HTTPS工作原理

HTTPS（HyperText Transfer Protocol over Secure Socket Layer）超文本传输安全协议， 近两年Google、Baidu、Facebook 等这样的互联网巨头，不谋而合地开始大力推行 HTTPS， 国内外的大型互联网公司很多也都已经启用了全站 HTTPS，这也是未来互联网发展的趋势。
为鼓励全球网站的 HTTPS 实现，一些互联网公司都提出了自己的要求：
Google 已调整搜索引擎算法，让采用 HTTPS 的网站在搜索中排名更靠前；
从 2017 年开始，Chrome 浏览器已把采用 HTTP 协议的网站标记为不安全网站；
苹果要求 2017 年 App Store 中的所有应用都必须使用 HTTPS 加密连接；
当前国内炒的很火热的微信小程序也要求必须使用 HTTPS 协议；
新一代的 HTTP/2 协议的支持需以 HTTPS 为基础。
因此在不久的将来，全网 HTTPS 势在必行。
（1）作用
对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全。对网站服务器进行真实身份认证。
（2）使用特征
我们经常会在Web的登录页面和购物结算界面等使用HTTPS通信。
使用HTTPS通信时，不再用 http:// ，而是改用 https:// 。另外，当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记。

架构图

HTTPS并非是应用层一个新的协议，通常 HTTP 直接和 TCP 通信，HTTPS则先和安全层（SSL/TLS）通信，然后安全层再和 TCP 层通信。

image.png

SSL/TLS协议就是为了解决上面提到的HTTP存在的问题而生的，下面我们来看一下它是怎么解决的：

1. 所有的信息都是加密传输的，第三方无法窃听
2. 配备身份验证（服务端程序），防止身份被冒充
3. 具有校验机制，一旦被篡改，通信双方会立刻发现

工作原理

HTTPS是身披SSL/TLS外壳的HTTP，TLS全称传输层安全协议Transport Layer Security Protocol，TLS/SSL是一种加密通道的规范。

image.png

TLS协议是由TLS记录协议（TLS record Protocol）和TLS握手协议（TLS handshake Protocol）这两层协议叠加而成的。

image.png
记录协议：TLS Record protocol
TLS记录协议位于TLS握手协议的下层，是负责使用对称密码对消息进行加密通信的部分，加密使用的密钥是通过握手协议在服务器和客户端之间协商决定的。

握手协议：TLS Handshaking Protocols由TLS Change Ciper Spec Protocol（密码规格变更协议）和TLS Alert Protocol（警告协议）组成负责在客户端和服务器之间协商决定密码算法和共享密钥。
密码规格变更协议负责向通信对象传达变更密码方式的信号，当协议中途发生错误时，就会通过警告协议传达给对方。警告协议是TLS握手协议负责在发送错误时将错误传达给对方。
HTTPS和HTTP协议相比提供了：

1. 数据完整性：内容传输经过完整性校验
2. 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
3. 身份认证：第三方无法伪造服务端（客户端）身份
   其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。
   理解HTTPS前需要理解这些概念：对称加密、非对称加密、摘要算法、数字签名、证书、认证中心（CA - Certificate Authority）

对称加密算法

（1）定义：
采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解
密，这种加密方法称为对称加密，也称为单密钥加密。
（2）要素：
原文、秘钥、算法
秘钥：在密码学中是一个定长的字符串、需要根据加密算法确定其长度
（3）工作过程：
对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。如果你只用1 bit来做这个密钥，那黑客们可以先试着用0来解密，不行的话就再用1解；但如果你的密钥有1 MB大，黑客们可能永远也无法破解，但加密和解密的过程要花费很长的时间。密钥的大小既要照顾到安全性，也要照顾到效率。
加密：明文 + 密钥 -> 密文 解密：密文 + 密钥 -> 明文

image.png

