协议需求：

搞这么个协议是为了干嘛，这个协议需要具备什么样的特性。前三点非常重要，也是HTTPS协议的主要作用。

1.对内容进行加密
建立一个信息安全通道，来保证数据传输的安全。
SSL/TLS协议进行加解密，且通常采用的非对称加密算法为RSA。
公钥加密，私钥解密。

2.能够进行身份认证
确认对方的真实性。
证书由受信任的数字证书认证机构(Certificate Authority, CA)所颁发的，就认为对方是真的。
比如，12306官网的购票入口采用https协议，但其证书是由默认不受信任的CA所颁发的，这个机构叫SRCA，呵呵呵。

中铁数字证书认证中心（中铁CA，SRCA）

你也可以手动添加它为受信任的，但是至少默认是不受信任的。因此，在默认情况下，Chrome会认为这不是真正的12306官网的购票入口，返回错误为：

12306

虽然它确实是真的，但是谁让它是个野鸡CA呢。

3.能保证数据完整性
防止内容被第三方冒充或者篡改。
数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹(fingerprint)，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。
所以只要对内容稍有改动，算出来的指纹就和原来的指纹不一样了，这样就可以知道内容已经被篡改过，不可信了。

4.需要具备兼容性
基于兼容性的考虑，可以得出的结论是：

• HTTPS 还是要基于 TCP 来传输（如果改为 UDP 作传输层，无论是 Web 服务端还是浏览器客户端，都要大改，动静太大了）
• 单独使用一个新的协议，把 HTTP 协议包裹起来（所谓的“HTTP over SSL”，实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动）

5.需要具备可扩展性
前面说了，HTTPS 相当于是“HTTP over SSL”。　　
如果 SSL 这个协议在“可扩展性”方面的设计足够牛逼，那么它除了能跟 HTTP 搭配，还能够跟其它的应用层协议搭配。岂不美哉？　　
现在看来，当初设计 SSL 的人确实比较牛。如今的 SSL/TLS 可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性。

6.需要考虑性能
为了确保性能，SSL 的设计者至少要考虑如下几点：

• 如何选择加密算法
  “对称”or“非对称”
• 如何兼顾 HTTP 采用的“短连接”TCP 方式
  SSL 是在1995年之前开始设计的，那时候的 HTTP 版本还是 1.0，默认使用的是“短连接”的 TCP 方式（即，默认不启用 Keep-Alive）

Q&A

一些问题，答疑解惑。

1. 为什么需要身份认证，单纯用“非对称加密算法”的风险。

风险就是：中间人攻击。

• 没有被攻击之前，应该是这样的：
  第1步 网站服务器先基于“非对称加密算法”，随机生成一个“密钥对”（为叙述方便，称之为“k1 和 k2”）。因为是随机生成的，目前为止，只有网站服务器才知道 k1 和 k2。
  第2步 网站把 k1 保留在自己手中，把 k2 用【明文】的方式发送给访问者的浏览器。因为 k2 是明文发送的，自然有可能被偷窥。不过不要紧。即使偷窥者拿到 k2，也【很难】根据 k2 推算出 k1（这一点是由“非对称加密算法”从数学上保证的）。
  第3步 浏览器拿到 k2 之后，先【随机生成】第三个对称加密的密钥（简称 k）。然后用 k2 加密 k，得到 k'（k' 是 k 的加密结果）浏览器把 k' 发送给网站服务器。由于 k1 和 k2 是成对的，所以只有 k1 才能解密 k2 的加密结果。因此这个过程中，即使被第三方偷窥，第三方也【无法】从 k' 解密得到 k。
  第4步 网站服务器拿到 k' 之后，用 k1 进行解密，得到 k至此，浏览器和网站服务器就完成了密钥交换，双方都知道 k，而且【貌似】第三方无法拿到 k。然后，双方就可以用 k 来进行数据双向传输的加密。
