Foreword
不知道有没有同学和我一样，在网上看https的资料总是觉得好像讲的不详细或者经不起推敲，甚至在书本中，也看的云里雾里，稍微到了关键的地方，就被跳过不介绍了。自己好像懂了，诶，好像又没懂。
反正我当初是憋了好一段时间 (〒︿〒)
因此，为了避免新手别像本王一样走弯，本王放弃了看动漫的时间，下定决心写一篇关于https的文章。
原文
why https ?
github上看排版更好。
What
https在MDN上的定义：
HTTPS （安全的HTTP）是 HTTP 协议的加密版本。它通常使用 SSL 或者 TLS 来加密客户端和服务器之前所有的通信 。这安全的链接允许客户端与服务器安全地交换敏感的数据，例如网上银行或者在线商城等涉及金钱的操作。
SSL和TLS的区别：
大体上说白了，没什么区别。就是TLS是IETF的标准化，SSL不是，而且会被历史给能慢慢淘汰。
值得一提的是SSL 3.0开始，便引入了前向安全性，为了不一开始就让各位困扰，前向安全会在后面介绍。
Why
那为什么要是用https呢？
自然因为安全啦。
那http怎么就不安全了呢？
接下来就让我们一起来看看吧：
小灰是客户端，小灰的同事小红是服务端，有一天小灰试图给小红发送请求。
但是，由于传输信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击。
如何进行加密呢？
小灰和小红可以事先约定一种对称加密方式，并且约定一个随机生成的密钥。后续的通信中，信息发送方都使用密钥对信息加密，而信息接收方通过同样的密钥对信息解密。
这样做是不是就绝对安全了呢？并不是。
虽然我们在后续的通信中对明文进行了加密，但是第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就已经被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。
这可怎么办呢？别担心，我们可以使用非对称加密，为密钥的传输做一层额外的保护。非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，用公钥解密。
在小灰和小红建立通信的时候，小红首先把自己的公钥Key1发给小灰：
收到小红的公钥以后，小灰自己生成一个用于对称加密的密钥Key2，并且用刚才接收的公钥Key1对Key2进行加密，发送给小红：
小红利用自己非对称加密的私钥，解开了公钥Key1的加密，获得了Key2的内容。从此以后，两人就可以利用Key2进行对称加密的通信了。
在通信过程中，即使中间人在一开始就截获了公钥Key1，由于不知道私钥是什么，也无从解密。
那这样做是不是就绝对安全了呢？同样不是。
中间人虽然不知道小红的私钥是什么，但是在截获了小红的公钥Key1之后，却可以偷天换日，自己另外生成一对公钥私钥，把自己的公钥Key3发送给小灰。
小灰不知道公钥被偷偷换过，以为Key3就是小红的公钥。于是按照先前的流程，用Key3加密了自己生成的对称加密密钥Key2，发送给小红。
这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初小红发来的Key1重新加密，再发给小红。
那怎么办呢？难道再把公钥进行一次加密吗？这样只会陷入鸡生蛋蛋生鸡，永无止境的困局。
这时候，我们有必要引入第三方，一个权威的证书颁发机构（CA）来解决。
接下来，也是开始正真的进入https的详解了。
How
证书的生成
权威的证书颁发机构（CA）是做什么的？
简单的说，就是发安全证书的，而且受全世界认可，相信它绝不造假，安全可靠。用户通过申请，填写相关资料，然后花点钱，就能获得CA下发的安全证书。
我们介绍下具体的流程：
- 生成密钥和证书签名请求
此部分使用 openssl 命令行程序（大部分 Linux、BSD 和 Mac OS X 系统均附带此程序）来生成私钥/公钥和 CSR(证书签名请求 )。
- 生成一个公钥/私钥对
用于生成 RSA 密钥对的命令为：openssl genrsa -out www.example.com.key 2048
- 生成CSR（证书签名请求）
命令：openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
- 将 CSR 提交给证书颁发机构
对于不同的证书颁发机构 (CA)，需要使用不同的方法将 CSR 发送给他们。 这些方法可能包括在其网站上使用表单、以电子邮件或其他方式发送 CSR。 一些 CA（或其经销商）甚至可能将其中部分或全部流程自动化（在某些情况下，包括密钥对和 CSR 的生成）。
将 CSR 发送给 CA 并按照他们的说明接收最终证书或证书链。
关于收费：
对于为您的公钥进行证实的服务，不同 CA 的收费将有所不同。
还可以选择将密钥映射到多个 DNS 名称，包括多个独立名称（例如 example.com、www.example.com、example.net 和 www.example.net 的全部）或“通配符”名称（例如 *.example.com）。
例如，某个 CA 目前提供以下价格：
标准：16 美元/年，适用于 example.com 和 www.example.com。
通配符：150 美元/年，适用于 example.com 和 *.example.com。
对称加密的密钥生成
证书包含如下信息：
对于已经双方都有私钥以后的事情，想必同学们都已经经过之前的训练非常清楚了。
所以我们只需要重点介绍服务端和客户端进行对称加密的时候的密钥是怎么生成就可以了。
我们来看看整个用https信息交互的流程：
第一种方式：
第二种方式：
图中生成对称密钥的流程已经很清楚了。
另外提一下，我们需要知道，目前有两对密钥：
- 一对是服务端生成的公私钥
- 另一对是CA自己的公私钥
- 服务端的私钥只在服务端存着；
- 服务端的公钥在证书里面；
- CA的私钥只在CA机构那边存着（可想而知，要是CA的私钥被泄露了，那基本这个CA机构也就破产了）；
- CA的公钥和证书一起预置了在各个操作系统里。
为了流程图更清晰，图中忽略了客户端用CA的公钥解密证书中服务端的公钥和签名的过程。
回过头来，有个问题是，为什么有两种方式？
这就得提到之前说过的前向安全性了。
它们主要的区别就是生成对称密钥的算法，图1是RSA，图2则是DH。
什么是RSA？
C随机选取一个master key（即对称加密的密钥） ，用S 的公钥加密，S解密，得到明文的master key，剩下过程和DH算法类似！
什么是DH？
S为server端，C为client端：
S 筛选出自己的素数对 S1、S2；
C 筛选出自己的素数对 C1、C2；
S与C交换各自的S2、C2；
S拥有了S1、C2，DH可以算出一个master key；
C拥有了C1、S2，DH可以算出一个master key；
两个master key 完全一样。
这就是神奇的DH算法！
任何第三方都无法根据截获的S2、C2算出master key。
Summary
最终，我们通过http中遇到的种种问题，到一步步的想办法解决，再到后来的走投无路，最终引入了https。然后又学习了https加密的整个过程，以及https早期的前向安全问题的解决方案。
想必，同学们已经对https有了更深入的了解了。
参考资料
