HTTPS的出现
HTTPS的出现，首先是要从HTTP的缺点说起，HTTP的缺点如下：
- 通信使用明文（ 不加密）， 内容可能会被窃听
- 不验证通信方的身份， 因此有可能遭遇伪装
- 无法证明报文的完整性， 所以有可能已遭篡改
防止窃听的几种加密技术。加密的对象可以有这么几个。如下
- 通信的加密。HTTP 协议中没有加密机制，但可以通过和SSL（Secure Socket Layer，安全套接层）或TLS（Transport LayerSecurity，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。
- 内容的加密。还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP报文里所含的内容进行加密处理。
确保 Web 安全的 HTTPS
在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。
HTTPS 是身披 SSL 外壳的 HTTP
HTTP+ 加密 + 认证 + 完整性保护 =HTTPS。HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS。
http与https对比图
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）协议代替而已。
通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的HTTP。
相互交换密钥的公开密钥加密技术
在对 SSL 进行讲解之前，我们先来了解一下加密方法。SSL 采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。
近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种方式得以保持加密方法的安全性。
加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。
共享密钥加密的困境
加密和解密同用一个密钥的方式称为共享密钥加密（Common key cryptosystem），也被叫做对称密钥加密。
20160817234603750.png
以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。
20160818101723390.png
使用两把密钥的公开密钥加密
公开密钥加密方式很好地解决了共享密钥加密的困难。
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。公开密钥和私有密钥是配对的一套密钥。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
20160818102412183.png
HTTPS 采用混合加密机制
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。
但是公开密钥加密与共享密钥加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。
20160818102219321.png
HTTPS 验证原理
HTTPS在真正的请求数据前，先会与服务器有几次握手验证，以证明互相的身份，以下图为例：
https验证流程.png
1、客户端发起一个https的请求，client Hello，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端。
（1） 支持的协议版本，比如TLS 1.0版。
（2） 一个客户端生成的随机数 random1，稍后用于生成"对话密钥"。
（3） 支持的加密方法，比如RSA公钥加密。
（4） 支持的压缩方法。
2、服务器收到请求,然后响应(server Hello)
（1）确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
（2）一个服务器生成的随机数random2，稍后用于生成"对话密钥"。
（3）确认使用的加密方法，比如RSA公钥加密。
（4）服务器证书。证书中包含了公钥颁证机构、网址、失效日期等等。
证书信息1
证书信息2
3、客户端收到证书之后会首先会进行验证
- 验证证书的合法性，具体验证流程请看后面，有详述。
- 生成随机密码。
验证通过之后，客户端会生成一个随机数pre-master secret，然后使用证书中的公钥进行加密，然后传递给服务器端。
PreMaster secret
PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。
PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。
4、服务器收到使用公钥加密的内容，在服务器端使用私钥解密之后获得随机数pre-master secret，然后根据radom1、radom2、pre-master secret通过一定的算法得出session Key和MAC算法秘钥，作为后面交互过程中使用对称秘钥。同时客户端也会使用radom1、radom2、pre-master secret，和同样的算法生成session Key和MAC算法的秘钥。
5、然后在后续的交互中就使用session Key和MAC算法的秘钥对传输的内容进行加密和解密（共享密钥加密）。
具体的步骤是先使用MAC秘钥对内容进行摘要，然后把摘要放在内容的后面使用sessionKey再进行加密。对于客户端发送的数据，服务器端收到之后，需要先使用client_write_key进行解密，然后使用client_write_MAC_key对数据完整性进行验证。服务器端发送的数据，客户端会使用server_write_key和server_write_MAC_key进行相同的操作。
客户端如何验证 证书的合法性？
1、验证证书是否在有效期内。
在服务端面返回的证书中会包含证书的有效期，可以通过失效日期来验证证书是否过期
2、验证证书是否被吊销了。
被吊销后的证书是无效的。验证吊销有CRL(证书吊销列表)和OCSP(在线证书检查)两种方法。
CRL（Certificate Revocation List）即证书撤销名单。证书颁发者会提供一份已经失效证书的名单，供浏览器验证证书使用。当然这份名单是巨长无比的，浏览器不可能每次TLS都去下载，所以常用的做法是浏览器会缓存这份名单，定期做后台更新。
OCSP(Online Certificate StatusProtocol)即在线证书状态协议。除了离线文件，证书颁发者也会提供实时的查询接口，查询某个特定证书目前是否有效。实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手，也会有些延迟。
3、验证证书是否是上级CA签发的。
系统中保留了所有受信任的根证书，浏览器可以查看信任的根证书，自然可以验证服务器的证书，是不是由这些受信任根证书颁发的或者受信任根证书的二级证书机构颁发的（根证书机构可能会受权给底下的中级证书机构，然后由中级证书机构颁发中级证书）。
在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信任的，整个验证的结果才是受信任的。
参考文章：
1、HTTPS 原理解析
2、1- Https流程和原理
3、Https协议详解
4、SSL/TLS原理详解
网友评论