• 被攻击之后，变成这样的了：
  第1步 这一步跟原先一样——服务器先随机生成一个“非对称的密钥对”k1 和 k2（此时只有网站知道 k1 和 k2）。
  第2步 当网站发送 k2 给浏览器的时候，攻击者截获 k2，保留在自己手上。然后攻击者自己生成一个【伪造的】密钥对（以下称为 pk1 和 pk2）。攻击者把 pk2 发送给浏览器。
  第3步 浏览器收到 pk2，以为 pk2 就是网站发送的。浏览器不知情，依旧随机生成一个对称加密的密钥 k，然后用 pk2 加密 k，得到密文的 k'浏览器把 k' 发送给网站。（以下是关键）发送的过程中，再次被攻击者截获。因为 pk1 pk2 都是攻击者自己生成的，所以攻击者自然就可以用 pk1 来解密 k' 得到 k然后，攻击者拿到 k 之后，用之前截获的 k2 重新加密，得到 k''，并把 k'' 发送给网站。
  第4步 网站服务器收到了 k'' 之后，用自己保存的 k1 可以正常解密，所以网站方面不会起疑心。至此，攻击者完成了一次漂亮的偷梁换柱，而且让双方都没有起疑心。
• 所以，为什么会被攻击？
  因为缺乏可靠的身份认证。
• 如何实现可靠的身份认证。
  有两种方式：
  1.基于某些“私密的共享信息”
  2.基于双方都信任的“公证人”
  对于 SSL/TLS 的应用场景，由于双方（客户端和服务器）通常都是互不相识的，显然不可能采用第一种方式（私密的共享信息），而只能采用第二种方式（依赖双方都信任的“公证人”）。　　
  那么，谁来充当这个公证人？
  当然是第三方：CA

2.基于 CA 证书进行的密钥交换

第1步（这是“一次性”的准备工作） 网站方面首先要花一笔银子，在某个 CA 那里购买一个数字证书。该证书通常会对应几个文件：其中一个文件包含公钥，还有一个文件包含私钥。此处的“私钥”，相当于“方案2”里面的 k1；而“公钥”类似于“方案2”里面的 k2。网站方面必须在 Web 服务器上部署这两个文件。所谓的“公钥”，顾名思义就是可以公开的 key；而所谓的“私钥”就是私密的 key。其实前面已经说过了，这里再唠叨一下：“非对称加密算法”从数学上确保了——即使你知道某个公钥，也很难（不是不可能，是很难）根据此公钥推导出对应的私钥。
第2步 当浏览器访问该网站，Web 服务器首先把包含公钥的证书发送给浏览器。
第3步 浏览器验证网站发过来的证书。如果发现其中有诈，浏览器会提示“CA 证书安全警告”。由于有了这一步，就大大降低了（注意：是“大大降低”，而不是“彻底消除”）前面提到的“中间人攻击”的风险。为啥浏览器能发现 CA 证书是否有诈？因为正经的 CA 证书，都是来自某个权威的 CA。如果某个 CA 足够权威，那么主流的操作系统（或浏览器）会内置该 CA 的“根证书”。（比如 Windows 中就内置了几十个权威 CA 的根证书）因此，浏览器就可以利用系统内置的根证书，来判断网站发过来的 CA 证书是不是某个 CA 颁发的。（关于“根证书”和“证书信任链”的概念，请参见《数字证书及CA的扫盲介绍》）
第4步 如果网站发过来的 CA 证书没有问题，那么浏览器就从该 CA 证书中提取出“公钥”。然后浏览器随机生成一个“对称加密的密钥”（以下称为 k）。用 CA 证书的公钥加密 k，得到密文 k'浏览器把 k' 发送给网站。
第5步 网站收到浏览器发过来的 k'，用服务器上的私钥进行解密，得到 k。至此，浏览器和网站都拥有 k，“密钥交换”大功告成啦。

总结：
1.client和server之间，首先通过CA证书的公钥/密钥同步对称密钥，之后信息的传输用对称密钥进行加解密。
2.client不会再顺便接受一个公钥了，这个公钥必须是CA认证的才行。所以这时中间人截获了CA证书的公钥就没毛用了，就算cilent用证书公钥加密一个k，然后发送给它，它也没办法解开，因为它没CA证书的私钥。
3.所以突破口就在CA证书上了。

值得参考的链接

背景知识、协议的需求、设计的难点
https://program-think.blogspot.com/2014/11/https-ssl-tls-1.html
数字证书与认证机构CA
https://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html
非对称VS对称，身份认证
https://program-think.blogspot.com/2014/11/https-ssl-tls-2.html
详解https是如何确保安全的
http://www.wxtlife.com/2016/03/27/%E8%AF%A6%E8%A7%A3https%E6%98%AF%E5%A6%82%E4%BD%95%E7%A1%AE%E4%BF%9D%E5%AE%89%E5%85%A8%E7%9A%84%EF%BC%9F/
相关异常javax.net.ssl.SSLHandshakeException:
http://www.jianshu.com/p/7c1bc2daef8d