Https工作原理

一.简介

HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议 它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用 TLS/SSL 加密的 HTTP 协议。
HTTP 协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议 TLS/SSL 具有身份验证、信息加密和完整性校验的功能，可以避免此类问题。
TLS/SSL 全称安全传输层协议 Transport Layer Security, 是介于 TCP 和 HTTP 之间的一层安全协议，不影响原有的 TCP 协议和 HTTP 协议，所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造。

二.http的问题

由于http使用明文传输，可以使用软件抓包。容易被劫持。

三.加密方式

Https加密通信有两种加密，一种是非对称加密，另一种是对称加密。

非对称加密，就是加密和解密的秘钥不同，一个私钥一个公钥，公钥加密，私钥解密，你访问某https站点时，是可以知道这个站点的公钥的。公钥进行加密，而解密是只能用私钥进行解密，而私钥是握在站点手里的，只有该站点可以知道，显然，这样的安全性很高，但有个很严重的问题就是，非对称解密相当损耗CPU性能，全部内容都用非对称加密交流性能大大下降。

对称加密，就是加密和解密都是用的同一个秘钥，加密和解密都很快，在不知道秘钥的情况下，想要破解的难度也非常大，比非对称加密破解还要难。但有个问题就是，如果用对称秘钥的话，在第一次握手协商秘钥的时候，很可能就已经被劫持，这时你的加密也就毫无安全性可言了。

四.https握手的过程详细描述

1 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端

2  服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法

   以证书的形式返回给客户端，证书里面包含了 网站公钥+各种信息+签名（CA机构的私钥对各种信息加密后生成签名）。

3 客户端收到服务端响应后会做以下几件事

    3.1 验证证书的合法性    

　　  3.1.1 颁发证书的机构是否合法与是否过期，网站证书中包含的网站地址是否与正在访问的地址一致

         3.1.2 公钥加密，私钥解，私钥加密公钥也可以解。CA证书会在操作系统安装时就安装好，所以每个人电脑上都有根证书，使用CA证书中带的公钥来对网站证书的签名进行解密，然后和证书中的各种信息做比较就可以校验出证书的合法性

        3.1.3 证书验证通过后，在浏览器的地址栏会加上一把小锁

   3.2 生成随机密码

        如果证书验证通过，或者用户接受了不授信的证书，此时浏览器会生成一串随机数，然后用证书中的公钥加密。 　　　　　　

    3.3 HASH握手信息

       用最开始约定好的HASH方式，把握手消息取HASH值，  然后用随机数加密 “握手消息+握手消息HASH值(签名)”  并一起发送给服务端

       在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。

最终发送给服务端的消息密文组成：公钥加密的（随机数+随机数加密的（握手消息+握手消息HASH值））

4  服务端拿到客户端传来的密文，用自己的私钥来解密取出随机数密码，再用随机数密码解密握手消息与HASH值，将握手消息用约定的HASH方式取HASH值，并与传过来的HASH值做对比确认是否一致。

    然后用随机数密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端

5  客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机数密码并利用对称加密算法进行加密  

     因为这串随机数密钥只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全

那么这里再推理几种情况能不能破解这个校验方案：

中间人攻击第一波

客户端say hello 后，被代理服务器拦截，然后他再向我们真正的服务器发相同的say hello，这时候服务器不知道你是谁，给了代理服务器公开密钥证书，然后代理服务器再把证书转发给客户端，客户端校验没毛病，然后用公钥加密的随机字符串发给代码服务器，这个时候代理服务器懵逼了，因为他没有私钥，解密不到随机字符串到底是什么，好吧，他虽然看不懂，但是还是把这一坨东西原封不动的给了服务器，服务器一看，没毛病，再把加密信息给代理服务器，代理服务器，因为不知道刚才的随机字符串是什么，而这个时候客户端和服务器已经不再使用公钥加密，而是使用了共享密钥加密，而关键的关键就是密钥就是刚才的随机字符串。代理服务器再次懵逼，就看数据来来回回，可是他看不懂，这样的中间人，只能算蠢萌的中转人，这也就是使用了HTTPS之后，packetCapture截取到的数据都是乱码的原因，关于这个可以参考这里。

中间人攻击第二波

客户端say hello 后，被代理服务器拦截，代理服务器也有CA颁发的证书，他把自己的合法证书发给客户端，客户端用证书里面的公钥解密签名之后，得到了各种信息，一看信息都对上了，没毛病信任。然后代理服务器宰相真正的服务器say hello，服务器下发真正的证书，代理服务器假装自己是客户端，信任了证书，然后校验通过，发用真正公钥加密后的随机数给服务器，服务器当然能解开，也就是代理服务器作为客户端和真正的服务器建立了合法的通信。再看客户端在校验了代理服务器自己的证书后也建立了合法的通信，这个时候，代理服务器作为中间人，因为他有自己的私钥和真正的公钥，可以欺上瞒下，俩边的信息都从它这里过了一次，信息被他偷窥到。攻击成功。

怎么防御？

客户端内置真正的公钥，当代理服务器把它自己的证书传过来的时候，客户端用内置的公钥去解密证书中的签名，因为不是真正的私钥加密的所以解密失败，校验也就失败，连接中断。这也就是客户端信任所有的证书的风险—被中间人攻击。

参考：

http://blog.csdn.net/jogger_ling/article/details/60576625

https://www.cnblogs.com/zery/p/5164795.html