从新浪博客搬到简书（在简书试写）

参考链接：http://www.cnblogs.com/zery/p/5164795.html

HTTPS 验证原理

Https在真正请求数据前，先会与服务有几次握手验证，以证明相互的身份，以下图为例：

验证流程

注：文中所写的序号与图不对应但流程是对应的

1客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端

2服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法

以证书的形式返回给客户端 证书中还包含了 公钥 颁证机构 网址 失效日期等等。

3客户端收到服务端响应后会做以下几件事

3.1 验证证书的合法性

颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致等

证书验证通过后，在浏览器的地址栏会加上一把小锁(每家浏览器验证通过后的提示不一样 不做讨论)

3.2 生成随机密码

如果证书验证通过，或者用户接受了不授信的证书，此时浏览器会生成一串随机数，然后用证书中的公钥加密。

3.3 HASH握手信息

用最开始约定好的HASH方式，把握手消息取HASH值，  然后用 随机数加密 “握手消息+握手消息HASH值(签名)”  并一起发送给服务端

在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。

4服务端拿到客户端传来的密文，用自己的私钥来解密握手消息取出随机数密码，再用随机数密码 解密 握手消息与HASH值，并与传过来的HASH值做对比确认是否一致。

然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端

5客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密

因为这串密钥只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全

非对称加密算法：RSA，DSA/DSS     在客户端与服务端相互验证的过程中用的是对称加密

对称加密算法：AES，RC4，3DES     客户端与服务端相互验证通过后，以随机数作为密钥时，就是对称加密

HASH算法：MD5，SHA1，SHA256  在确认握手消息没有被篡改时

客户端如何验证 证书的合法性？

1. 验证证书是否在有效期内。

在服务端面返回的证书中会包含证书的有效期，可以通过失效日期来验证 证书是否过期

2. 验证证书是否被吊销了。

被吊销后的证书是无效的。验证吊销有CRL(证书吊销列表)和OCSP(在线证书检查)两种方法。

证书被吊销后会被记录在CRL中，CA会定期发布CRL。应用程序可以依靠CRL来检查证书是否被吊销了。

CRL有两个缺点，一是有可能会很大，下载很麻烦。针对这种情况有增量CRL这种方案。二是有滞后性，就算证书被吊销了，应用也只能等到发布最新的CRL后才能知道。

增量CRL也能解决一部分问题，但没有彻底解决。OCSP是在线证书状态检查协议。应用按照标准发送一个请求，对某张证书进行查询，之后服务器返回证书状态。

OCSP可以认为是即时的（实际实现中可能会有一定延迟），所以没有CRL的缺点。

3. 验证证书是否是上级CA签发的。

windows中保留了所有受信任的根证书，浏览器可以查看信任的根证书，自然可以验证web服务器的证书，

是不是由这些受信任根证书颁发的或者受信任根证书的二级证书机构颁发的（根证书机构可能会受权给底下的中级证书机构，然后由中级证书机构颁发中级证书）

在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信

简书比新浪博客好用太多了