https是当前网络通信中保证传输消息安全的一种最为常用的协议，本文将阐述https的通信机制，道出其到底安全在哪。
https是在http上添加TLS/SSL层来保证信息在传输过程中的安全；这其中呢，主要包含三个关键技术：对称加密、非对称加密以及数字证书；
http协议中信息的传输是明文的，所以在传输过程中，攻击者可以捕获并窃取数据的内容；
为了防止攻击者在途中截取有效的数据，我们首先想到的就是对传输数据进行加密；一种常用的高级加密算法AES（Advanced Encryption Standard）应用于此；这是一种在计算机网络中很常用的对称加密算法，对称加密算法需要通信双方使用相同的密钥对传输信息进行加密和解密；
但是，接下来又有另一个问题，这个用于数据加解密的密钥如何让通信双方同时持有呢？如果将key（密钥）也通过明文传输过去，那么攻击者也将拿到这个密钥，之后对信息进行加密传输也就没什么意义了。
于是，https里面的另一个关键技术要登场了，那就是非对称加密。知道了对称加密是什么意思，那非对称这个就一目了然了。非对称加密算法会有两个密钥（key1/公钥、key2/私钥），用key1加密的数据，只有通过key2才能解密；同样，通过key2加密的数据只能通过key1进行解密。RSA就是一种常用的非对称加密算法。
继续回到AB两端通信这个场景，我们现在使用RSA生成的两个密钥key1、key2来解决之前明文传输AES密钥key的问题；步骤如下：
- 通过RSA算法生成一对密钥key1、key2；B要和A进行通信，A将key1传递给
- B将AES的密钥key用key1进行加密，发给A；攻击虽然可以截获key1和加密的数据，但是key1加密的数据只能通过key2解密，所以数据还是安全的
-
A用手中的key2解密用key1加密的数据，得到key；接下来A和B便可以通过这个对称加密密钥来进行加密通信了
AES搭配RSA实现加密通信过程
到这边，有些可能会有些疑惑，为何要先用非对称加密去传递AES的key，然后再用这个key进行加密传输？为何不直接使用RSA进行加密传输呢？
这是因为RSA加解密的耗时较长，如果传输消息使用非对称加密，那么信息传输的时间消耗将会较大；但是AES的耗时较小，所以我们通过RSA来保证AES密钥的安全传递，这样既保证了数据传输过程的安全，又避免不会在数据加解密上消耗太多时间。有兴趣的同学可以再去深究下RSA算法原理。
到这边可以圆满大结局了么？还不行。这样还是挡不住中间人攻击。现在来看下这样一个场景：
- B向A发起https请求，通过RSA算法生成一对密钥key1、key2
- A将key1发送给B，中间人出现，将key1截断
- 中间人自己通过RSA算法生成另一对密钥fakeKey1、fakeKey2，将fakeKey1发送给B
- B误以为fakeKey1这是A发来的密钥key1，用fakeKey1对key进行加密传递出去
- 中间人拦截加密数据，用fakeKey2解密出fakeKey1加密的key；至此，中间人已经获取AB之间通信使用的对称密钥key
- 中间人将获得的key，再通过key1进行加密发送给A；A误以为和B完成了密钥key的交换
-
AB使用对称密钥key进行加密通信，中间人也知道这个key，所以~~
中间人攻击
到这，仿佛陷入了死局，怎么搞？
https最后一个关键技术数字证书，这时候就要登场了。
我们在上面遇到的问题：无法确认传过来的公钥是否为A的传的公钥，可能在传输途中被换包或者篡改；数字证书就是要用来解决这个问题的。
站点首先将自己的通信公钥以及站点身份等信息合成一份申请，递交给权威的证书颁发机构CA（certificate authority）；这份申请，叫做CSR（Certificate signing request）
)。这个CSR主要包含就是站点的公钥以及申请方的各类信息。
CA拿到这份信息后，跟根据约定的规范格式通过hash算法，生成内容的散列值；然后通过CA的私钥对这段散列值进行加密，生成数字签名DA（Digital Signature）；最后将站点的CSR和这段CSR的数字签名合在一起，成为颁发给站点的数字证书DC(Digital Certificate)。
现在站点拥有了CA认证的公钥证书，有浏览器想跟站点进行https通信时，站点会将自己的公钥证书发给浏览器；浏览器会使用已植入在内的CA公钥解密证书的签名，得到站点CSR的hash值，然后浏览器用CRS部分算一个hash值， 将解密后的hash值进行比较；相等则认证通过，证书中的公钥为站点的公钥；不相等，则认证失败，提示用户站点存在风险。
至此，我们已经安全的获得了站点的公钥，之后就可以按照文章上半部分所写的那样，进行https协议通信了
