https S 代表的是SSL/TLS

先做个尝试： 在浏览器的地点栏上输入 http:\\  

用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 详细解析 （超详细，半小时搞懂HTTPS）