HTTPS底层原理的奇妙探险

因为网站一直用的http，总给人一种不安全的感觉，所以最近想给网站升级成https。但是呢，升级https步骤还是挺多的，网站用的阿里云的服务器，可以直接申请免费版的证书。开放443端口后，改了下nginx的配置，然后一切就正常工作了。虽说做起来很简单，但是本人还是对https的底层原理非常感兴趣，想一探究竟。

导火索：

我在升级htttps的过程中，经历了如下的步骤，首先去阿里云后台申请了一个免费的数字证书，接着在我的nginx服务器开启443端口，并配置好ssl证书，然后重启就可以访问了。大致配置如下：

http {
  include       mime.types;
  default_type  application/octet-stream;
  sendfile        on;
  keepalive_timeout  65;
  server {
    #监听443端口
    listen 443;
    #你的域名
    server_name www.xxx.com; 
    ssl on;
    #ssl证书的pem文件路径
    ssl_certificate  /root/cer.pem;
    #ssl证书的key文件路径
    ssl_certificate_key /root/cer.key;
    location / {
    proxy_pass  http://公网地址:项目端口号;
    }
  }
  server {
    listen 80;
    server_name www.xxx.com;
    #将请求转成https
    rewrite ^(.*)$ https://$host$1 permanent;
  }
}

从CA申请的证书包括一个pem文件和一个key文件，第一步探索一下这两个文件。

PEM文件里面装着如下信息，可以看到这是一个Certification文件，里面是base64编码。

-----BEGIN CERTIFICATE-----
MEUCIBCSxVxwBZL5FBVop5c2/JyCYqxUhdWS23HEW1SJCah2AiEAxZ+bI1zNYKZg
66oUmIAbkPh+ID/rnxmxwJ23F+pfc5EAdgCHdb/nWXz4jEOZX73zbv9WjUdWNv9K
tWDBtOr/XqCDDwAAAWcDk6Z6AAAEAwBHMEUCICw04SvauCz8UUWxiozmZ7tUhbaA
J7VIqOUT/tfjRuTSAiEAoyuYB7e/pkOiCkoVrJBFcaihrAPse/ts98xyQH0vsUIw
......
DQYJKoZIhvcNAQELBQADggEBAIsWG24SkYCw0/wf7uMsctYyAtZjaww5gKupOTqz
VLE97jaleLTv3Xsvghw/TJjuz5icUCD7Jcs5oofFZIVndlnHrWcK6LMRlQP/I1Eq
T3RbFI1LNkL2LXaCBoPt4TQWoYzkYfxvSyx9SYh140qO+t8hdeL9ZG0b+m7DN07k
n0vGKKnRzkpMT0Q8GdWGQPu07W3YNTCYZy7BqkVBJVUxoQzQSWWYzNJ+P4rpvUrt
uKr1iiwzKjf9T7G34G6gtjchKp58LPKTpVcptefYuX47XA3PW3SfBxF1YKVSBwZo
RN7xu94YEVKDq712D5uN+4e7/LR5uPMW3t7wzDswMk90rUY=
-----END CERTIFICATE-----

KEY文件如下，根据注释可以看出，他装着一个RSA 私钥的base64编码

-----BEGIN RSA PRIVATE KEY-----
GgvrZxKJOBukLYs78rXh0nV0w83assJnHuTxOGkCgYEAvo+o8qzp9hijchhWPTml
RNZFA6p62JMZ6AvkM3WnzdVp0AQ1dGTQWdDGYHHZIbhS2iJBIDHo2mcSqoHD87l6
7cRssYFN2xQ0HYOjBJfTerKxgZXgMrr3aE87jU9gzJHmk7euB0p+7JJIE8qA2v9p
fjhkx62UO38e9yI7dvsEi+0CgYADLp2G3pY4GyTAXCnYUU2B/+cmnEaanvgpOGL7
....
nB3aUw6HmlLl3JDCqVahHkttxEh3Gzm1g5QPrf9vW1d/6HJEb3QS6yPG4rNrB4GX
my/nhvvBNS9MGudL3pkUXNYVmsQF+yiLs+S8Ni/imwYv/GJcpAYb5VVfUE4CTGIJ
yst4yQKBgAgvBkMrmUNPBekBiugrcZA4brhxPdW3pe5bu2Fz75Ee3ZlywhITMiIn
G3uD5+b1sZMpIU5HkA3dml4rXASw00i2plMCeQS+gIZbR3QyVQcMZA88f2zQs0kb
KtUrwmdCdgbXqLGI/4pKNAlbPtJ3l/3RZ5zc1q5pq/cEiBOVwYK4
-----END RSA PRIVATE KEY-----

思考：

都说https让我们网站更安全，那就这样两个文件怎么保证https是安全可靠的呢？而且他们是怎么和浏览器配合工作的呢？带着诸多疑问，我们开始了https的探险之旅。