（4）算法
DES（Data Encryption Standard）：数据加密标准（现在用的比较少，因为它的加密强度不够，能够暴力破解）
3DES：原理和DES几乎是一样的，只是使用3个密钥，对相同的数据执行三次加密，增强加密强度。(缺点：要维护3个密钥，大大增加了维护成本)
AES（Advanced Encryption Standard）：高级加密标准，用来替代原先的DES，目前美国国家安全局使用的，苹果的钥匙串访问采用的就AES加密。是现在公认的最安全的加密方式，是对称密钥加密中最流行的算法。
AES128和AES256主要区别是密钥长度不同（分别是128bits,256bits)、加密处理轮数不同（分别是10轮，14轮），后者强度高于前者。
（5）特点
优点：算法公开、计算量小、加密速度快、加密效率高。
缺点：相对来说不算特别安全，只有一把钥匙，密文如果被拦截，且密钥也被劫持，那么，信息很容易被破译。
（6）推演
为了防止上述现象的发生，人们想到一个办法：对传输的信息加密（即使黑客截获，也无法破解）
加密公式： f1 ( key（密钥），data ) = X（密文）
解密公式： f2 ( key（密钥），X（密文） ) = data

image.png
缺陷：
加密和解密同用一个密钥，加密和解密都会用到密钥，没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密。
改进：比如服务器为每一个客户端请求的TCP连接生成一个唯一的key
image.png
缺陷：
不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高。
因每个客户端、服务器的安全级别不同，密钥极易泄露。

非对称加密算法

