https验证原理

前言

在说HTTPS之前先说说什么是HTTP，HTTP就是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，后来IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0。

HTTPS 验证原理

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

下面简要概述下上面的验证流程（底下的序号不是和上图一一对应）
1 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（**算法套件，简称Cipher）发送给服务端。

2 服务端，接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法，以证书的形式返回给客户端证书中还包含了公钥颁证机构网址失效日期等等。

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

验证证书的合法性

颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致等，证书验证通过后，在浏览器的地址栏会加上一把小锁

生成随机密码

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

HASH握手信息

用最开始约定好的HASH方式，把握手消息取HASH值，然后用随机数加密 “握手消息+握手消息HASH值(签名)” 并一起发送给服务端，在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。

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

5 客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密，因为这串**只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全。

非对称加密算法：RSA，DSA/DSS 在客户端与服务端相互验证的过程中用的是非对称加密
对称加密算法：AES，RC4，3DES 客户端与服务端相互验证通过后，以随机数作为**时，就是对称加密
HASH算法：MD5，SHA1，SHA256 在确认握手消息没有被篡改时

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

验证证书是否在有效期内
在服务端面返回的证书中会包含证书的有效期，可以通过失效日期来验证证书是否过期。
验证证书是否被吊销了
被吊销后的证书是无效的。验证吊销有CRL(证书吊销列表)和OCSP(在线证书检查)两种方法。证书被吊销后会被记录在CRL中，CA会定期发布CRL。应用程序可以依靠CRL来检查证书是否被吊销了。
CRL有两个缺点，一是有可能会很大，下载很麻烦。针对这种情况有增量CRL这种方案。二是有滞后性，就算证书被吊销了，应用也只能等到发布最新的CRL后才能知道。
增量CRL也能解决一部分问题，但没有彻底解决。OCSP是在线证书状态检查协议。应用按照标准发送一个请求，对某张证书进行查询，之后服务器返回证书状态。
OCSP可以认为是即时的（实际实现中可能会有一定延迟），所以没有CRL的缺点。
验证证书是否是上级CA签发的
windows中保留了所有受信任的根证书，浏览器可以查看信任的根证书，自然可以验证web服务器的证书，是不是由这些受信任根证书颁发的或者受信任根证书的二级证书机构颁发的（根证书机构可能会受权给底下的中级证书机构，然后由中级证书机构颁发中级证书）
在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信。

前言

HTTPS 验证原理

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

相关链接

相关推荐

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