why https ?

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下发的安全证书。
咱们介绍下具体的流程：

1. 生成密钥和证书签名请求

此部分使用 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

1. 将 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信息交互的流程：

第一种方式：

第二种方式：

图中生成对称密钥的流程已经很清楚了。

另外提一下，咱们须要知道，目前有两对密钥：

1. 一对是服务端生成的公私钥
2. 另外一对是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 筛选出本身的素数对 S一、S2；
C 筛选出本身的素数对 C一、C2；
S与C交换各自的S二、C2；
S拥有了S一、C2，DH能够算出一个master key；
C拥有了C一、S2，DH能够算出一个master key；
两个master key 彻底同样。

这就是神奇的DH算法！
任何第三方都没法根据截获的S二、C2算出master key。

Summary

最终，咱们经过http中遇到的种种问题，到一步步的想办法解决，再到后来的走投无路，最终引入了https。而后又学习了https加密的整个过程，以及https早期的前向安全问题的解决方案。
想必，同窗们已经对https有了更深刻的了解了。

参考资料

HTTPS能够防止中间人篡改内容吗？

在服务器上启用 HTTPS

TLS/SSL 高级进阶

漫画：什么是 HTTPS 协议？