HTTPS简介
HTTPS其实是有两部分组成：HTTP SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。也就是说使用HTTPS协议之后在网络上传输的数据是加密的密文，即便进行拦截后没有密钥进行解密的话也就是一串乱码。端口号是443
HTTPS其实就是身披SSL协议外壳的HTTP。
概念解析
明文：是指原始干净的数据，比如”I’m a boy.”。 密文：是指通过加密算法加密后的数据。 对称加密：是指用对称加密密钥以及对应的算法进行加密的方法。特点是对称秘钥既能用于加密数据也能用于解密数据。 非对称加密：是指用非对称加密密钥（公钥和私钥）以及对应的算法进行加密的方法。特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。 证书：是指数字证书，具有权威性，就像企业公司合同上的印章一样，代表这个是企业授权的合同。
SSL/TLS
不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。 （SSL和TLS只是协议不同时期的叫法不同，一般我们都叫SSL证书。TLS是在SSL基础上发展的新版本，有时候会统称该协议为SSL）
（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。 （2） 篡改风险（tampering）：第三方可以修改通信内容。 （3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。
SSL/TLS协议是为了解决这三大风险而设计的，希望达到：
（1） 所有信息都是加密传播，第三方无法窃听。 （2） 具有校验机制，一旦被篡改，通信双方会立刻发现。 （3） 配备身份证书，防止身份被冒充。
CA证书
第三方机构CA的使用流程： * 首先，CA会向申请者颁发一个证书，这个证书里面的内容有：签发者、证书用途、服务器申请的时候附带的公钥、服务器的加密算法、使用的HASH算法、证书到期的时间等等。 * 紧接着，把上面所提到的内容，做一次HASH求值，得到一个HASH值。 * 再接着，用CA的私钥进行加密，这样就完成了数字签名。而用CA的私钥加密后，就生成了类似人体指纹的签名，任何篡改证书的尝试，都会被数字签名发现。 * 最后，把数字签名，附在数字证书的末尾，传输回来给服务器。 * 客户端拿到这个数字证书以后，用CA私钥对应的公钥，可以解密数字证书末尾的数字签名，得到原始的HASH值。 * 紧接着，客户端按照证书中的HASH算法，对证书的内容求HASH值。如果通过CA公钥解密的HASH和通过计算求得的HASH值相同，那么认证通过，否则失败。 * 如果认证通过，就可以取得服务器的公开密钥。
（浏览器和操作系统都会维护一个权威的第三方机构CA列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。）
HTTPS加密流程
流程（与上图的流程序号可能有些对不上，抽出主干内容）：
1. 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
注意：客户端还会附加一个随机数，这里记为A。
2. 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
注意：这里服务器同样会附加一个随机数，发给客户端，这里记为B。
3. 接着服务端将自己的公钥等信息发给CA申请证书并数字签名，CA用自己的私钥进行加密，然后将其都发还给服务器，服务器再将其发给客户端
4. 客户端尝试用自己系统内置的所有CA的公钥对服务端发过来的公钥进行解密，如果所有CA的公钥都无法解密的话，说明服务端发过来的证书是不被信任的，弹出警告；如果用自己内置的某个CA公钥对服务端发过来的公钥进行解密成功，说明服务端发过来的证书是正常的，然后对服务端的证书进行有效期、机构信息等进行验证，如果验证不通过(如：过期)，则弹出警告
5. 接着，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用随机生成的Pre-master secret的随机密码串。该报文使用从证书中解密获得的公钥进行加密（其实就是服务器的公钥）。当其生成了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。
6. 客户端继续发送Change Cipher Spec报文。用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。发送finish报文。
7. 服务器接收到客户端的请求之后，使用私钥解密报文，把Pre-master secret取出来。接着，服务器同样发送Change Cipher Spec报文和finish报文。当服务器解密获得了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。
8. 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
9. 接下来双方使用对称加密算法进行加密，用hash secret对HTTP报文做一次运算生成一个MAC（相当于摘要），附在HTTP报文的后面，然后用session-secret加密所有数据（HTTP MAC），然后发送。接收方则先用session-secret解密数据，然后得到HTTP MAC，再用相同的算法计算出自己的MAC，如果两个MAC相等，证明数据没有被篡改。
上面第一步所说的加密组件列表，也就是密文族： 是浏览器所支持的加密算法的清单。RFC2246中建议了很多中组合，一般写法是”密钥交换算法-对称加密算法-哈希算法。以“TLS_RSA_WITH_AES_256_CBC_SHA”为例，TLS为协议，RSA为密钥交换的算法，AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式），SHA是哈希的算法。浏览器支持的加密算法一般会比较多，而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。
总结HTTPS
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构（CA）颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
（HTTPS的加密协商过程使用了非对称加密和对称加密，同时在数字证书签发的过程中也使用了非对称加密，还对公钥等明文部分使用了Hash算法）
总流程图：
参考博文链接： http://www.jianshu.com/p/705dcd60c264 http://www.jianshu.com/p/25ee72de8ea0 http://www.jianshu.com/p/b5db358a0444 https://segmentfault.com/a/1190000012196642
