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

HTTPS默认端口号为433,基于HTTP扩展了安全传输的特性,其他特性完全沿用HTTP。

一、HTTPS协议架构

我们先来看一看HTTP的协议架构和HTTPS协议架构的区别:

计算机网络详解——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的精华所在了。

二、SSL/TLS发展历史

为了保证安全性,SSL/TLS在不断的迭代升级版本,引入了更加安全的算法套件。下面是大致的升级过程:
计算机网络详解——HTTPS_服务器_02

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

不过由于安全问题,TLS 1.1及其以下版本都将作废,不再维护,目前主要在用的是TLS 1.2和TLS 1.3。

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

三、TLS详解

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

常见的加密套件可以参考  161 Cipher Suites

我们选一个来看看加密套件的命名格式:
计算机网络详解——HTTPS_服务器_03

如最后一个组合,意味着:

  • ECDHE: 握手时,使用ECDHE算法交换密钥;

  • ECDSA: 使用ECDSA算法进行签名;

  • AES128-GCM: 使用AES256对称加密算法进行通信,密钥长度128,分组模式GCM;

  • SHA256: 使用SHA256算法进行消息的完整性验证和产生随机数。

3.1、为什么需要用到这么多算法?

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

为了保证安全,TLS就需要保证这五个特性。简要说明下这个五个特性:

  • 机密性:保密信息不会透露给非授权的用户或实体;

  • 可用性:指的是加密服务的高可用;

  • 完整性:信息不回被非法篡改,有对应的篡改检测机制;

  • 认证性:参与信息交换的两个主体需要确认对方的身份是否可信,避免信息被不怀好意的人给窃取或者篡改;

  • 不可否认性:指的是用户在事后无法否认曾经进行的信息交换、签发;

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

3.2、对称加密算法

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

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

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

3.3、非对称加密

非对称加密通常包含一对密钥,称为公钥(public key)和私钥(private key)。

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

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

虽然非对称加密能够保证安全性,但是性能却比对称加密差很多。

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

3.4、摘要算法

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

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

有了摘要算法就能保证完整性了吗?
假如黑客截取了信息,改动了信息之后,重新生成了摘要,那么,这个时候就判断不出来消息是被篡改过了。
计算机网络详解——HTTPS_HTTPS_04
为了避免这类消息发生,我们需要给摘要也通过会话密钥进行加密,这样就看不到摘要明文信息了,能更好的保证信息的安全性了。
计算机网络详解——HTTPS_客户端_05
可见,离开了机密性,完整性也就无从说起了。

3.5、数字签名

到目前为止,我们还有一个问题没有解决,那就是:怎么知道我们要连接的网站不是伪造的呢,如果是伪造的,即使他给了我们他的公钥,也是可以成功进行加解密的,因为他给的公钥给他自己的私钥本身就是一对。

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

中间人攻击

计算机网络详解——HTTPS_HTTPS_06
为了避免拿到假的公钥,所以我们需要一个权威机构帮忙验证这个公钥是不是真的。

通过CA机构生成数字证书

这个时候我们请来了权威的机构,来帮忙我们生成网站公钥的数字证书:
计算机网络详解——HTTPS_服务器_07

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

  • CA机构通过摘要算法生成公钥的摘要;

  • CA机构通过自己的CA私钥以及特定的签名算法加密摘要,生成签名;

  • 把签名、服务器公钥,以及其他基本信息打包放入数字证书中。

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

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

服务器公钥验证流程

客户端接收到服务器发送的数字证书和CA机构的公钥,通过CA机构的公钥对数字证书上的签名进行验证。
计算机网络详解——HTTPS_HTTPS_08

验证过程:

  • 使用CA公钥和声明的签名算法对CA中的签名进行解密,得到服务器公钥的摘要内容;

  • 拿到证书里面的服务器公钥,用摘要算法生成摘要内容,与第一步的结果对比,如果一致,则说该证书就是合法的,里面的公钥是正确的,否则证书就是非法的。

谁来保证CA的公钥的正确性?
服务器验证的时候,需要拿到数字证书发布机构的CA公钥,但是怎么证明这个CA公钥是正确的呢?这个时候就需要有更大的CA帮小的CA的公钥做认证了,一层一层的背书,最顶层的CA,Root CA,称为根证书,作为信任链的根,是全球皆知的的极大著名CA,这些根证书一般会内置到操作系统中。
计算机网络详解——HTTPS_服务器_09
大家可以到操作系统的证书目录下,或者浏览器,看看证书文件里面都有什么内容。
思考题:
即使证书验证通过了,这样就能够保证安全了么,想想还有没有其他原因导致请求的网站身份不可信的;
有了CA机构,就没法进行中间人攻击了吗?

3.6、算法总结

计算机网络详解——HTTPS_客户端_10
我们来总结一下上面提到的各种算法的作用:

  • 签名算法:通过数字证书,和CA公钥,验证获取到的服务器公钥的可靠性,保证了认证性;

  • 密钥交换算法 + 对称加密算法:通过交换的密钥,进行加密通信,保证了机密性和不可否认性;

  • 摘要算法:保证完整性。

四、HTTPS连接过程

HTTS连接访问比HTTP多了一步TLS连接:DNS解析,TCP连接、TLS连接。

最关键的就是TLS连接,这里我们重点来分析。

其中TLS连接认证分为单向认证和双向认证:

单向认证 :服务器提供证书,客户端验证服务器证书;

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

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

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

4.1、基于TLS1.2的HTTPS连接过程

4.1.1、RSA密钥交换算法

这个过程稍微有点复杂,还是先上图,流程的关键部分都加上了注释,后面详细解释。
计算机网络详解——HTTPS_服务器_11

如上图:

  • 首先是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连接过程。

4.1.2、ECDHE密钥交换算法

我把与基于RSA算法的连接过程的差异步骤都进行高亮显示了,如下图:
计算机网络详解——HTTPS_服务器_12

这里重点说明不一样的地方:

  • 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。

4.2、TLS1.3对安全性和性能的提升

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

4.2.1、安全性提升

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

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

假设有人故意截获了会话中所有的加密报文,在RSA算法中,如果私钥泄露,那么就可以推算出PreMaster和对称密钥,那么保存了所有的历史报文都会被破解。

4.2.2、性能提升

上图我们看到,TLS握手经历了两个RTT。

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

思考:用了HTTPS肯定会变慢,有什么提升速度的措施呢?

原文出处:
 https://www.itzhai.com/articles/https-the-battle-for-network-security.html