HTTPS 详细解析 （超详细，半小时搞懂HTTPS）

https S 代表的是SSL/TLS

先做个实验： 在浏览器的地址栏上输入 http:\\www.meituan.com  

用http header LIVE  抓个包如下

过程如下：

浏览器先以HTTP协议来连接服务器。服务器因配置了HTTPS，所以使用了302跳转至https页面，浏览器再去连接服务器的443端口。

上述小实验只是https步骤的第一步 ，接下来先进行TCP三次握手，然后进行SSL/TLS四次握手

接下来就是难点了。再讲难点之前，先讲难点细分讨论  

什么是对称加密

只有一个密钥，它可以对内容进行加密，也可以用该密钥对密文进行解密。

但问题来了，密钥如何保护呢？  

什么是公钥加密  (非对称加密)

有两把密钥，一把公钥，一把私钥，公钥加密的内容必须用私钥才能解开，私钥加密的内容必须用公钥解开

单个公钥私钥，只能保障单方向的安全性，为什么这么说呢

服务器将他的公钥明文发送给浏览器，浏览器将数据用公钥加密发给服务器，只有服务器有私钥可以查看数据。

服务器将数据用私钥加密发送给浏览器，浏览器用公钥解密

想想看，公钥是一开始是明文传输的，意味着只要截获了公钥就可以查看服务器发送的消息，那怎样可以保障双方向的通信安全呢？

服务器一对公钥私钥，浏览器一对公钥私钥

服务器明文传输自己的公钥A给浏览器，浏览器明文传输自己的公钥B给服务器

以后浏览器给服务器发送的数据都用公钥A加密，服务器给浏览器发送的数据用公钥B加密，这样就保障了双向通信的安全性

但非对称性加密非常耗时，如何解决呢 ？

对称加密+非对称加密结合

浏览器用公钥A将自己的对称密钥X发送给服务器

服务器用私钥A解密获得对称密钥X

双方用对称密钥X进行数据交换

这样看起来很安全，但其实还要一个小问题

在发送自己的公钥给对面时，有个中间人截获双方的公钥，并且把自己的公钥发送给浏览器和服务器

这时候中间人就可以收到用中间人的公钥加密的对称密钥X，这样看来，还是很危险，客户端根本不知道接受的公钥是否可信

数字证书

数字证书是网站的身份证，有了证书就可以证明该网站的合法性；

网站在使用HTTPS之前，需要向CA机构申请一份数字证书，数字证书里有持有者和网站公钥的信息，服务器只需要把证书传给浏览器即可

但如何证明证书的真伪性呢？

数字签名

把证书的内容生成一份签名，对比证书的内容和签名是否一致

签名如何制作呢： 将证书的明文信息用hash函数加密一次得到一个固定长度的序列，称消息摘要，哈希值，然后CA用私钥进行加密得数字签名   明文和数字签名组成数字证书

如何验证呢：用CA机构的公钥对数字签名进行解密，得到哈希值，用证书里的hash算法对证书明文进行hash ，查看两次得到的hash是否相同

CA公钥是否可信？

操作系统，浏览器会默认安装信任的证书，证书里包含信任的公钥

现在来理解一下四次握手：

1.创建一个属于浏览器与服务器之间的session，避免多次重复验证

2.服务器将自己的证书发送给浏览器

3.浏览器发送对称密钥给服务器

4.安全的会话建立，数据采用私钥加密

https中涉及的数据包

client hello报文：

TSL版本

SID（session id）：保持会话；扩展：不过只保留在一台服务器上，如果请求域名的流量很大的时候，往往右很多的服务器提供服务，就无法恢复对话。采用session ticket

密文族：密钥交换算法-对称加密算法-哈希算法

server_name：请求访问的域名

服务器在收到client hello报文后，会回复三个数据包

server hello：session id 、选择的密文族、选择的TSL版本

Certificate报文：服务器的数字证书

server hello done 和server key exchange

客户端验证证书的真伪： 根据数字签名

密钥交换：客户端通过服务器的证书将非对称加密的密钥发送给服务器

到此建立TSL连接结束了 ，其中还要很多细节之处由于水平有限，未能提出