https原理总结
最近项目中要用到https，找运维人员配置相关参数时，被问到要配置单向认证还是双向认证，瞬间傻了，已是回来研究了下https的原理。
https已经成为电商网站、银行、资金有关的系统的标配，特别是现在网络流量劫持增多、资金频繁被盗等场景下，重要网站https化势在必行。那么https原理是什么？单向认证、双向认证、为何要依赖于证书颁发机构、12306网站为何需要配置根证书？这些都是值得探讨的。
一.https原理
网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持。
1. 客户端发起https请求
这个过程中客户端发送的信息会说明它支持的最高TLS协议版本、随机数、密码算法列表及压缩方法给服务端；
2. 服务端配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。
3. 服务器返回证书
发送给浏览器的证书包含公钥、证书的颁发机构、过期时间、域、签名等信息；
4. 验证证书
这部分工作是由客户端的TLS来完成的，客户端会验证证书是否有效，如服务器证书是否过期、发行服务器证书的CA是否可靠、发行CA的公钥能否正确解开服务器证书的发行CA的数字签名、服务器证书上的域名是否和服务器的实际域名相匹配等等，如果发现异常则会弹出一个警告框，提示证书存在问题，让用户选择是否继续。
证书中会包含数字签名，该数字签名是加密过的，是用颁发机构的私钥对本证书的公钥、名称及其他信息做hash散列加密而生成的。客户端浏览器会一层层的去寻找颁发者的证书，直到自签名的根证书，然后通过相应的公钥再反过来验证下一级的数字签名的正确性，如果不能正常解密，则就是”发现异常”，说明该证书是伪造的。
5. 传送加密信息
如果上步证书验证通过，则生成一个随机值A作为后面通讯的密钥（对称加密），用证书的公钥对这个随机值加密，发送该加密后的随机值到服务器端，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
如果服务器要求客户端的身份认证（在握手过程中为可选）即双向认证，客户端可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户端自己的证书以及加密过的随机值A发送给服务器。
6. 服务端解密信息
服务端用证书的私钥解密后，得到了客户端传过来的随机值A，至此一个非对称加密的过程结束，看到TLS利用非对称加密实现了身份认证和密钥协商。
如果服务器要求客户端的身份认证（双向认证），服务器必须检验客户端证书和签名随机数的合法性，具体的合法性验证包括：客户端证书是否过期，发行客户端证书的CA是否可靠，发行CA的公钥能否正确解开客户端证书的发行CA的数字签名，检查客户端证书是否在证书废止列表（CRL）中。如果合法性验证没有通过，通讯立刻中断；如果合法性验证通过，才获取随机值A,进行后续的步骤。
7. 传输加密后的信息
用上文客户端传来的密钥A加密客户端请求的内容，发给客户端。
8. 客户端解密信息
客户端用密钥A解密消息，获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。（为什么不直接使用公钥和私钥进行通讯？因为非对称解密相当损耗CPU性能，https网站cpu损耗差不多90%的性能损耗都在非对称秘钥的解密上。全部内容都用非对称加密交流性能大大下降）
不管是双向认证还是单向认证，服务端都需要配置CA证书，单向认证不需要客户端拥有CA证书，双向认证客户端需要拥有CA证书。
一般Web应用都是采用单向认证的，原因很简单，用户数目广泛，且无需做在通讯层做用户身份验证，一般都在应用逻辑层来保证用户的合法登入。但如果是企业应用对接，情况就不一样，可能会要求对客户端（相对而言）做身份验证。这时就需要做双向认证。
二.证书颁发机构
如果任何的证书客户端都信任，那么在上面的步骤1中，攻击者可以通过DNS劫持或IP伪造的方法使其访问到攻击者的服务器上，攻击者伪造一个同样域名的证书发给客户端，客户端验证了日期、域等都没错，从而骗过了客户端。
为了抵御这种中间人攻击，证书需要由可信的证书颁发机构颁发，形成一个证书链（比如Gmail的证书链为：最底层为网域mail.google.com，上一层为Thawte SGC CA证书颁发机构，最顶层为很有名的VeriSign证书颁发机构）。那么，浏览器除了需要验证域和有效期外，还要检查证书链中的上级证书公钥是否有效，上级的上级证书公钥是否有效，直至根证书公钥为止。这样就可以有效避免中间人攻击了，因为根证书公钥都是预装在浏览器或操作系统中的，黑客如果不是暴力破解，无法得到根证书的私钥，如果黑客自己生成一个私钥，浏览器验证根证书公钥的时候发现无法通过浏览器中预装的公钥加密数据后使用这个私钥进行解密，从而判定这个公钥是无效的。这个方案也是现在https通讯通常的方案。
那么，这个现在所有的浏览器正在使用的https通讯方案就无懈可击了吗？答案仍是否定的。我们可以看到，在后一个方案中，https的安全性需要在证书颁发机构公信力的强有力保障前提下才能发挥作用。如果证书颁发机构在没有验证黑客为mail.google.com的持有者的情况下，给黑客颁发了网域为mail.google.com的证书，那么黑客的中间人攻击又可以顺利实施。
12306网站就是没有采用证书颁发机构颁发的证书，而是自己制作证书，因此需要在浏览器安装根证书，否则访问的时候就会提示‘此网站的安全证书有问题’，阻止用户继续访问。
证书分为DV(Digital Verification)，OV(Organization Verification)和EV(Extended Verification)，其中EV证书最贵，可以在浏览器中看到绿色的就是EV证书。
