https的那些事

以前看了一些网上关于https的文章，感受都讲的不够完善，整篇看下来仍是以为有几个疑问点，最近学习了极客时间《透视HTTP协议》，稍微能摸清楚https的工做，写一写增强印象。

什么是安全

一般认为，通讯过程具有了如下4个特性，能够认为安全：机密性，完整性，身份认证，不能否认。

• 机密性
  指数据保密的，只有通讯的对方能知道数据的内容，数据对其余方是不可见的
• 完整性
  机密性虽然保证了数据不可被窃取，可是不能防止被篡改，若是通讯过程数据直接被调包或者被修改，那么也是不安全的
• 身份验证
  指能确认对方的身份，保证“我”在和“你”在通讯而不是“他”，没有身份验证，通讯的是“他”，那么再怎么机密的数据也是白搭
• 不能否认
  “我”经过只有“你”知道的事情回应“你”，那么“你”就是正确的“你”

什么是HTTPS

HTTPS是运行在SSL/TLS上的HTTP，只要弄懂了SSL/TSL就弄懂了HTTPS，而SSL/TLS是在OSI模型中处于第5层会话层中，目前运用最普遍的TLS是v1.2版本，最新的v1.3兼容了v1.2，且强大了不少。
TLS由记录协议，握手协议，警告协议，变动密码协议，扩展协议等几个子协议组成，综合使用了对称加密，非对称加密，身份验证等多个前沿密码学技术。

加密

对称加密

安全的第1个特性是机密性，那么实现机密性最经常使用的手段就是对数据进行“加密”，把数据经过某种形式转化为谁都看不懂的乱码，只有特定的“钥匙”的人才能解密数据。加密能够分为两大类：对称加密和非对称加密。

对称加密的加密和解密的密钥都是同一个，因此是“对称”的，只要保证了密钥只有通讯双方持有，那么整个通讯过程就具备了机密性。
目前最经常使用的对称加密算法是AES（advanced encryption standard），安全强度高，性能也很好，因此最流行。

分组模式

对称加密还有个分组模式的概念，他可让加密算法用固定长度的密钥加密任意长度的明文，即小秘密转化为大秘密，将明文按照必定的规则切分，而后分别对明文片断进行加密，再整合成一块儿。如今最多见的分组模式是GCM/CCM/Poly1305，

非对称加密

对称加密最大的问题就是如何让通讯两方都知道一个密钥，总不能为了传输这个密钥再用另外一个密钥进行加密吧，那就是“鸡生蛋，蛋生鸡”的问题没完没了了。
因此非对称加密就出来了。它有两个密钥，一个是“公钥”，一个是“私钥”，两个密钥不一样，因此“不对称”，私钥必须严格保密，公钥能够公开给任何人使用。
这里有个特别的“单向性”，公钥加密的数据只能够用私钥解密，反之私钥加密的数据只能够用公钥解密，常见算法有RSA/ECC。

RSA

在TLS1.2版本里最经常使用的非对称加密算法，因为不具备“向前安全”，因此在1.3版本中被弃用了。

ECC

是非对称加密算法的后起之秀，他基于“椭圆曲线离散对数”的数学难题，用特定的曲线方程和基点生成一个公钥和一个私钥。子算法ECDHE用于密钥交换，ECDSA用于数字签名。

混合加密

为何TLS不直接使用非对称加密呢

1. 由于非对称加密和解密的过程比对称加密慢太多，致使在通讯的过程中须要很是长的时间，通讯龟速，实用性为0，RSA2048的加解密大约是15KB/s，而AES128则是13MB/s,相差了差很少一千倍。
2. 因为公钥是公开的，那么客户端的数据被窃取修改，第三方同样能够用公钥加密篡改后的数据，因此要用非对称加密进行通讯，客户端须要验证服务端的身份的同时，服务端也须要验证客户端的身份，这是不现实的，要海量的客户端的身份谈何容易。

因此TLS只是用非对称加密算法让双方得到一个对称加密算法的密钥，后续的通讯使用该密钥进行。

数字签名和证书

虽然有了机密性，可是离安全还差很远
黑客虽然拿不到密钥，可是能够经过窃听收集足够多的密文，尝试修改/重组后发给服务器，由于没有完整性检查，服务器正常返回，黑客能够经过服务器的响应获取进一步线索，最终破解密钥。
另外，黑客也能够伪造公钥发布，若是客户端拿到了假的公钥匙，那么再怎么加密都没有用了，被黑客直接拦截，直接裸奔。。

