网站不支持https是什么意思（啥都玫说之网络篇-9.2这个协议叫啥）

前边已经铺垫好了，现在开始说说这个章节主要说的内容SSL/TLS。

SSL，是英文Secure Sockets Layer的缩写，中文叫做“安全套接层”。它是在20世纪90年代中期，由网景公司设计的。顺便插一句，网景公司不光发明了SSL，还发明了很多Web的基础设施，比如CSS样式表和JavaScript。

为啥要发明SSL这个协议？因为原始的HTTP协议是明文的，存在很多缺点，比如传输内容会被偷窥（嗅探）和篡改。发明SSL协议，就是为了解决这些问题。到了1999年，SSL因为应用广泛，已经成为事实标准。IETF就在那年把SSL标准化。标准化之后的名称改为TLS是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。很多相关的文章都把这两者并列称呼，也就是SSL/TLS，因为这两者可以视作同一个东西的不同阶段，所以大多数文章也只写SSL。

解释完HTTP和SSL/TLS，现在就可以来解释HTTPS啦。咱们通常所说的HTTPS协议，说白了就是“HTTP协议”和“SSL/TLS协议”的组合。可以把HTTPS大致理解为“HTTP over SSL”或“HTTP over TLS”，反正SSL和TLS差不多。

SSL具有以下有点：

• [x] 提供较高的安全性保证：SSL利用数据加密、身份验证和消息完整性验证机制。保证网络上传输数据的安全性。
• [x] 支持各种应用层协议：尽管SSL设计的初衷是为了解决万维网安全性问题，可是因为SSL位于应用层和传输层之间。它能够为不论什么基于TCP等可靠连接的应用层协议提供安全性保证。
• [x] 部署简单：眼下SSL已经成为网络中用来鉴别站点和网页浏览者身份，在浏览器使用者及Webserver之间进行加密通信的全球化标准。SSL协议已被集成到大部分的浏览器中，这就意味着差点儿随意一台装有浏览器的计算机都支持SSL连接。不须要安装额外的client软件。

SSL协议实现的安全机制包含：

• [x] 传输数据的机密性：利用对称密钥算法对传输的数据进行加密。
• [x] 身份验证机制：基于证书利用数字签名方法对server和client进行身份验证，当中client的身份验证是可选的。
• [x] 消息完整性验证：消息传输过程中使用MAC算法来检验消息的完整性。

这就是SSL的结构，在图中可以看到，SSL位于TCP\/IP协议的应用层和传输层之间，它能够为不论什么基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议本身分为两层：

• [x] 上层为SSL握手协议（SSL handshake protocol）、SSLpassword变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）。
• [x] 底层为SSL记录协议（SSL record protocol）。

其中：

• [x] SSL握手协议：是SSL协议很重要的组成部分。用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在server和client之间安全地交换密钥、实现server和client的身份验证。
• [x] SSLpassword变化协议：client和server端通过password变化协议通知对端。随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
• [x] SSL警告协议：用来向通信对端报告告警信息，消息中包括告警的严重级别和描写叙述。
• [x] SSL记录协议：主要负责对上层的数据（SSL握手协议、SSLpassword变化协议、SSL警告协议和应用层协议报文）进行分块、计算并加入MAC值、加密。并把处理后的记录块传输给对端。

这张图就说明了包括服务端和客户端电子证书请求认证的过程。SSL通过握手过程在client和server之间协商会话參数，并建立会话。会话包括的主要參数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将採用该会话的主密钥和加密套件进行加密、计算MAC等处理。不同情况下，SSL握手过程存在差异。可以叙述为下三种情况下的握手过程：

• [x] 仅仅验证server的SSL握手过程
• [x] 验证server和client的SSL握手过程
• [x] 恢复原有会话的SSL握手过程

仅仅验证server的SSL握手过程，仅仅须要验证SSLserver身份，不须要验证SSLclient身份时，SSL的握手过程为：

• [x] SSLclient通过Client Hello消息将它支持的SSL版本号、加密算法、密钥交换算法、MAC算法等信息发送给SSLserver。
• [x] SSLserver确定本次通信採用的SSL版本号和加密套件，并通过Server Hello消息通知给SSLclient。假设SSLserver同意SSLclient在以后的通信中重用本次会话，则SSLserver会为本次会话分配会话ID。并通过Server Hello消息发送给SSLclient。
• [x] SSLserver将携带自己公钥信息的数字证书通过Certificate消息发送给SSLclient。
• [x] SSLserver发送Server Hello Done消息。通知SSLclient版本号和加密套件协商结束。開始进行密钥交换。
• [x] SSLclient验证SSLserver的证书合法后，利用证书中的公钥加密SSLclient随机生成的premaster secret，并通过Client Key Exchange消息发送给SSLserver。
• [x] SSLclient发送Change Cipher Spec消息，通知SSLserver兴许报文将採用协商好的密钥和加密套件进行加密和MAC计算。
• [x] SSLclient计算已交互的握手消息（除Change Cipher Spec消息外全部已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSLserver。SSLserver利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比較，假设二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
• [x] 相同地。SSLserver发送Change Cipher Spec消息，通知SSLclient兴许报文将採用协商好的密钥和加密套件进行加密和MAC计算。
• [x] SSLserver计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSLclient。SSLclient利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比較，假设二者相同。且MAC值验证成功。则证明密钥和加密套件协商成功。

