HTTPS加密协议详解

HTTPS基础知识

HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议，是一个安全通信通道，它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。

HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有信息加密、完整性校验和身份验证的功能，可以避免此类问题发生。

TLS/SSL

TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，位于传输层，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

注：
SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，TLS 1.0可以理解为SSL 3.1，它是写入了RFC的。

TLS/SSL工作原理

HTTPS协议的主要功能基本都依赖于TLS/SSL协议。

TLS/SSL的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

非对称加密
即常见的 RSA 算法，还包括 ECC、DH 等算法，算法特点是，密钥成对出现，一般称为公钥(公开)和私钥(保密)，公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信，从而实现身份验证。

非对称加密的特点是信息传输1对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。

对称加密
常见的有 AES-CBC、DES、3DES、AES-GCM等，相同的密钥可以用于信息的加密和解密，掌握密钥才能获取信息，能够防止信息窃听，通信方式是1对1;

对称加密的优势是信息传输1对1，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和 N 个客户端通信，需要维持 N 个密码记录，且缺少修改密码的机制;

散列函数Hash
常见的有 MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性;

在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密;

结合三类算法的特点，TLS的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

TLS/SSL握手过程

参考博客：SSL/TLS四次握手
SSL/TLS协议的开头是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

SSL/TLS协议的基本过程是这样的：

（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成"对话密钥"（对称密钥）。
（3） 双方采用"对话密钥"进行加密通信。

上面过程的前两步，又称为"握手阶段"（handshake）。握手分为4次，并且"握手阶段"的所有通信都是明文的。

第一次握手：（ClientHello）
客户端（通常是浏览器）先向服务器发出加密通信的请求，这里客户端主要向服务器提供
（1）支持的协议版本，（2）一个客户端生成的随机数（稍后用于生成"对话密钥"），（3）支持的加密方法，比如RSA公钥加密。

第二次握手：（SeverHello）
服务器收到客户端请求后，向客户端发出回应信息
（1）确认使用的加密通信协议版本（如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。），
（2） 一个服务器生成的随机数，稍后用于生成"对话密钥"，
（3）确认使用的加密方法，比如RSA公钥加密。
（4）服务器证书（公钥放在证书里面，只要证书是可信的，公钥就是可信的，保证公钥不被篡改）

第三次握手：
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
（1） 一个随机数pre-master key。该随机数用服务器公钥加密，防止被窃听。（此时客户端已经有了3个随机数，有能力生成对称密钥了）
（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

这样，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。（对称密钥）

第四次握手
服务器收到客户端的第三个随机数之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

PKI和CA 介绍

1、身份验证的隐患
身份验证和密钥协商是TLS的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但RSA算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，（客户端获得服务器公钥是在第二次握手后，第三次握手前，也是在这一阶段客户端验证证书有无问题，公钥是否可用）

存在如下安全隐患:（中间人攻击和信息抵赖）

客户端C和服务器S进行通信，中间节点M截获了二者的通信;

节点M自己计算产生一对公钥pub_M和私钥pri_M;

C向S请求公钥时，M把自己的公钥pub_M发给了C;

C使用公钥 pub_M加密的数据能够被M解密，因为M掌握对应的私钥pri_M，而 C无法根据公钥信息判断服务器的身份，从而 C和 M之间建立了"可信"加密连接;

中间节点 M和服务器S之间再建立合法的连接，因此 C和 S之间通信被M完全掌握，M可以进行信息的窃听、篡改等操作。

另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。

因此该方案下至少存在两类问题：中间人攻击和信息抵赖。

产生原因：客户端无法无法根据公钥信息判断服务器的身份真伪
解决方案：引入权威的第三方机构CA，核实公钥的拥有者的信息，并颁发认证"证书"，服务端将公钥放在数字证书中返回给客户端，客户端通过CA的公钥验证证书签名的合法性

2、身份验证CA和证书
解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA(如沃通CA)。CA 负责核实公钥的拥有者的信息，并颁发认证"证书"，同时能够为使用者提供证书验证服务，即PKI体系(PKI基础知识)。

基本的原理为，CA负责审核服务器信息，然后对关键信息利用自己的私钥进行"签名"，公开对应的公钥，客户端可以利用CA的公钥验证签名。CA也可以吊销已经签发的证书

a.服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;

b.CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;

c.如信息审核通过，CA会向申请者签发认证文件-证书。

证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名;

签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;

d.客户端 C 向服务器 S 发出请求时，S 返回证书文件;

e.客户端 C读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法;

f.客户端然后验证证书相关的域名信息、有效时间等信息;

g.客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

在这个过程注意几点：

a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;

b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;

c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）

d.证书=公钥+申请者与颁发者信息+签名;