HTTPS协议
引言
HTTP和HTTPS协议是互联网上应用最为广泛的网络协议,现在为了安全,很多网站从HTTP的阵营转向HTTPS。近两年,Google、Baidu、Facebook 等这样的互联网巨头,不谋而合地开始大力推行 HTTPS, 国内外的大型互联网公司很多也都已经启用了全站 HTTPS,这也是未来互联网发展的趋势。
TCP协议
TCP协议的三次握手与四次挥手
先来一张网络模型图(应表会传网数物),可以看到TCP、UDP协议处于传输层。
建立TCP需要三次握手才能建立,而断开连接连接则需要四次挥手。整个过程如下图:
三次握手建立连接
1、Client
端发送连接请求报文。
2、Server
端接受连接后回复ACK报文,并为这次连接分配资源。
3、Client
端接收到ACK报文后也向Server段发送报文,并分配资源
这就是TCP的三次握手建立连接阶段。
四次挥手断开连接
中断连接端可以是Client端,也可以是Server端。
1、假设Client
端发起中断请求,也就是发送FIN报文。
2、Server
端接到FIN报文后,告诉Client端,“你的请求我收到了,但是我还没准备好,请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。
3、当Server
端确定数据已发送完成,则向Client端发送FIN报文。告诉Client端,”好了,我这边数据发完了,准备好关闭连接了”。
4、Client
端收到FIN报文后,就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。Server端收到ACK后,就知道可以断开连接了。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那Client端也可以关闭连接了。
这就是TCP四次挥手断开连接。
问题
一、为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
二、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间Maximum Segment Lifetime)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
HTTPS协议
HTTPS(Hypertext Transfer Protocol over Secure Socket Layer,基于SSL的HTTP协议)使用了HTTP协议,但HTTPS使用不同于HTTP协议的默认端口及一个加密、身份验证层(HTTP与TCP之间)。HTTPS是一个安全通信通道,用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换,简单来说它是HTTP的安全版。
- 内容加密:建立一个信息安全通道,来保证数据传输的安全;
- 身份认证:确认网站的真实性;
- 数据完整性:防止内容被第三方冒充或者篡改;
加密算法
对称加密
有流式、分组两种。加密和解密都是使用的同一个密钥。
例如:DES、AES-GCM、ChaCha20-Poly1305等。
非对称加密
加密使用的密钥和解密使用的密钥是不相同的,分别称为:公钥、私钥,公钥的算法是公开的,私钥是保密的。非对称加密算法性能较低,但是安全性超强,由于其加密特性,非对称加密算法能加密的数据长度也是有限的。
例如:RSA、DSA、ECDSA、 DH、ECDHE。
哈希算法
将任意长度的信息转换为较短的固定长度的值,通常其长度要比信息小得多,且算法不可逆。
例如:MD5、SHA-1、SHA-2、SHA-256 等
数字签名
签名就是在信息的后面再加上一段内容(信息经过hash后的值),可以证明信息没有被修改过。hash值一般都会加密后(也就是签名)再和信息一起发送,以保证这个hash值不被修改。
请求过程
HTTPS其实是有两部分组成:HTTP + SSL/TLS,也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。
客户端发起HTTPS请求
用户在浏览器里输入一个https网址,连接到server的443端口。
服务端配置
采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。
传送证书
这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。
客户端解析证书
这部分工作是有客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。
传送加密信息
这部分传送的是用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
服务端解密信息
服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。
传输加密后的信息
这部分信息是服务段用私钥加密后的信息,可以在客户端被还原。
客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。
总结
HTTPS请求连接的全过程可简化理解为:客户端拿到服务端非对称加密的公钥验证其身份后,将对称加密的私钥通过非对称加密的公钥加密后传输给服务端,服务端通过非对称加密的私钥解密后得到对称加密的私钥,其后客户端和服务端通过对称加密的私钥对数据进行加密传输。
相比 HTTP 协议,HTTPS 协议增加了很多握手、加密解密等流程,虽然过程很复杂,但其可以保证数据传输的安全。然而,加密和解密过程需要耗费系统大量的开销,严重降低机器的性能,相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。所谓鱼与熊掌不可兼得,适当的选择HTTP和HTTPS协议非常重要。