HTTPS工作原理和TCP握手机制

矫情吗；* 2022-04-11 05:56 208阅读 0赞

转自  
\[url\]http://www.admin5.com/article/20150523/600105.shtml\[/url\]  
\[url\]http://www.admin5.com/article/20150525/600230.shtml\[/url\]  
  
\[b\]1、HTTPS的工作原理\[/b\]  
　　HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的具体描述如下：  
　　1.浏览器将自己支持的一套加密规则发送给网站。  
  
　　2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。  
  
　　3.浏览器获得网站证书之后浏览器要做以下工作：  
　　a) 验证证书的合法性(颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等)，如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。  
　　b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。  
　　c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。  
  
　　4.网站接收浏览器发来的数据之后要做以下的操作：  
　　a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。  
　　b) 使用密码加密一段握手消息，发送给浏览器。  
  
　　5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。 这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：  
　　非对称加密算法：RSA，DSA/DSS  
　　对称加密算法：AES，RC4，3DES  
　　HASH算法：MD5，SHA1，SHA256 HTTPS对应的通信时序图如下：  
\[align=center\]\[img\]http://upload.admin5.com/2015/0525/1432517989667.png\[/img\]\[/align\]  
  
HTTPS协议和HTTP协议的区别： (具体HTTP协议的介绍可见参考资料2)  
　　\[color=red\]https协议需要到ca申请证书，一般免费证书很少，需要交费。  
　　http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。  
　　http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。  
　　http的连接很简单,是无状态的 。  
　　HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议， 要比http协议安全。\[/color\]  
　　  
\[b\] 2、TCP3次握手，4次挥手过程\[/b\]  
　　1、建立连接协议(三次握手)  
　　(1)客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。  
　　(2)服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应;同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。  
　　(3)客户必须再次回应服务段一个ACK报文，这是报文段3。  
\[align=center\]\[img\]http://upload.admin5.com/2015/0525/1432517989407.png\[/img\]\[/align\]  
  
  
为什么需要“三次握手”  
　　在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。  
　　谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。 主要目的防止server端一直等待，浪费资源。  
　　2、连接终止协议(四次挥手)  
　　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。  
　　(1) TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送(报文段4)。  
　　(2) 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1(报文段5)。和SYN一样，一个FIN将占用一个序号。  
　　(3) 服务器关闭客户端的连接，发送一个FIN给客户端(报文段6)。  
　　(4) 客户段发回ACK报文确认，并将确认序号设置为收到序号加1(报文段7)。  
\[align=center\]\[img\]http://upload.admin5.com/2015/0525/1432517989232.png\[/img\]\[/align\]  
  
  
为什么需要“四次挥手”  
　　那可能有人会有疑问，在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。  
　　握手，挥手过程中各状态介绍(详见wiki：TCP)  
　　3次握手过程状态：  
　　LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。  
　　SYN\_SENT: 当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN\_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN\_SENT状态表示客户端已发送SYN报文。(发送端)  
　　SYN\_RCVD: 这个状态与SYN\_SENT遥想呼应这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。(服务器端)  
　　ESTABLISHED：这个容易理解了，表示连接已经建立了。  
　　4次挥手过程状态：(可参考上图)  
　　FIN\_WAIT\_1: 这个状态要好好解释一下，其实FIN\_WAIT\_1和FIN\_WAIT\_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN\_WAIT\_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN\_WAIT\_1状态。而当对方回应ACK报文后，则进入到FIN\_WAIT\_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN\_WAIT\_1状态一般是比较难见到的，而FIN\_WAIT\_2状态还有时常常可以用netstat看到。(主动方)  
　　FIN\_WAIT\_2：上面已经详细解释了这种状态，实际上FIN\_WAIT\_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。(主动方)  
　　TIME\_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN\_WAIT\_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME\_WAIT状态，而无须经过FIN\_WAIT\_2状态。(主动方)  
　　CLOSING(比较少见): 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到(或同时收到)对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。  
　　CLOSE\_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE\_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE\_WAIT状态下，需要完成的事情是等待你去关闭连接。(被动方)  
　　LAST\_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。(被动方)  
　　CLOSED: 表示连接中断。TCP的具体状态图可参考：  
\[url\]\[img\]http://upload.admin5.com/2015/0525/1432517989214.png\[/img\]\[/url\]  
  
  
\[align=center\]\[color=red\]\[size=medium\]\[b\]图解HTTPS\[/b\]\[/size\]\[/color\]\[/align\]  
我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。  
　　HTTPS简介  
　　HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。  
\[align=center\]\[img\]http://upload.admin5.com/2015/0523/1432369389705.png\[/img\]\[/align\]  
\[b\]1. 客户端发起HTTPS请求\[/b\]  
　　这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。  
  
　　\[b\]2. 服务端的配置\[/b\]  
　　采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。  
  
　　\[b\]3. 传送证书\[/b\]  
　　这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。  
  
　　\[b\]4. 客户端解析证书\[/b\]  
　　这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。  
  
　　\[b\]5. 传送加密信息\[/b\]  
　　这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。  
  
　　\[b\]6. 服务段解密信息\[/b\]  
　　服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。  
  
　　\[b\]7. 传输加密后的信息\[/b\]  
　　这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。  
  
　　\[b\]8. 客户端解密信息\[/b\]  
　　客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。