SSL/TLS工做原理

之前已经介绍过HTTP协议和HTTPS协议的区别，此次就来了解一下HTTPS协议的加密原理。

为了保证网络通讯的安全性，须要对网络上传递的数据进行加密。如今主流的加密方法就是SSL (Secure Socket Layer)，TLS (Transport Layer Security)。后者比前者要新一些，不过在不少场合仍是用SSL指代SSL和TLS。先来回顾一下网络通讯加密的发展过程，假设A和B之间要网络通讯。

上古时代
随着时代的发展，渐渐的有了一类人---C。C不只会监听A和B之间的网络数据，还会拦截A和B之间的数据，伪造以后再发给A或者B，进而欺骗A和B。C就是中间人攻击（Man In The Middle Attack）。为了应对C的攻击，A和B开始对本身的数据进行加密。A和B会使用一个共享的密钥，A在发送数据以前，用这个密钥对数据加密。B在收到数据以后，用这个密钥对数据解密。由于加密解密用的是同一个密钥，因此这里的加密算法称为对称加密算法。

在1981年，DES（Data Encryption Standard）被提出，这是一种对称加密算法。DES使用一个56bit的密钥，来完成数据的加解密。尽管56bit看起来有点短，但时间毕竟是在上古时代，56bit已经够用了。就这样，网络数据的加密开始了。由于采用了DES，A和B如今不用担忧数据被C拦截了。由于就算C拦截了，也只能获取加密以后的数据， 没有密钥就没有办法获取原始数据。可是A和B之间又有了一个新的问题，他们须要一个共享的56bit密钥，而且这个密钥必定要保持私密，不然被C拿到了，就没有加密的意义了。首先AB不能经过网络来传递密钥，由于密钥肯定之前，全部的网络通讯都是不安全。若是经过网络传递密钥，密钥有可能被拦截。拦截了就没有加密的意义了。为了安全，A和B只能先见一面，私下商量好密钥，这样C就没办法获取密钥。若是由于任何缘由，以前的密钥泄露了，那么AB还得再见一面，从新商量一个密钥。如今A和B之间，最私密的信息就是这个密钥了，只要保证密钥的安全，那么AB之间整个网络通讯都是安全的。

中古时代
A和B当心的保护着密钥，不让C知道。可是道高一尺，魔高一丈。随着技术的发展，计算机速度变得很快，快到能够经过暴力破解的方法来解密通过DES加密的信息。不就是56bit的密钥吗？C找了一个好点的计算机，尝试每个可能的值，这样总能找到一个密钥破解A和B之间的加密信息。倒不是说DES在提出时没有考虑过这种状况，只是在上古时代，计算机没这么快，破解56bit的密钥须要的时间很是长。可是如今是中古时代，可能只须要几天就能够破解56bit的密钥。为了应对这个状况，新的协议被提出，例如triple-DES（最长168bit的密钥），AES（最高256bit的密钥）。通过这些改进，至少在能够预见的将来，计算机是没有办法在有限的时间内，暴力破解这个长度的密钥。因此，在中古时代，将对称加密算法的密钥长度变长，来应对中间人攻击。可是A和B仍是须要见面商量一个密钥。

现代
非对称加密

时间到了现代。网络通讯变得十分发达，A不仅与B通讯，还同时还跟其余10000我的进行网络通讯。A不可能每一个人都跑去跟他们见个面，商量一个密钥。

因此一种新的加密算法被提出，这就是非对称加密算法。非对称加密使用两个密钥，一个是public key，一个是private key。经过一个特殊的数学算法，使得数据的加密和解密使用不一样的密钥。由于用的是不一样的密钥，因此称为非对称加密。非对称加密最著名的是RSA算法，这是以其发明者Rivest, Shamir 和Adleman命名。非对称加密算法里面的public key和private key在数学上是相关的，这样才能用一个加密，用另外一个解密。不过，尽管是相关的，但以现有的数学算法，又没有办法从一个密钥，算出另外一个密钥。

非对称加密的好处在于，如今A能够保留private key，经过网络传递public key。这样，就算public key被C拦截了，由于没有private key，C仍是没有办法完成信息的破解。既然不怕C知道public key，那如今A和B不用再见面商量密钥，直接经过网络传递public key就行。

具体在使用中，A和B都各有一个public key和一个private key，这些key根据相应的算法已经生成好了。private key只保留在各自的本地，public key传给对方。A要给B发送网络数据，那么A先使用本身的private key（只有A知道）加密数据的hash值，以后再用B的public key加密数据。以后，A将加密的hash值和加密的数据再加一些其余的信息，发送给B。B收到了以后，先用本身的private key（只有B知道）解密数据，本地运算一个hash值，以后用A的public key解密hash值，对比两个hash值，以检验数据的完整性。

在这个过程当中，总共有4个密钥，分别是A的public/private key，和B的public/private key。若是B的解密结果符合预期，那么至少能够证实，这个信息只有B能获取，由于B的private key参与了解密，而B的private key其余人都不知道。而且，这个信息是来自A，而不是C伪造的，由于A的public key参与了解密。一切看起来彷佛很美好。

非对称加密的安全隐患

