一. HTTP

在说HTTPS之前先说说什么是HTTP，HTTP就是我们平常浏览网页时候用的一种协议。HTTP协议传输的数据都是未加密的，也就是明文的，因而用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据可以加密传输，于是网景公司设计了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出现的时间比较早，并且仍旧被现在浏览器所支持，因而SSL仍然是HTTPS的代名词，但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0，今后TLS将会继承SSL优良血统继续为我们进行加密服务。

二. HTTPS验证原理

Https在真正请求数据前，先会与服务有几次握手验证，以证实相互的身份，如图所示：

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

2.1 验证流程

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一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利使用对称加密算法进行加密，由于这串密钥只有用户端和服务端知道，所以即便中间请求被阻拦也是没法解密数据的，以此保证了通信的安全。

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

1） 验证证书能否在有效期内。

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

2） 验证证书能否被吊销了。

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

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

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

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

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

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

windows中保留了所有受信任的根证书，浏览器能查看信任的根证书，自然能验证web服务器的证书，是不是由这些受信任根证书颁发的或者者受信任根证书的二级证书机构颁发的（根证书机构可可以会授权授权给底下的中级证书机构，而后由中级证书机构颁发中级证书）在验证证书的时候，浏览器会调使用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信。