HTTPS：网络安全攻坚战

本文为《三万长文50+趣图带你领悟web编程的内功心法》第五个章节。

五、HTTPS

咱们知道，明文传输和不安全是HTTP的其中一个特色，可是随着愈来愈多机密的业务交易转移到线上，如银行转帐、证券交易、在线支付、电商等，咱们对传输的安全性有了更高的要求，为此，出现了HTTP的扩展：HTTPS，Hypertext Transfer Protocol Secure，超文本传输安全协议。

HTTPS默认端口号为433，基于HTTP扩展了安全传输的特性，其余特性彻底沿用HTTP。

5.一、HTTPS协议架构

咱们先来看一看HTTP的协议架构和HTTPS协议架构的区别：

HTTP是基于TCP/IP的协议，中间没有任何安全传输相关的模块。为此，HTTPS在中间引入了一个传输级的密码安全层，该层可使用安全套接层 Secure Sockets Layer(SSL)，也可使用其后继者：传输层安全 Transport Layer Security(TLS)。

HTTPS = HTTP + SSL or TLS

加入这层以后，收发报文也就再也不是使用Socket API，而是调用了安全层提供的安全API。在使用HTTPS时无需过多的修改协议处理逻辑。

为此，若是咱们弄清楚这个SSL/TLS，就理解了HTTPS的精华所在了。

5.二、SSL/TLS发展历史

为了保证安全性，SSL/TLS在不断的迭代升级版本，引入了更加安全的算法套件。下面是大体的升级过程：

在1999年，SSL 3.0升级为TLS 1.0，写入到RFC 2246标准中。

不过因为安全问题，TLS 1.1及其如下版本都将做废，再也不维护，目前主要在用的是TLS 1.2和TLS 1.3。

OpenSSL是开源版本的实现，目前急需在维护的是OpenSSL 1.1.1版本。

5.三、TLS详解

浏览器和服务器通讯以前，会先协商，选出他们都支持的加密套件，用于实现安全的通讯。

常见的加密套件能够参考 161 Cipher Suites^[1]。

咱们选一个来看看加密套件的命名格式：

如最后一个组合，意味着：

• ECDHE: 握手时，使用ECDHE算法交换密钥；
• ECDSA: 使用ECDSA算法进行签名；
• AES128-GCM: 使用AES256对称加密算法进行通讯，密钥长度128，分组模式GCM；
• SHA256: 使用SHA256算法进行消息的完整性验证和产生随机数。

5.3.一、为何须要用到这么多算法？

以密码学为基础的信息安全包含主要的五个方面：机密性，可用性，完整性，认证性，不能否认性。

为了保证安全，TLS就须要保证这五个特性。简要说明下这个五个特性：

• 机密性：保密信息不会透露给非受权的用户或实体；
• 可用性：指的是加密服务的高可用；
• 完整性：信息不回被非法篡改，有对应的篡改检测机制；
• 认证性：参与信息交换的两个主体须要确认对方的身份是否可信，避免信息被不怀好意的人给窃取或者篡改；
• 不能否认性：指的是用户在过后没法否定曾经进行的信息交换、签发；

每种算法，在TLS中都有其特定的用处，下面先简单介绍各类算法。

5.3.二、对称加密算法

所谓对称加密，就是使用同一个密钥进行加解密。

最多见的就是AES加密算法。

可是对称加密，加解密双方如何安全的传递密钥是一个问题。若是服务器直接把密钥传输给客户端，而后才进行加密通讯，可能在传输密钥的过程当中，密钥就被窃取了。

5.3.三、非对称加密

非对称加密一般包含一对密钥，称为公钥(public key)和私钥(private key)。

其中一个密钥加密后的数据，只能让另外一个密钥进行解密。

使用公钥推算出私钥是很是困难的，可是随着计算机运算能力提高，目前在程序中使用的非对称密钥至少要2048位才能保证安全性。

虽然非对称加密可以保证安全性，可是性能却比对称加密差不少。

为此，在TLS中，实际上用的是用到了两种算法的混合加密。经过非对称加密算法交换对称加密算法的密钥，交换完成以后，在使用对称加密进行加解密传输数据。这样就保证了会话的机密性。

5.3.四、摘要算法

摘要算法主要用于保证信息的完整性，至关于信息的指纹信息。常见的散列函数，哈希函数，MD5算法都属于这类算法，其特色是单向性，没法反推原文。

为了保证安全性，目前TLS推荐使用SHA-2摘要算法，禁止使用MD5和SHA-1。

有了摘要算法就能保证完整性了吗？

假如黑客截取了信息，改动了信息以后，从新生成了摘要，那么，这个时候就判断不出来消息是被篡改过了。

为了不这类消息发生，咱们须要给摘要也经过会话密钥进行加密，这样就看不到摘要明文信息了，能更好的保证信息的安全性了。

可见，离开了机密性，完整性也就无从提及了。

