当前位置：首页 > 资讯 > 软件开发应用 > 安全

如何用双向HTTPS进行“偷懒”

分类：软件开发应用时间：2020-10-18 20:29 浏览：309

概述

作者简介：四拾一，个推高级开发工程师，精通Java、Go语言，全栈践行者，对于数据安全、密码学有较深入的理解与实践。01写在前面近期某项目有一个业务拓展的需求，需要将项目中单机房部署的模块扩展成异地多机房部署。原先项目的模块都部

内容

作者简介：
四拾一，个推高级开发工程师，精通Java、Go语言，全栈践行者，对于数据安全、密码学有较深入的理解与实践。

01 写在前面

近期某项目有一个业务拓展的需求，需要将项目中单机房部署的模块扩展成异地多机房部署。原先项目的模块都部署在自建的机房A，有防火墙等相关安全策略的保护，相对比较安全，但现在网络跨越了两个公网通信的机房，该如何保证传输安全和访问控制呢？

HTTPS可以对服务器进行身份认证，同时也可以保证数据流量传输的安全，避免中间人攻击，但这并不能满足我们访问权限控制的要求（我们的服务并不希望任何人都能访问）。

解决以上问题有两种思路，一种是在应用层对模块进行改造，使其支持访问权限控制；另外一种则是双向HTTPS，基于双向HTTPS的特性来实现。出于是否能快速实现与成本考虑，我们最终选择了双向HTTPS来实现这一需求。

下面我们对如何实现这个需求与双向HTTPS的原理做一个简要介绍，希望给遇到类似问题的开发者提供一个思路供参考。

02 HTTPS & 双向HTTPS

HTTPS

HTTPS 全称为 HyperText Transfer Protocol Secure，在HTTP的基础上，集成了TLS/SSL传输层协议，以提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

双向HTTPS

双向HTTPS在单向HTTPS认证的基础上，增加了服务端对客户端身份认证的步骤，在进行通信前互相验证对方身份，增加了网络的安全性。

03 方案思考

网络环境介绍

服务端与客户端原先在同一机房内，只使用了HTTP协议来做数据传输。

我们的目标方案则是保证跨域公网的两个模块能够互相通信，并在此基础上确保输过程的安全性与权限控制。

解决思路

为服务端增加Nginx做反向HTTPS代理
此时客户端访问服务端的流量采用了HTTPS协议，保证了数据流量的安全，但暴露在公网上的服务端依然有被其他人访问的风险

在1 的基础上为客户端增加Nginx做正向代理，将单向HTTPS升级为双向HTTPS

双向HTTPS在单向HTTPS的基础上，多了服务端校验客户端证书的步骤。若服务端校验客户端证书失败，则在HTTPS握手阶段服务端就将其拒绝。这样，就一定程度上实现了服务端的访问权限控制。

涉及新增修改的内容

新增代理层
代理层包括客户端和服务端的两个代理服务器，此处选用Nginx
新增一个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_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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bMdTUHyK-1602177408571)(/img/bVceVRD)] ](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/81b17287c3904c7b8501403bff5033f5~tplv-k3u1fbpfcp-zoom-1.image)

服务端返回的结果提示：要求的证书未发送。
• 指定客户端发送证书

• 调用结果：

显然，客户端使用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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kmfjGGkB-1602177408581)(/img/bVceVTZ)]](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9dbb16403e284efe846b8403c8a5fc5c~tplv-k3u1fbpfcp-zoom-1.image)

握手完成，开始使用 Master Secret加密通信
梳理下整体流程：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XLTZN0JQ-1602177408584)(/img/bVceVT2)]](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7cc2797f57a24017b1ea9f1456c1b87b~tplv-k3u1fbpfcp-zoom-1.image)

• 双向HTTPS流量分析
此处抓包的内容源自两台Nginx之间的流量

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wk6KMA51-1602177408586)(/img/bVceVT4)]](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/91b8a4c75bfb416980c30802e96f60a7~tplv-k3u1fbpfcp-zoom-1.image)

客户端向服务端发送 Client Hello，其中包含随机数A、支持的TLS版本、支持的加密套件等

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JlfnJMlB-1602177408592)(/img/bVceVT8)]](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ed4f67c983e14fe8ae1f8722567b5aec~tplv-k3u1fbpfcp-zoom-1.image)

加密套件说明例如: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE 秘钥交换算法
RSA 身份验证算法
AES128_GCM 批量加密算法
SHA256 消息认证码算法

服务器响应给客户端随机数B、选用的TLS协议版本、选用的加密套件、服务器证书、DH算法公钥、以及要求客户端返回证书的请求等
– 随机数B、选用的TLS协议版本、选用的加密套件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zGyzeK6u-1602177408594)(/img/bVceVT9)]](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2780ecb32f444d4ab74794fe707f0625~tplv-k3u1fbpfcp-zoom-1.image)

– 服务端证书
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f54AhHh9-1602177408595)(/img/bVceVUc)]
](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5cc40903089d417eaa9d95aa58be2196~tplv-k3u1fbpfcp-zoom-1.image)

– 服务端DH公钥

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RfOQjTYh-1602177408597)(/img/bVceVUa)]](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/940cb04a5be242bfa6ee99c59d28b97b~tplv-k3u1fbpfcp-zoom-1.image)

ServerKeyExchange是只有DH秘钥交换算法才有的一步，可以理解为这一步是为了计算得到Pre-master Secret；通过非对称加密方式来握手获取Pre-master Secret的加密套件不需要这一步。

– 要求客户端返回证书的请求

客户端校验证书的有效性
此处操作由Nginx 客户端内部完成，未体现在抓包中。
客户端返回客户端自身证书, 以及对证书的签名后, 通知服务端自己的加密策略已转换，以及第一条加密信息（用协商出的加密秘钥加密）

– 客户端证书

此处区别于单向HTTPS，客户端发送的证书会被服务端Nginx配置的根证书进行校验，只有验证通过的客户端才可进行下一步。

– 客户端DH算法公钥

ClientKeyExchange，同ServerKeyExchange类似，都是为了支援DH交换秘钥

– 对证书的签名

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7opxHbuw-1602177408609)(/img/bVceVUJ)]](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1c2dbe864248448782ca774a106c3b08~tplv-k3u1fbpfcp-zoom-1.image)

客户端为了证明发出去的证书是自己的，需要使用私钥对证书进行签名，以确认证书身份。
– 通知服务端自己的加密策略已转换(Client)