01.写在前面
近期某项目有一个业务拓展的需求,需要将项目中单机房部署的模块扩展成异地多机房部署。原先项目的模块都部署在自建的机房A,有防火墙等相关安全策略的保护,相对比较安全,但现在网络跨越了两个公网通信的机房,该如何保证传输安全和访问控制呢?
HTTPS可以对服务器进行身份认证,同时也可以保证数据流量传输的安全,避免中间人攻击,但这并不能满足我们访问权限控制的要求(我们的服务并不希望任何人都能访问)。
解决以上问题有两种思路,一种是在应用层对模块进行改造,使其支持访问权限控制;另外一种则是双向HTTPS,基于双向HTTPS的特性来实现。出于是否能快速实现与成本考虑,我们最终选择了双向HTTPS来实现这一需求。
下面我们对如何实现这个需求与双向HTTPS的原理做一个简要介绍,希望给遇到类似问题的开发者提供一个思路供参考。
02.HTTPS & 双向HTTPS
HTTPS
HTTPS 全称为 HyperText Transfer Protocol Secure,在HTTP的基础上,集成了TLS/SSL传输层协议,以提供对网站服务器的身份认证,保护交换数据的隐私与完整性。 双向HTTPS
双向HTTPS在单向HTTPS认证的基础上,增加了服务端对客户端身份认证的步骤,在进行通信前互相验证对方身份,增加了网络的安全性。
要求 | 安全性 | 用途 | |
---|---|---|---|
单向 | 服务端部署证书 | 客户端使用根证书校验服务端证书 | 任何使用http协议且对传输安全 |
双向 | 服务端部署证书 | 客户端使用根证书校验服务端证书 | 在HTTPS私密传输基础上有访问 |
客户端部署证书 | 服务端CA证书校验客户端证书 | 权限控制需求的场景,比如银行支付经常会使用U盾来验证身份。 |
03.方案思考
网络环境介绍
服务端与客户端原先在同一机房内,只使用了HTTP协议来做数据传输。
我们的目标方案则是保证跨域公网的两个模块能够互相通信,并在此基础上确保输过程的安全性与权限控制。
解决思路
1.为服务端增加Nginx做反向HTTPS代理此时客户端访问服务端的流量采用了HTTPS协议,保证了数据流量的安全,但暴露在公网上的服务端依然有被其他人访问的风险
2.在1 的基础上为客户端增加Nginx做正向代理,将单向HTTPS升级为双向HTTPS
双向HTTPS在单向HTTPS的基础上,多了服务端校验客户端证书的步骤。若服务端校验客户端证书失败,则在HTTPS握手阶段服务端就将其拒绝。这样,就一定程度上实现了服务端的访问权限控制。
涉及新增修改的内容
1.新增代理层
代理层包括客户端和服务端的两个代理服务器,此处选用Nginx
2.新增一个CA中心
新增的CA中心主要用于为客户端颁发证书( 服务端的HTTPS证书将选用商用CA证书)
配置双向HTTPS的整体投入的整体投入和为模块开发权限功能比起来,此方案的实现相对来说更简单也更快捷。 环境搭建验证
此处将使用openssl 与docker,在本地搭建一套方案中的模拟环境来验证方案的可行性。
证书生成
证书结构
方案所需的证书结构如下:
• 生成证书
# 生成私钥
openssl genrsa -out ca.key 4096
# 生成自签名根证书
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
• 生成服务端用证书
# 生成私钥
openssl genrsa -out server.key 4096
# 生成CSR证书请求
openssl req -new -key server.key -out server.csr
# 使用CA1根证书签发证书
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 3650
• 生成客户端证书的过程同生成服务端的过程相同,更换相应名称即可 配置服务端Nginx
• 配置并启动
修改服务端 Nginx配置文件并启动,具体关键配置如下:
•服务端Nginx启动
docker run \
--name nginx_server \
# 指定映射的端口
-p 30443:30443 \
-d \
#将相应的证书和配置文件挂载入容器
-v /Users/zhangchenyu/Documents/temp/nginx_test2/server/conf/nginx.conf:/etc/nginx/nginx.conf:ro \
-v /Users/zhangchenyu/Documents/temp/nginx_test2/server/conf/index.html:/etc/nginx/html/index.html:ro \
-v /Users/zhangchenyu/Documents/temp/nginx_test2/ca1:/etc/nginx/ca1:ro \
-v /Users/zhangchenyu/Documents/temp/nginx_test2/ca2:/etc/nginx/ca2:ro \
nginx
使用curl命令检查Nginx是否已经启用双向认证
证书注册时使用了域名,将注册时的相关域名添加到 /etc/hosts,否则使用本地ip无法访问。
• 直接访问
curl \
# 指定服务端证书的CA证书
--cacert ../ca1/ca.crt \
https://test.server:30443
服务端返回的结果提示:要求的证书未发送。
• 指定客户端发送证书
curl \
# 指定服务端证书的CA证书
--cacert ../ca1/ca.crt \
# 指定客户端证书
--cert client.crt \
# 指定客户端私钥
--key ./client.key \
# 指定tls 协议版本
--tlsv1.2 \
https://test.server:30443
• 调用结果:
当我们看到服务端返回了相应的页面,说明服务端已经开始使用双向HTTPS,对接收到的请求不再全部接受,而是在HTTPS握手阶段要求客户端发送客户端证书进行校验,校验通过的请求才进行处理。
配置客户端Nginx的正向代理
配置并启动 •客户端Nginx配置见下
注意:docker容器内的Nginx 在配置转发地址,指定的IP端口需要为容器内部IP端口。
• 客户端Nginx 启动
docker run \
--name nginx_client\
-d \
# 指定端口映射
-p 9999:9999 \
# 将相应的证书和配置文件挂载入容器
-v /Users/zhangchenyu/Documents/temp/nginx_temp2/client/conf/nginx.conf:/etc/nginx/nginx.conf:ro \
-v /Users/zhangchenyu/Documents/temp/nginx_temp2/ca1:/etc/nginx/ca1:ro \
-v /Users/zhangchenyu/Documents/temp/nginx_temp2/ca2:/etc/nginx/ca2:ro \
nginx
• 使用 curl 命令检查链路连通性
至此,整套链路已经搭建完成,如果使用curl 命令能最后访问到相应的服务端页面,那说明我们目标达成curl http://127.0.0.1:9999
调用结果 :
显然,客户端使用HTTP就访问到了终端服务。通过以上步骤我们可以看到Nginx 的两次代理,已经完全实现了本次需求。同时,我们发现通过Nginx配置的修改即可实现接口权限的控制,且保证网络传输的安全。
抓包分析
最后,完成了配置也别忘了总结分析哦。我们对双向HTTPS的握手和交互的过程进行抓包,抓包的同时简要分析单双向HTTPS的差异,并对双向HTTPS实现权限的控制过程予以了解。 • 单向HTTPS流量分析
随意访问一个HTTPS网站,并抓包。具体内容见下图 :
客户端向服务端发送 Client Hello,其中包含一个随机数A、支持的TLS版本、支持的加密套件等
服务器响应给客户端一个随机数B、选用的TLS协议版本、选用的加密套件、服务器证书、DH公钥等 此处Server Hello的包和证书、服务端DH公钥等响应的数据包分成了两个,而双向HTTPS的数据包是单个的,这与单向双向无关,具体看服务器对HTTPS协议的实现方式。
客户端返回DH公钥
使用DH算法计算生成Pre-master secret,并通过Master Secret生成器及随机数A、随机数B、Pre-master Secret 生成最终加密通信所用的Master Secret
客户端和服务端互相告知对方自己状态切换完成,并发送一条加密信息,以互相验证双方都拥有了正确的Master Secret
握手完成,开始使用 Master Secret加密通信
梳理下整体流程:
• 双向HTTPS流量分析
此处抓包的内容源自两台Nginx之间的流量
客户端向服务端发送 Client Hello,其中包含随机数A、支持的TLS版本、支持的加密套件等
加密套件说明 例如: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE 秘钥交换算法 RSA 身份验证算法 AES128_GCM 批量加密算法 SHA256 消息认证码算法
2.服务器响应给客户端随机数B、选用的TLS协议版本、选用的加密套件、服务器证书、DH算法公钥、以及要求客户端返回证书的请求等
– 随机数B、选用的TLS协议版本、选用的加密套件
– 服务端证书
– 服务端DH公钥
ServerKeyExchange是只有DH秘钥交换算法才有的一步,可以理解为这一步是为了计算得到Pre-master Secret;通过非对称加密方式来握手获取Pre-master Secret的加密套件不需要这一步。 – 要求客户端返回证书的请求
3.客户端校验证书的有效性 此处操作由Nginx 客户端内部完成,未体现在抓包中。 4.客户端返回客户端自身证书, 以及对证书的签名后, 通知服务端自己的加密策略已转换,以及第一条加密信息(用协商出的加密秘钥加密) – 客户端证书
此处区别于单向HTTPS,客户端发送的证书会被服务端Nginx配置的根证书进行校验,只有验证通过的客户端才可进行下一步。 – 客户端DH算法公钥
ClientKeyExchange,同ServerKeyExchange类似,都是为了支援DH交换秘钥 – 对证书的签名
客户端为了证明发出去的证书是自己的,需要使用私钥对证书进行签名,以确认证书身份。
– 通知服务端自己的加密策略已转换(Client)
– Encrypted Handshake Message 客户端第一条使用Master Secret加密的数据
Master Secret = MasterSecret生成器(随机数A、 随机数B、 DH交换获得的Pre-master Secret)
此消息发给服务端后,服务端会使用生成的Master Secret 进行解密,确认客户端已生成正确的Master Secret
5.服务端返回Session Ticket、通知客户端自己的加密策略已转换以及第一条使用Master Secret加密的数据
– Session Ticket
服务端会缓存Master Secret 一段时间,只需要客户端将Session Ticket 带过来,可以避免重复握手导致的资源开销 – 通知服务端自己的加密策略已转换(Server)
– 服务端返回第一条使用Master Secret加密的数据,功能等同于服务端发送Encrypted Handshake Message,此项给客户端是为了向客户端证明自己也生成了正确的Master Secret。
6.开始使用Master Secret 加密数据并开始通信
梳理下整体流程:
• 流程对比
我们结合整体抓包和分析的流程可知,双向HTTPS和单向HTTPS相比,多了对客户端证书校验、以及相应支援处理的步骤。客户端只有拿到了服务端CA颁发的证书,才能访问到服务端,这也是双向HTTPS拥有一定权限控制功能的基础。
04.总结
前文提及的改造需求,如果按照常规思路选择改动业务代码新增权限控制功能,需要改动的整体流程较为复杂,开发成本也相对较重,为此我们借鉴双向HTTPS的策略,通过修改配置方式快速地实现了该需求,避免了相关权限控制的重复劳动。
此外,HTTPS整体流程,无论是单向还是双向,都是互联网技术领域的基础保障,值得我们开发者继续探究和学习其协议的相关细节。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8