可是在一切的最开始，A和B要经过网络交换public key。若是C在中间拦截了呢？假设有这种状况，C拦截了A和B的public key，又分别用本身的public key发给A和B。A和B并不知道，他们还觉得这个public key来自对方。当A给B发消息时，A先用本身的private key加密数据的hash值，以后用C传来的假的public key加密数据，再发出去。C拦截到以后，先用C本身的private key解密数据，C就获取了A的原始信息！以后，C能够篡改数据内容，再用本身的private key加密数据的hash值，用以前拦截的B的public key加密数据，再发给B。B收到之后，先用本身的private key解密数据，再用C传来的假public key解密hash值，发现匹配。这样，B收到了一条来自C的假的信息，可是B还觉得信息来自于A。中间人攻击仍然可能存在！

完了，一切都崩了，加密搞的这么复杂，竟然还不能保证网络数据的安全。回顾一下，问题出就出在最开始经过网络交换public key。看起来为了保证public key不被拦截，A和B彷佛仍是要见一面，交换一下public key。这一下就回到了上古时代。

不过，虽然A和B如今仍是要见一面，但见面的实质已经变了。在上古时代，见面是为了商量一个密钥，密钥的内容很重要，不能让别人知道密钥的内容。而在现代，见面是为了确认public key的真实性，public key的内容是能够公开的。

那若是有其余办法能保证public key的真实性，A和B是能够不用见面交换public key的。

CA

现实中，经过CA（Certificate Authority）来保证public key的真实性。CA也是基于非对称加密算法来工做。有了CA，B会先把本身的public key（和一些其余信息）交给CA。CA用本身的private key加密这些数据，加密完的数据称为B的数字证书。如今B要向A传递public key，B传递的是CA加密以后的数字证书。A收到之后，会经过CA发布的CA证书（包含了CA的public key），来解密B的数字证书，从而得到B的public key。

可是等等，A怎么确保CA证书不被劫持。C彻底能够把一个假的CA证书发给A，进而欺骗A。CA的大杀器就是，CA把本身的CA证书集成在了浏览器和操做系统里面。A拿到浏览器或者操做系统的时候，已经有了CA证书，没有必要经过网络获取，那天然也不存在劫持的问题。

如今A和B都有了CA认证的数字证书。在交换public key的阶段，直接交换彼此的数字证书就行。而中间人C，仍是能够拦截A和B的public key，也能够用CA证书解密得到A和B的public key。可是，C没有办法伪造public key了。由于C不在CA体系里面，C没有CA的private key，因此C是没有办法伪造出一个能够经过CA认证的数字证书。若是不能经过CA认证，A和B天然也不会相信这个伪造的证书。因此，采用CA认证之后，A和B的public key的真实性获得了保证，A和B能够经过网络交换public key（实际是被CA加密以后的数字证书）。

除非有种状况，A内置的CA证书被篡改了，例如A使用了盗版的系统，“优化”了的非官方浏览器，或者被病毒攻击了，那这个时候，A有可能会承认非CA认证的数字证书，C就有机会发起中间人攻击。因此，用正版至少是安全的。

实际使用

非对称加密算法比对称加密算法要复杂的多，处理起来也要慢得多。若是全部的网络数据都用非对称加密算法来加密，那效率会很低。因此在实际中，非对称加密只会用来传递一条信息，那就是用于对称加密的密钥。当用于对称加密的密钥肯定了，A和B仍是经过对称加密算法进行网络通讯。这样，既保证了网络通讯的安全性，又不影响效率，A和B也不用见面商量密钥了。

因此，在现代，A和B之间要进行安全，省心的网络通讯，须要通过如下几个步骤

经过CA体系交换public key
经过非对称加密算法，交换用于对称加密的密钥
经过对称加密算法，加密正常的网络通讯
这基本就是SSL/TLS的工做过程了。

HTTPS

HTTPS全称是HTTP over SSL，也就是经过SSL/TLS加密HTTP数据，这或许是SSL最普遍的应用。

前面提到了CA做为一个公证机构，能确保数字证书的真实性。可是在实际使用中，CA认证通常是要收费的，普通人不会去作CA认证，进而得到属于本身的数字证书。更多的是，一些大的机构，例如银行，网店，金融机构，它们去得到本身的数字证书。那这种状况如何保证网络通讯的安全呢？

这些机构获取到CA授予的数字证书以后，将数字证书加到本身的web服务器上。当用户要去访问它们的网页，例如https://domain.com，会通过下图所示的步骤。

用户向web服务器发起一个安全链接的请求
服务器返回通过CA认证的数字证书，证书里面包含了服务器的public key
用户拿到数字证书，用本身浏览器内置的CA证书解密获得服务器的public key
用户用服务器的public key加密一个用于接下来的对称加密算法的密钥，传给web服务器
由于只有服务器有private key能够解密，因此不用担忧中间人拦截这个加密的密钥
服务器拿到这个加密的密钥，解密获取密钥，再使用对称加密算法，和用户完成接下来的网络通讯
如今用户知道本身访问的网站是正规的网站，不然用户浏览器会报错说不能用CA证书解析。服务器经过CA授予的数字证书自证了身份。但，这里的安全隐患在于，服务器怎么知道访问者就是真用户呢？以前介绍的双向认证是能够经过数字证书验明用户的正身，如今用户为了省钱没有数字证书。这种状况下通常是经过用户名密码来确认用户。因此，你们要保管好本身的密码。
本文转载自：https://zhuanlan.zhihu.com/p/36981565