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连接结束了 ，其中还要很多细节之处由于水平有限，未能提出
原文地址：https://www.cnblogs.com/dhfblog/p/12115477.html