一, 开篇
啥是 HTTPS? 说白了就是 HTTP + SSL.HTTP 呢, 就是我们平时上网时, 浏览器和服务器之间传输数据的一项协议. 普通情况下, 浏览器发送的请求会经过若干个网络中间节点, 最后到达服务器; 然后服务器又将请求的数据经过若干个网络中间节点发送回给浏览器, 这时候浏览器就能够显示我们想要看到的页面.
这个过程中, 其实并没有存在什么太大的问题. 问题出在, 如果我们需要在网页上输入一些敏感信息, 如我们的银行卡账号和密码, 发送给服务器, 就会在中间节点中存在泄漏的风险. HTTPS 就是为了保障传输过程中的安全目的而生的. HTTPS 保证了数据仅仅只在发送方和目的方双方可见, 而对中间任一一个节点都不可见. 这是怎么实现的? 我们来慢慢看.
二, 故事
我们首先来看一个故事:
1)流程
有两个大师, 他们需要经常交流研究心得, 因此需要频繁地进行相互信件往来. 在信件往来的过程中, 我们假设发送方是大师 A, 而目的方是大师 B.A 想告诉 B 一些研究的最新成果, 于是将相关的研究成果写成了一封信, 从邮局邮寄给 B. 这封信通过邮局的若干个快递员, 最终到达了 B 的手里. 这样就形成了一个最典型的数据传输过程.
2)加密, 解密, 密钥, 加密算法
现在, 大师 A 觉得, 我写的这封信, 要是哪个快递员打开看过了, 我的最新研究成果不就泄漏了吗? 要是这个快递员拿去卖钱我半辈子努力不就白费了? 于是乎大师 A 就想了个办法, 在书写的过程中, 每个字符都加 4. 如字符 A 就写成 E, 字符 B 就写成 F, 以此类推. 大师 B 收到了信件后, 再把每个字符都减去 4, 这样就可以正确得到大师 A 想传递的研究成果的内容. 而最重要的是, 即使快递员在中间拆开信件, 如果不知道 4 这个数字, 是无法正确的到信件内容的.
我们将大师 A 每个字符加 4 的过程, 叫做 "加密"; 大师 B 每个字符减 4 的过程, 叫做 "解密"; 而数字 4, 就是我们常说的密钥. 而这种加密算法, 名为凯撒算法.
3)证书
就这样, 平安地度过了一段时间, 直到突然有一天大师 B 收到一封来自于大师 A 的信, 但是大师 B 使用之前的方式怎么也明白不了大师 A 说的是什么. 于是电话询问大师 A 关于这封信的内容. 结果大师 A 说, 这不是我写的啊. 这才发现, 大师 B 收到的是一封伪造大师 A 的来信. 为防止以上事情再次发生, 大师 A 与大师 B 商量说, 以后每封信上, 我都会签上自己特有的签名, 并带上相关内容的 HASH 值.
HASH 值用来校验这封信是否有被篡改过, 而签名类似于指纹, 用来标示这封信是否真实来自于指纹上所指向的人. 一般来说, 签名的内容中会包含这封信的发件方地址等信息. 大师 B 收到信件后第一时间通过内容的 HASH 值来校验信件的内容长度; 通过签名来校验发件方地址和指纹信息是否匹配. 只有全部匹配才继续用之前的密钥进行解密操作.
这些标明了大师 A 身份信息等信息的签名, 就是我们常说的证书.
经过以上的故事, 我们大致明白了密钥, 加密解密, 算法等必要的知识了. 而 HTTPS 的过程其实和这个类似, 只不过多了一些数学的描述.
三, HTTPS 工作原理
image
HTTPS 工作在客户端和服务器端之间. 以上故事中, 客户端可以看作为大师 A, 服务器端可以看作为大师 B. 客户端和服务器本身都会自带一些加密的算法, 用于双方协商加密的选择项.
1, 客户端首先会将自己支持的加密算法, 打个包告诉服务器端.
2, 服务器端从客户端发来的加密算法中, 选出一组加密算法和 HASH 算法(注, HASH 也属于加密), 并将自己的身份信息以证书的形式发回给客户端. 而证书中包含了网站的地址, 加密用的公钥, 以及证书的颁发机构等;
这里有提到公钥的概念是故事中没有的. 我们常见的加密算法一般是一些对称的算法, 如凯撒加密; 对称算法即加密用的密钥和解密用的密钥是一个. 如故事中的密钥是 4. 还有一种加密解密算法称之为非对称算法. 这种算法加密用的密钥 (公钥) 和解密用的密钥 (私钥) 是两个不同的密钥; 通过公钥加密的内容一定要使用私钥才能够解密.
这里, 服务器就将自己用来加密用的公钥一同发还给客户端, 而私钥则服务器保存着, 用户解密客户端加密过后的内容.
3, 客户端收到了服务器发来的数据包后, 会做这么几件事情:
1)验证一下证书是否合法. 一般来说, 证书是用来标示一个站点是否合法的标志. 如果说该证书由权威的第三方颁发和签名的, 则说明证书合法.
2)如果证书合法, 或者客户端接受和信任了不合法的证书, 则客户端就会随机产生一串序列号, 使用服务器发来的公钥进行加密. 这时候, 一条返回的消息就基本就绪.
3)最后使用服务器挑选的 HASH 算法, 将刚才的消息使用刚才的随机数进行加密, 生成相应的消息校验值, 与刚才的消息一同发还给服务器.
4, 服务器接受到客户端发来的消息后, 会做这么几件事情:
1)使用私钥解密上面第 2)中公钥加密的消息, 得到客户端产生的随机序列号.
2)使用该随机序列号, 对该消息进行加密, 验证的到的校验值是否与客户端发来的一致. 如果一致则说明消息未被篡改, 可以信任.
3)最后, 使用该随机序列号, 加上之前第 2 步中选择的加密算法, 加密一段握手消息, 发还给客户端. 同时 HASH 值也带上.
5, 客户端收到服务器端的消息后, 接着做这么几件事情:
1)计算 HASH 值是否与发回的消息一致
2)检查消息是否为握手消息
6, 握手结束后, 客户端和服务器端使用握手阶段产生的随机数以及挑选出来的算法进行对称加解密的传输.
为什么不直接全程使用非对称加密算法进行数据传输? 这个问题的答案是因为非对称算法的效率对比起对称算法来说, 要低得多得多; 因此往往只用在 HTTPS 的握手阶段.
以下是我们一些经常使用的加密算法, 是不是有熟悉的味道?
非对称加密算法: RSA, DSA/DSS
对称加密算法: AES, 3DES
HASH 算法: MD5, SHA1, SHA256
参考资料:
书籍HTTP 权威指南 https://book.douban.com/subject/10746113/ , 2012-9, 人民邮电出版社
来源: http://www.jianshu.com/p/d2b8bed6ca1c