HTTPS工作原理详解&加密（TLS握手）过程_tls1.0握手最后会使用秘钥加密hash

HTTPS概念

HTTPS就是一个有安全保障的HTTP通信，我们都知道，http是明文传输的，http报文是人肉眼就可识别的ASCII码，在通信过程中，http报文很容易被黑客窃听、篡改、伪造，而在互联网交易中，我们必须保证通信安全，所有就需要像https这样有安全层的协议。

那么，https是怎么保障通信安全的呢？什么样的通信可以被称为是安全的，安全的定义是什么？

通常，如果通信过程具备了四个特性，就可以认为是“安全”的，这四个特性是：机密性、完整性、身份认证和不可否认。而HTTPS正是实现了这四个特性，所以被认为是“安全的”。

HTTPS和HTTP的区别

• http是超文本传输协议，信息是明文传输，https则是具有安全性的加密传输协议；
• http是基于tcp协议，tcp三次握手之后即可开始http通信；https是在http与tcp之间加了一个SSL/TLS安全层，在TCP握手之后，还要进行TLS握手，才可以开始通信；
• http没有身份认证，存在安全隐患；https使用证书系统来进行身份认证，使用https的网站需要到CA申请证书，一般免费证书较少，因而需要一定费用；
• http默认端口是80，https默认端口443

HTTPS的基本概念

SSL：安全套接层，在OSI模型中处于第5层（会话层）；
TLS：1999年，SSL被改名为TLS（传输层安全），正式标准化，所以TLS1.0实际上就是SSLv3.1，目前应用的最广泛的TLS是1.2。

TLS综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术；

浏览器和服务器在使用TLS建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”；

TLS的密码套件命名：密钥交换算法+签名算法+对称加密算法+摘要算法
如：ECDHE-RSA-AES256-GCM-SHA38

含义：握手时使用ECDHE算法进行密钥交换，用RSA签名和身份认证，握手后的通信使用AES对称算法，密钥长度256位，分组模式是GCM，摘要算法SHA384用于消息认证和产生随机数

机密性实现机制

前置知识

为什么要有机密性？

因为http是明文传输的，明文的意思就是头部字段等信息直接使用ASCII码这种人能看懂的符号传递，很容易被窃取和篡改。当我们使用http进行金钱方面的交易时，是毫无安全性而言的。

实现机密性最常用的手段是“加密”，就是把消息用某种方式转换成谁也看不懂的乱码，只有掌握特殊“钥匙”的人才能再转换出原始文本。

这里的“钥匙”就叫做“密钥”，加密前的消息叫“明文”，加密后的乱码叫“密文”，使用密钥还原明文的过程叫“解密”，是加密的反操作，加密解密的操作过程就是“加密算法”。

按照密钥的使用方式，加密可以分为两大类：对称加密和非对称加密

对称加密

对称加密：加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。

目前常用加密算法：AES（高级加密标准），密钥长度可以是128、192或256。

对称算法还有一个“分组模式”的概念，它可以让算法用固定长度的密钥加密任意长度的明文，把小秘密（即密钥）转化为大秘密（即密文），常用的是GCM、CCM和Poly1305。

非对称加密

对称加密有一个缺点：就是无法解决“密钥交换”问题，因为在对称加密算法中只要持有密钥就可以解密。如果你和网站约定的密钥在传递途中被黑客窃取，那他就可以在之后随意解密收发的数据，通信过程也就没有机密性而言了；

所以，就出现了非对称加密，也叫公钥加密算法。它有两个密钥，一个叫“公钥”（public key），一个叫“私钥”（private key）。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密；

公钥和私钥有个特别的“单向”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。

RSA是最著名的非对称加密算法，它的安全性基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。

ECC是非对称加密里的“后起之秀”，它基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法ECDHE用于密钥交换，ECDSA用于数字签名。

HTTPS的加密方式

混合加密

• 在通信刚开始的时候使用非对称加密算法，比如RSA、ECDHE，首先解决密钥交换的问题；【用随机数产生对称加密算法使用的“会话密钥”（session key），再用公钥加密。因为会话密钥很短，通常只有16字节或32字节，所以慢一点也无所谓。对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换。】
• 后续全都使用对称加密进行通信

完整性实现机制

完整性用来保证通信数据没有被篡改过。

摘要

实现完整性的手段主要是摘要算法，也就是常说的散列函数、哈希函数。

摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。

身份认证和不可否认

数字签名

数字签名就是经过私钥加密后的摘要。
#### 数字签名

还有一个问题，就是黑客冒充某网站给客户端一个假的公钥，如果你拿到了假的公钥，混合加密就完全失效了。所以，为了解决公钥的信任问题，需要引入“数字证书”。

通信过程

服务器需提供：

• 数据内容（会话密钥加密）
• 数字签名（服务器私钥加密后的摘要）
• 数字证书（CA私钥加密的服务器公钥）

客户端收到后：

• 先用CA公钥解密证书，把服务器公钥拿出来
• 使用服务器公钥解密数字签名，得到摘要
• 使用摘要算法对内容进行计算，算出的摘要与刚才解密出的摘要进行对比，如果一模一样，说明数据是完整的，没被篡改过

TLS握手过程

在http协议中，TCP三次握手成功后，浏览器会立即发送请求报文；但是https协议，它还需要另一个握手过程（TLS握手），在TCP上建立安全连接，之后才是收发报文。TLS握手的主要目的是使用非对称加密交换对称密钥，这个对称密钥是由三个随机数生成的。

TLS握手一共四个回合

1. 客户端发出请求
   • 支持的协议版本，比如TLS1.0版
   • 一个客户端生成的随机数，稍后用于生成“会话密钥”
   • 支持的密码套件（支持的加密方法）
2. 服务器回应
   • 确认使用的加密通信协议版本，比如TLS1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信
   • 一个服务器生成的随机数，稍后用于生成“会话密钥”
   • 确认使用的加密方法，比如RSA公钥加密
   • 服务器证书
3. 客户端回应
   客户端收到服务器回应以后，开始走证书链逐级验证，确认证书的真实性，如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书可以过期，就会向访问者显示一个警告，尤其选择是否还要继续通信：
   如果证书真实有效，从证书中拿出服务器公钥，向服务器发送下面三项信息：

• 一个用服务器公钥加密随机数（pre-master key），防止被窃听
• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
• 客户端握手结束通知（Finished），表示客户端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要（hash值），再加密一下，供服务器校验

4. 服务器的最后回应
   服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的“会话密钥”。

然后，向客户端最后发送下面信息：

• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送（Change Cipher Spec）
• 服务端握手结束通知（Finished），表示服务端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要（hash值），再加密一下，供客户端校验。