5.3.五、数字签名

到目前为止，咱们还有一个问题没有解决，那就是：怎么知道咱们要链接的网站不是伪造的呢，若是是伪造的，即便他给了咱们他的公钥，也是能够成功进行加解密的，由于他给的公钥给他本身的私钥自己就是一对。

以下图，客户端的请求被中间人截获了，中间人给了客户端本身的公钥，最终客户端把消息发给了中间人，中间人这个时候是能够解密密文拿到原始数据的。而后中间人请求实际的服务器，拿到了实际服务器的公钥，再把消息转发给实际的服务器。这样就窃取了客户端的信息了。

中间人攻击

为了不拿到假的公钥，因此咱们须要一个权威机构帮忙验证这个公钥是否是真的。

经过CA机构生成数字证书

这个时候咱们请来了权威的机构，来帮忙咱们生成网站公钥的数字证书：

如上图，服务器和CA机构分别有一对密钥，服务器请求CA机构把服务器公钥生成一个数字证书，生成流程：

• CA机构经过摘要算法生成公钥的摘要；
• CA机构经过本身的CA私钥以及特定的签名算法加密摘要，生成签名；
• 把签名、服务器公钥，以及其余基本信息打包放入数字证书中。

最后，CA机构把生成的数字证书返回给服务器。

服务器配置好生成的证书，之后客户端链接服务器，都先把这个证书返回给客户端，让客户端验证并获取服务器的公钥。

服务器公钥验证流程

客户端接收到服务器发送的数字证书和CA机构的公钥，经过CA机构的公钥对数字证书上的签名进行验证。

验证过程：

• 使用CA公钥和声明的签名算法对CA中的签名进行解密，获得服务器公钥的摘要内容；
• 拿到证书里面的服务器公钥，用摘要算法生成摘要内容，与第一步的结果对比，若是一致，则说该证书就是合法的，里面的公钥是正确的，不然证书就是非法的。

谁来保证CA的公钥的正确性?

服务器验证的时候，须要拿到数字证书发布机构的CA公钥，可是怎么证实这个CA公钥是正确的呢？这个时候就须要有更大的CA帮小的CA的公钥作认证了，一层一层的背书，最顶层的CA，Root CA，称为根证书，做为信任链的根，是全球皆知的的极大著名CA，这些根证书通常会内置到操做系统中。

你们能够到操做系统的证书目录下，或者浏览器，看看证书文件里面都有什么内容。

思考题：

1. 即便证书验证经过了，这样就可以保证安全了么，想一想还有没有其余缘由致使请求的网站身份不可信的；
2. 有了CA机构，就无法进行中间人攻击了吗？

5.3.六、算法总结

咱们来总结一下上面提到的各类算法的做用：

• 签名算法：经过数字证书，和CA公钥，验证获取到的服务器公钥的可靠性，保证了认证性；
• 密钥交换算法 + 对称加密算法：经过交换的密钥，进行加密通讯，保证了机密性和不能否认性；
• 摘要算法：保证完整性。

本文首次发表于: HTTPS：网络安全攻坚战 以及公众号 Java架构杂谈，未经许可，不得转载。

5.四、HTTPS链接过程

HTTS链接访问比HTTP多了一步TLS链接：DNS解析，TCP链接、TLS链接。

最关键的就是TLS链接，这里咱们重点来分析。

其中TLS链接认证分为单向认证和双向认证：

单向认证 ：服务器提供证书，客户端验证服务器证书；

双向认证 ：服务器客户端分别提供证书给对方，并互相验证对方的证书。

不过，大多数运行HTTPS的web服务器都不须要客户端提供证书，若是服务器须要验证客户端的身份，通常是经过用户名和密码、手机验证码等之类的凭证来完成。对于更高安全级别要求的系统，如大额网银转帐等，则会提供双向认证的场景，来确保对客户身份提供认证性。

早期的TLS密钥交换用的是RSA算法，目前主流都是用ECDHE算法来作密钥交换的。下面咱们分别来介绍下。

5.4.一、基于TLS1.2的HTTPS链接过程

5.4.1.一、RSA密钥交换算法

这个过程稍微有点复杂，仍是先上图，流程的关键部分都加上了注释，后面详细解释。

如上图：