1）简介：
非对称加密是计算机通信安全的基石，保证了加密数据不会被破解。
非对称加密算法需要两个密钥：公开密钥(public key) 和私有密(private key)
公开密钥和私有密钥是一对
2）特点：
如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密。
如果用私有密钥对数据进行加密，只有用对应的公开密钥才能解密。
由于其算法复杂，而使得加密、解密速度没有对称加密解密的速度快。有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了，这样安全性就大了很多。
3）常用算法：
RSA、DSA、ECDSA
4）推演 - 非对称加密
公钥加密：f1 ( publicKey，data ) = X
私钥解密：f2 ( privateKey，X ) = data
私钥加密：f3 ( privateKey，data) = X
公钥解密：f1 ( publicKey，X） = data
私钥保存在服务端，公钥保存在客户端，私钥永远不对外暴露

image.png
image.png

缺陷：
公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容。
（5）推演 - 对称加密和非对称加密
非对称加密既然也有缺陷，那我们就将对称加密，非对称加密两者结合起来，取其精华、去其糟粕，发挥两者的各自的优势。

image.png
image.png
解决问题：
通过对称加密和非对称加密的组合使用，解决内容可能被窃听的问题。
存在缺陷：
解决报文可能遭篡改问题
解决通信方身份可能被伪装的问题
image.png
解决方案：
解决报文可能遭篡改问题——数字签名
解决通信方身份可能被伪装的问题——数字证书

数字签名

1）数字签名有两种功能：
能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
数字签名能确定消息的完整性,证明数据是否未被篡改过。
2）数字签名如何生成

image.png

将要发送的数据先用Hash算法（摘要算法、散列算法）生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者。
接下来就是接收者校验数字签名的流程了。
3）校验数字签名流程

image.png
接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
假设消息传递在客户端、服务器之间发生。
服务器将消息连同数字签名一起发送给客户端，客户端接收到消息后，通过校验数字签名，就可以验证接收到的消息就是服务器发送的。
问题：
这个过程的前提是客户端知道服务器的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给客户端，或者说拿到的公钥如何证明是服务器的。此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，客户端内置了所有受信任CA的证书。

消息摘要算法分为三类：
MD(Message Digest)：消息摘要算法
SHA(Secure Hash Algorithm)：安全散列算法
MAC(Message Authentication Code)：消息认证码

证书

数字证书：是一个经证书认证结构数字签名的包含公开密钥、拥有者信息的文件，有点像生活中的身份证、护照等，是由一个官方的证书颁发机构签发的一组数据。这种证书很难伪造，用于使用者的身份证明。
实际上，我们使用的证书分很多种类型，SSL证书只是其中的一种，SSL证书负责传输公钥。我们常见的证书根据用途不同大致有以下几种：
1、SSL证书，用于加密HTTP协议，也就是HTTPS，TLS。如果一个web应用想要升级为https，需要购买证书。
2、代码签名证书，用于签名二进制文件，比如Windows内核驱动，Firefox插件，Java代码签名等等
3、客户端证书，用于加密邮件
4、双因素证书，网银专业版使用的USB Key里面用的就是这种类型的证书
证书中包含：组织信息、域名信息、公钥（比如拉勾教育的公钥）、证书有效期等信息。

image.png

CA - 数字证书认证机构：
CA是证书的签发机构，它是公钥基础设施（Public Key Infrastructure，PKI）的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。

image.png
image.png
image.png
认证过程（升级HTTPS）：

1. 服务器的运营人员（网站的运营）向第三方机构CA（或者其代理机构）提交公钥、组织信息、域名等信息并申请认证;
2. CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;

3. 如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：
   申请者公钥（如拉勾教育的公钥）、申请者的组织信息和个人信息、签发机构的信息、有效时间、证书序列号等信息的明文，同时包含一个CA机构的数字签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名；

   
   image.png
   image.png
   

   用户向web服务器发起一个安全连接的请求服务器返回经过CA认证的数字证书，证书里面包含了服务器的public key。
   用户拿到数字证书，怎么确保CA证书不被劫持，黑客完全可以把一个假的CA证书发给Client，进而欺骗Client，用户如何辨别证书真伪？
   CA的大杀器就是，CA把自己的CA证书集成在了浏览器和操作系统里面。
   Client拿到浏览器或者操作系统的时候，已经有了CA证书，没有必要通过网络获取，那自然也不存在劫持的问题。
   查看浏览器CA证书：设置-->安全检查-->安全-->管理证书
   查看操作系统CA证书：certmgr.msc
   Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
   客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
   SSL证书分类：
   DV（域名型SSL）：个人站点
   OV（企业型SSL）：企业官网
   EV（增强型SSL）：对安全需求更强的企业官网、电商、互联网金融网站

完整的 HTTPS 的通信

TLS握手过程：
明文----->非对称加密----->对称加密
第一步，浏览器给出TLS协议版本号、一个客户端生成的随机数1（Clientrandom），以及客户端支持的加密方法。（明文通讯）

image.png
image.png
image.png
第二步，服务器确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数2（Server random）。（明文通讯）
image.png
image.png
第三步，浏览器确认数字证书有效，然后生成一个新的随机数3（Pre-master secret），并使用数字证书中的公钥加密这个随机数，发给服务器。（使用非对称加密算法）
浏览器确认数字证书有效：浏览器和操作系统内部内置了很多CA机构的证书，是否篡改、是否在有效期内、域名和访问的网站是否匹配。
第四步，服务端使用自己的私钥，获取客户端发来的随机数（即Premaster secret）。
双方就都有三个一模一样的随机数，前两个是明文发送的，最后客户端生成的这个是使用证书中的公钥密文发送的。
第五步，客户端和服务器根据约定的加密方法，使用前面的三个随机数经过特定的算法，生成"对话密钥"（session key），用来加密接下来的整个对话过程。
对话密钥，又叫做会话密钥，其实就是讲之前通讯中的三个随机数生成一个密钥（对称加密）
三个随机数----->第三个是使用非对称加密---->相同的算法------->会话密钥
第六步：客户端和服务器都会第一次使用会话密钥加密一个消息发送给对方。
备注：客户端收到服务端发送的Certificate 报文后首先会校验证书的合法性：
证书路径信任链逐级校验通过（证书确由可信 CA 认证签发）；
签名解密成功（确系证书持有者亲笔）；
从签名解析出的摘要和证书公开内容的摘要一致（证书内容完整，未被篡改）；
主题子域与 URL 中的 HOST 一致，综上确保访问的网站是来自预期目标服务器且非劫持或钓鱼。
session的恢复：
握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。
这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做 session ticket。
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。
image.png
上图中，客户端给出session ID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。
image.png
上图中，客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。