HTTP与HTTPS的区别；TLS握手过程

Posted 2023-04-03 Weber77

一、HTTP协议与HTTPS

我们都知道当客户端与服务端需要进行通信时，需要根据一套协议来进行通信。

HTTP全程是超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

我们都知道使用浏览器访问一个网站页面，需要知道该网站的域名，在浏览器的地址栏中我们会看到一串URL，如图

网站的URL会分为两部分：通信协议和域名地址。

域名地址都很好理解，不同的域名地址表示网站中不同的页面，而通信协议，简单来说就是浏览器和服务器之间沟通的语言。网站中的通信协议一般就是HTTP协议和HTTPS协议。两者分别是什么，有什么区别呢？

HTTP协议

HTTP协议也就是超文本传输协议，是一种使用明文数据传输的网络协议。一直以来HTTP协议都是最主流的网页协议，HTTP协议被用于在Web浏览器和网站服务器之间传递信息，以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。

互联网发展到今天，HTTP协议的明文传输会让用户存在非常大的安全隐患。试想一下，假如你在一个HTTP协议的网站上面购物，你需要在页面上输入你的银行卡号和密码，然后你把数据提交到服务器实现购买。假如这个环节稍有不慎，你的传输数据被第三者给截获了，由于HTTP明文数据传输的原因，你的银行卡号和密码，将会被这个截获人所得到。现在你还敢在一个HTTP的网站上面购物吗？你还会在一个HTTP的网站上面留下你的个人信息吗？

HTTPS协议

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。HTTPS协议可以理解为HTTP协议的升级，就是在HTTP的基础上增加了数据加密。在数据进行传输之前，对数据进行加密，然后再发送到服务器。这样，就算数据被第三者所截获，但是由于数据是加密的，所以你的个人信息仍然是安全的。这就是HTTP和HTTPS的最大区别。

 二、HTTP和HTTPS的区别

1.安全性不同

https://前缀表明是用SSL (安全套接字)或TSL加密的，你的电脑与服务器之间收发的信息传输将更加安全。当你使用浏览器访问一个HTTP网站的时候，你会发现浏览器会对该HTTP网站显示“不安全”的安全警告，提示用户当前所访问的网站可能会存在风险

2.网站申请流程不同

https协议需要到CA申请证书，一般免费证书很少，需要交费，Web服务器启用SSL需要获得一个服务器证书并将该证书与要使用SSL的服务器绑定。

3.默认端口不同

http和https使用的是完全不同的连接方式，同时使用的端口也不同，http使用的是80端口，https使用的是443端口。在网络模型中，HTTP工作于应用层，而HTTPS工作在传输层。

三、加密算法

一般加密算法分为对称加密和非对称加密两种

对称加密

加密和解密的秘钥使用的是同一个，密钥较短，破译困难，除了数据加密标准（DES），另一个对称密钥加密系统是国际数据加密算法（IDEA），它比DES的加密性好，且对计算机性能要求也没有那么高.

 优点:

 算法公开、计算量小、加密速度快、加密效率高

缺点:

在数据传送前，发送方和接收方必须商定好秘钥，然后 使双方都能保存好秘钥。其次如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

常见的对称加密算法有: DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES 

非对称加密

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。

优点:

安全，即使密文被拦截、公钥被获取，但是无法获取到私钥，也就无法破译密文。作为接收方，务必要保管好自己的密钥。

缺点:

加密算法及其复杂，安全性依赖算法与密钥，而且加密和解密效率很低。

常见的非对称加密算法有: RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

四、TLS握手过程

1、首先client将自己支持的TLS版本，可供选择的加密算法，以及一个随机数发送给server

2、server收到消息后将自己的TLS版本，选择的一套加密算法，以及第二个随机数发送给client

3、server将自己的CA证书发送给client，确保client想要访问的网站是正确的

4、server将自己的public key发送给client，并告诉client本次通话结束

5、client生成第三个随机数（预主密钥）使用公钥对预主密钥进行加密，并发送给server

6、server收到加密的预主密钥，使用自己的私钥进行解密，这样就只有server和client知道预主密钥了

7、server和client使用第一第二随机数和预主密钥进行计算获得会话密钥

8、之后server和client可以使用会话密钥进行对称加密，加快通信效率

SSL/TLS 握手过程详解***

我们知道，HTTP 协议都是明文传输内容，在早期只展示静态内容时没有问题。伴随着互联网的快速发展，人们对于网络传输安全性的要求也越来越高，HTTPS 协议因此出现。如上图所示，在 HTTPS 加密中真正起作用的其实是 SSL/TLS 协议。SSL/TLS 协议作用在 HTTP 协议之下，对于上层应用来说，原来的发送接收数据流程不变，这就很好地兼容了老的 HTTP 协议，这也是软件开发中分层实现的体现。

SSL/TLS 握手是为了安全地协商出一份对称加密的秘钥，这个过程很有意思，下面我们一起来了解一下。

以下内容需要你对加解密、数字签名和数字证书的概念有一定了解，这里有一篇文章可以帮你快速了解这几个概念。

SSL/TLS 握手过程

 

上图大致描述了 SSL/TLS 的握手过程，但缺少了一些信息不利于理解，我会在后面的讲解里再列出来。

Client Hello

握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。通过 Wireshark 抓包，我们可以看到如下信息：

 

Wireshark 抓包的用法可以参考这篇文章

Server Hello

第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

 

Certificate

这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。

 

Server Key Exchange

如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。

 

Certificate Request

Certificate Request 是服务端要求客户端上报证书，这一步是可选的，对于安全性要求高的场景会用到。

Server Hello Done

Server Hello Done 通知客户端 Server Hello 过程结束。

 

Certificate Verify

客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。

Client Key Exchange

上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。客户端将 PreMaster Key 传给服务端的过程如下图所示：

 

Change Cipher Spec(Client)

这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。

 

Encrypted Handshake Message(Client)

这一步对应的是 Client Finish 消息，客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。

 

Change Cipher Spec(Server)

这一步是服务端通知客户端后面再发送的消息都会使用加密，也是一条事件消息。

Encrypted Handshake Message(Server)

这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。

 

Application Data

到这里，双方已安全地协商出了同一份秘钥，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。

双向验证

前面提到 Certificate Request 是可选的，下面这张图展示了双向验证的过程：

 

握手过程优化

如果每次重连都要重新握手还是比较耗时的，所以可以对握手过程进行优化。从下图里我们看到 Client Hello 消息里还附带了上一次的 Session ID，服务端接收到这个 Session ID 后如果能复用就不再进行后续的握手过程。

 

除了上述的 Session 复用，SSL/TLS 握手还有一些优化技术，例如 False Start、Session Ticket 等，这方面的介绍具体可以参考这篇文章。

总结

前面我们一起详细地了解了整个 SSL/TLS 的握手过程，这部分知识在平时的开发过程中很少用到，但能让我们更清楚地了解 HTTPS 的工作原理，而不仅仅是只知道 HTTPS 会加密数据十分安全。同时这个过程也是各种加密技术的一个经典运用，也能帮助我们加深加密相关技术的理解。最后，建议大家也用 Wireshark 实际抓包体验一下这个过程来加深印象，enjoy~

参考资料

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

https://segmentfault.com/a/1190000002554673

https://imququ.com/post/optimize-tls-handshake.html

http://blog.csdn.net/fw0124/article/details/40983787