• 首先是TCP三次握手，握手成功以后，就能够开始经过TCP传输数据了；
• 接下来是TLS握手的流程：
  • Client Hello：客户端生成一个Client Random随机数，明文发送给服务器，同时提供本身的 TLS版本号，以及本身支持的加密套件；
  • Server Hello：服务器收到以后，也生成了一个Server Random随机数，明文发送给客户端，同时告知本身选择的TLS版本号，以及选择的加密套件；
  • Server Certificate：服务器发送本身的证书给到客户端；
  • Server Hello Done：提示服务器信息发送完毕；
  • 客户端收到证书以后进行证书的校验，确保公钥是合法的；
  • Client Key Exchange：客户端生成一个PreMaster随机数，经过服务器的公钥加密传输给服务器；
  • 这个时候客户端和服务器都有三个参数：Server Random、Client Random、PreMaster，其中PreMaster是没法被不怀好意的人截获的，经过这三个参数，生成对称密钥；
  • 客户端Change Cipher Spec：客户端通知服务器后续改用刚刚生成的密钥进行加密通讯；
  • 客户端Encrypted Handshake Message：客户端准备用刚刚的参数加密传输，验证加密通讯；
  • 服务器Change Cipher Spec：服务器也通知客户端后续改用刚刚生成的密钥进行加密通讯；
  • 服务器Encrypted Handshake Message：服务器准备用刚刚的参数加密传输，验证加密通讯；
  • 在双方都确认好了以后，最后是验证的消息。

这里的核心是：经过非对称加密交换参数，生成对称通讯加密的密钥，其中PreMaster是非对称加密传输的，保证了不会泄露通讯加密的密钥。

下面咱们再来看看主流的ECDHE密钥交换算法的HTTPS链接过程。

5.4.1.二、ECDHE密钥交换算法

我把与基于RSA算法的链接过程的差别步骤都进行高亮显示了，以下图：

这里我重点说明不同的地方：

• Server Key Exchange：在服务端发送完证书以后，多了这一步，这个是椭圆曲线参数Server Params，为了保证认证性，这里同时生成了Server Params的签名，一块儿发给客户端；
• Client Key Exchange：这里再也不是直接发送客户端生成PreMaster，而是生成客户端的椭圆曲线参数Client Params，直接传送给服务端；接着，客户端和服务端双方经过ECDHE算法用Client Params和Server Params算出最终的PreMaster，这个PreMaster是保证不会被截获的。这样双方就有了：Client Random，Server Random，PreMaster参数了，经过这三个参数就能够生成通讯密钥了；
• 在客户端发送了Encrypted Handshake Message以后，就马上发送测试包了，不用等到服务端发送完Encrypted Handshake Message。

5.4.二、TLS1.3对安全性和性能的提高

TLS1.3是2018年发布的，这个版本中对安全性和性能上有了大幅度提高。

5.4.2.一、安全性提高

这个版本中砍掉了不少不够安全点加密套件中的算法，只提供了少而精的加密套件。

密钥交换算法废弃了RSA，更好地保证了安全性，不会由于RSA私钥泄露致使历史报文被破解的问题出现。

假设有人故意截获了会话中全部的加密报文，在RSA算法中，若是私钥泄露，那么就能够推算出PreMaster和对称密钥，那么保存了全部的历史报文都会被破解。

5.4.2.二、性能提高

上图咱们看到，TLS握手经历了两个RTT。

TLS1.3简化了握手过程，主要就是把原来两个RTT中的信息，打包成一个发送了，减小传输次数，最终只须要1个RTT就完成了信息的交换和握手。

思考：用了HTTPS确定会变慢，有什么提高速度的措施呢？

---

这篇文章的内容就介绍到这里，可以阅读到这里的朋友真的是颇有耐心，为你点个赞。

本文为arthinking基于相关技术资料和官方文档撰写而成，确保内容的准确性，若是你发现了有何错漏之处，烦请高抬贵手帮忙指正，万分感激。

若是您以为读完本文有所收获的话，能够关注个人帐号，或者点赞吧，码字不易，您的支持就是我写做的最大动力，再次感谢！

为了把相关系列文章收集起来，方便后续查阅，这里我建立了一个Github仓库，把发布的文章按照分类收集起来了，感兴趣的朋友能够Star跟进：

https://github.com/arthinking/java-tech-stack

关注个人博客IT宅(itzhai.com)或者公众号Java架构杂谈，及时获取最新的文章。我将持续更新后端相关技术，涉及JVM、Java基础、架构设计、网络编程、数据结构、数据库、算法、并发编程、分布式系统等相关内容。

References

• 谢希仁. 计算机网络(第6版). 电子工业出版社.
• TCP/IP详解 卷1：协议（原书第2版）. 机械工业出版社.
• UNIX网络编程 卷1：套接字联网API. 人民邮电出版社
• HTTP权威指南. 人民邮电出版社
• HTTP/2基础教程. 人民邮电出版社
• 刘超. 趣谈网络协议. 极客时间
• 罗剑锋. 透视HTTP协议. 便可时间

---

本文同步发表于个人博客IT宅(itzhai.com)和公众号(Java架构杂谈)

做者：arthinking | 公众号：Java架构杂谈

博客连接：https://www.itzhai.com/articles/https-the-battle-for-network-security.html

版权声明： 版权归做者全部，未经许可不得转载，侵权必究！联系做者请加公众号。

---

1. 161 Cipher Suites. Retrieved from https://ciphersuite.info/cs/?software=openssl&singlepage=true ↩︎