摘要

实现完整性的手段主要是摘要算法，摘要意思就是原文的总结，归纳，一个原文经过一种摘要算法只有一个摘要，因此摘要能够认为是原文的“指纹”，MD5和SHA-1是以前常见的摘要算法，可是因为安全性不足，被弃用了，如今经常使用的是SHA-2。

数字签名

现实生活中解决身份认证的常见的有盖章，签名。一样的，在通讯中要想实现身份认证，首先得有个惟一的东西只要你拥有——那就是非对称加密中的私钥。使用私钥加密摘要，就可以实现数字签名，实现了身份认证的同时也实现了不能否认。

数字证书和CA

综合上述，咱们已经实现了安全的4大特性，是否是ok了？
不是。
这样还有公钥的信任，由于谁均可以发布公钥，咱们怎么证实这个公钥就是通讯对方的公钥呢？
只能引入“可信的第三方”，这个第三方就是咱们常说的CA，由他来给各个公钥签名，用自身的信誉作担保，构建起公钥的信任链。
CA对公钥的签名认证也是由必定格式的，包括序列号，用途，颁发者，有效时间，公钥等等，再打一个包再签名，造成一个数字证书。

HTTPS创建链接

图上的每个直线表明的是一个记录协议，多个记录协议会在一个tcp包中一同送出。

ECDHE握手过程

1. 在tcp创建链接后，浏览器会先发一个client hello，包含由TLS支持的版本号，支持的密码套件，还有一个随机数client random，用于后续生成会话密钥。
2. 服务端收到后，会返回一个server hello，包含肯定TLS版本号，选取其中一组密码套件，好比TLS_ECHDHE_RSA_WITH_AES256_GCM_SHA384，意思是非对称加密算法选取ECHDHE+RSA，对称加密算法AES256，分组模式GCM，摘要加密算法SHA384，还有一个随机数server random，这个一样用于后续生成会话密钥。
   而后，服务器发送证书，因为服务器选择的是椭圆曲线ECHDHE的加密算法，因此又发送来一个server key exchanges，里面是椭圆曲线的公钥server params，再加上本身的私钥签名，防止server params被篡改。
3. 客户端拿到了服务端的响应，这时开始验证服务端发送过来的证书是否可信，开始走证书链逐级验证：
   证书是被CA签名了的，因此此时根据该证书的颁发者，拿到颁发者的公钥，解密出摘要，再根据摘要算法对证书内容进行摘要计算，若是计算结果跟证书上的摘要一致，则验证了完整性和不能否认。若是该颁发者不是1级CA，那么须要验证该颁发者的身份，根据上述一样的操做验证颁发者的证书，直到根级证书。若是在此过程都验证正确，那么该颁发者可信，从而该服务器的证书可信，达到身份验证。
   验证完成后，客户端根据服务器证书上的公钥，解密出server key exchange的摘要，确认无误后，获得了server params。而后客户端按照密码套件，也生成了一个椭圆曲线的公钥(client params)和私钥，用client key exchange发送client params给服务端。
4. 如今两方都有椭圆曲线本身的私钥和对方的公钥，生成一个叫作pre-master的随机数，神奇的算法让双发生成的随机数是一致的，因为私钥并无在通讯中公开，因此pre-master也没有在通讯中公开，因此这个随机数在本次通讯中只要双发知道。
5. 双方根据client random , server random, pre-master三个随机数计算获得master secret，这个就是用于后面通讯的对称密钥。

6. 客户端发送一个change cipher spec和finished。再将以前发送的全部数据作个摘要，再用密钥加密一下，让服务器验证一下。

   • 这里客户端能够立刻进行https的通讯，就是抢跑，无需等待服务器的回应，由于双方都已经在以前的握手中肯定能够知道主密钥了。减小0.5个rtt。
7. 服务器验证完成后，发送一个change cipher spec和finished，以后的通讯就开始密文交流。

RSA握手过程

大致流程跟上述一致，只是pre-master再也不经过算法生成，而是客户端直接生成随机数，而后用服务器的公钥加密，经过发送一个client key exchange发送给服务器，那此时双方也实现了共享3个随机参数。