SSLclient接收到SSLserver发送的Finished消息后。假设解密成功，则能够推断SSLserver是数字证书的拥有者，即SSLserver身份验证成功，由于仅仅有拥有私钥的SSLserver才干从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSLclient对SSLserver的身份验证。

SSLclient的身份验证是可选的，由SSLserver决定是否验证SSLclient的身份。图中蓝色部分标识的内容所看到的，假设SSLserver验证SSLclient身份。则SSLserver和SSLclient除了交互“仅仅验证server的SSL握手过程”中的消息协商密钥和加密套件外，还须要进行下面操作：

• [x] SSLserver发送Certificate Request消息。请求SSLclient将其证书发送给SSLserver。
• [x] SSLclient通过Certificate消息将携带自己公钥的证书发送给SSLserver。SSLserver验证该证书的合法性。
• [x] SSLclient计算已交互的握手消息、主密钥的Hash值。利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSLserver。
• [x] SSLserver计算已交互的握手消息、主密钥的Hash值。利用SSLclient证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比較。假设二者同样，则SSLclient身份验证成功。

恢复原有会话的SSL握手过程，协商会话參数、建立会话的过程中。须要使用非对称密钥算法来加密密钥、验证通信对端的身份。计算量较大，占用了大量的系统资源。为了简化SSL握手过程。SSL同意重用已经协商过的会话，详细过程为：

• [x] SSLclient发送Client Hello消息，消息中的会话ID设置为计划重用的会话的ID。
• [x] SSLserver假设同意重用该会话，则通过在Server Hello消息中设置同样的会话ID来应答。这样，SSLclient和SSLserver就能够利用原有会话的密钥和加密套件。不必又一次协商。
• [x] SSLclient发送Change Cipher Spec消息，通知SSLserver兴许报文将採用原有会话的密钥和加密套件进行加密和MAC计算。
• [x] SSLclient计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSLserver，以便SSLserver推断密钥和加密套件是否正确。
• [x] 相同地。SSLserver发送Change Cipher Spec消息，通知SSLclient兴许报文将採用原有会话的密钥和加密套件进行加密和MAC计算。
• [x] SSLserver计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSLclient。以便SSLclient推断密钥和加密套件是否正确。

SSL说的差不多了，再说HTTPS。如果大家仔细观察过，或者有所了解，web服务存在HTTP和HTTPS两种通信方式，HTTP默认采用80作为通讯端口，对于传输采用不加密的方式，HTTPS默认采用443，对于传输的数据进行加密传输。目前主流的网站基本上开始默认采用HTTPS作为通信方式。顾名思义，HTTPS\=HTTP SSL，HTTPS是在HTTP的基础上加上了SSL保护，信息的加密过程就是在SSL中完成的。

• [x] client向server发送请求https://baidu.com，然后连接到server的443端口。
• [x] 服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。
• [x] 传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
• [x] 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（秘钥）。然后用证书对该随机值进行加密。
• [x] 传送加密信息，这部分传送的是用证书加密后的秘钥，目的就是让服务端得到这个秘钥，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
• [x] 服务段加密信息，服务端用私钥解密秘密秘钥，得到了客户端传过来的私钥，然后把内容通过该值进行对称加密。
• [x] 传输加密后的信息，这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
• [x] 客户端解密信息，客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容。

那么问题来了，怎么保证保证服务器给客户端下发的公钥是真正的公钥，而不是伪造的公钥呢？

其实数字证书包括了加密后服务器的公钥、权威机构的信息、服务器域名，还有经过CA私钥签名之后的证书内容（经过先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名），签名计算方法以及证书对应的域名。当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要，然后根据证书上描述的计算证书的方法计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被篡改过。因为攻击者虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后攻击者需要将证书重新加密，但是攻击者没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果攻击者强行乱修改证书，就会导致证书内容和证书签名不匹配。

那第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？（伪装服务端一样的配置）显然这个是不行的，因为当第三方攻击者去CA那边寻求认证的时候CA会要求其提供例如域名的whois信息、域名管理邮箱等证明你是服务端域名的拥有者，而第三方攻击者是无法提供这些信息所以他就是无法骗CA他拥有属于服务端的域名。

当然SSL还有其他的应用，比如SSH，VPN。HTTPS只不过是我们日常应用中最常见的一个。