知识储备：

在开始探险之前我们需要先获得一些基本的生存技能，这些技能的理解和使用可以很好的帮助我们度过难关。

1）劫持者

也就是黑客，他能在你数据传输过程中把你数据拦截住，然后做些手脚发出去。因为你的数据想要到达目的地，中间会经过各种路由节点，比如wifi路由器。

2）加密算法

对称加密：张三通过一个密钥X（钥匙）加密一段数据（锁上门），然后发给李四。李四也有密钥X（配的相同的钥匙），李四可以用X解开张三发的加密消息，得到实际明文（打开门）。别人不知道密钥就解不开。

非对称加密：有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

数字摘要: 数字摘要是将任意长度的消息变成固定长度的短消息，它类似于一个自变量是消息的函数，也就是hash函数（SHA或MD5）。数字摘要就是采用单向Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。

数字签名：只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。

数字签名不是很好理解，下面举个例子就可以很清晰的理解：

张三从黑龙江给在新疆的李四发了一个信封，这个信封会经过很多人的手（运输）最后才到李四手里，怎么确保李四拿到手的信件没被别人串改呢？

前提： 张三手上有RSA非对称加密用的私钥，李四手上有公钥

1. 张三先把信件用SHA编码生成128位的数字摘要。
2. 张三接着用私钥来加密这个数字摘要。
3. 张三把加密后的数字摘要，信件都放在信封里，然后发出去
4. 李四收到信件之后，先用公钥解密加密后的数字摘要得到128位数字摘要，然后在把信件也用SHA编码生成128位的数字摘要，然后对比一下两个数字摘要是否一致，如果一致就说明信件没被动过手脚。

尝试篡改：来模拟一下劫持者能否串改信件，假如劫持者拿到信封了，他很惊喜发现加密后的数字摘要，件用都放在信封里，他开始搞事情了。

方案一：直接改完信件，发出去，肯定不行，李四收到了一顿验证，结果不一致，信件不被信任。

方案二：用劫持者生成自己的公私密钥，篡改信件，生成新的数字摘要，然后用自己私钥加密数字摘要得到加密后的数字摘要，把自己加密后的数字摘要，信件都放在信封里，然后发出去，李四拿到信件用自己的公钥解不出来，信件不被信任。

探索服务器和浏览器如何做到证书信任的和数据安全传输的

1）保证数据安全传输

浏览器和服务器之间如果每次发消息都用非对称加密，那么是特别耗时间（非对称加密算法非常耗时），那么可以采用对称加密（对称加密算法很快），那么现在只剩下一个问题，如何让对称加密的密钥只被浏览器和服务器知道，不允许第三方获得。

假如我们使用非对称加密算法来传递这样一个对称加密的密钥，看看能不能行？
1）服务器拥有公钥A和私钥a, 浏览器第一次请求的时候，服务器把公钥A发给浏览器，浏览器生成一个对称加密密钥X，然后用公钥A加密密钥X再发给服务器，服务器收到加密文件，用私钥a解出来就可以得到密钥X，这个时候不就只有双发知道了吗？

漏洞如下：劫持者拥有公钥B和私钥b，服务器往浏览器发送消息时，先劫持公钥A，然后替换为公钥B，发给浏览器，浏览器生成密钥X，用公钥B加密文件，发给服务器，劫持者拿到加密文件，用私钥b解出密钥X，然后再用公钥A加密密钥X，再发给浏览器，这样浏览器也可以用私钥a可以顺利解出X。双方都没有发现劫持者已经知道了密钥X，很危险。

2）想要安全传输数据，就要公钥不被劫持者篡改

那么怎么确保服务器发出去的公钥不被劫持者篡改呢？

这就用到我们上面所说的数字签名技术。

计算机默认会安装一些受信任机构CA颁发的根证书。服务器申请的证书当然也是CA颁发的，CA拥有绝对的权威。

接下来就是运输公钥A的问题了，可以结合上面张三李四用数字签名确保信封的例子来看：

CA给我们的证书文件：包括了公钥A和签名（先对公钥A进行Hash摘要，并用CA的私钥进行加密之后的加密摘要）。这个证书文件被发给了浏览器，浏览器收到了证书文件，先用系统存放CA颁发的证书的公钥去解密，得到摘要文件M1，然后再Hash公钥A得到摘要文件M2，对比M1和M2就知道公钥A有没有被篡改（验证签名），此时的公钥A就是受信任的。当然证书中也存放了域名，网站信息等，当劫持者用自己网站的CA颁发的证书B去做劫持，由于域名不一致而失败。

另外证书所存放的信息远远不止我们上面讲的那些，看图可以发现很多信息，而且证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。也就是CA颁发的证书（服务器的证书）被系统预装的证书（浏览器证书）所信任（一层层的找）。

至此，探索完毕，当然还有更多关于证书信任链的问题可以挖掘。