HTTPS原理——RSA密钥协商算法详解
HTTPS——加密协议详解
目录
HTTPS——加密协议详解
HTTP安全传输问题，核心的技术：
用非对称加密传输对称加密的密钥，如何用对称密钥通信
1、CIA三原则
2、加密方式
对称加密
非对称加密
3、HTTP与HTTPS的区别
4、RSA密钥协商握手过程
TLS第一次握手
TLS第二次握手
数字证书签发和验证流程
TLS第三次握手
TLS第四次握手
总结TLS四次握手的具体消息流程：
TLS四次握手过程中使用到的加密算法分类：
第一类：非对称加密算法：
第二类：对称加密算法：
第三类：散列算法（哈希算法、摘要算法）：
备注：
1、证书链
2、RSA 算法的缺陷
HTTP安全传输问题，核心的技术：
用非对称加密传输对称加密的密钥，如何用对称密钥通信
1、CIA三原则
安全上存在以下三个风险：
-
窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
-
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
-
冒充风险，比如冒充淘宝网站，用户钱容易没。
CIA三原则，分别代表C（机密性，Confidentiality），I（完整性，Integrity），A（可用性，Avaliability） 机密性 特性：确保用户的某些敏感数据，只能被自己看到，即数据的“不可见” 完整性 特性：确保用户的数据不能被随意的修改，即数据的”不可改“ 可用性 特性：确保用户随时可以完成对数据的读取，即数据的”在需要时的可获取性“ 以上三点，均是围绕着用户的数据提出的，可见安全最本质的一方面，就是要保证数据的安全
2、加密方式
对称加密
采用对称的密码编码技术，他的特点是，加密和解密使用相同的秘钥
非对称加密
非对称加密技术，需要两个秘钥，公钥和私钥。公钥和私钥成对出现
3、HTTP与HTTPS的区别
HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 HTML 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。
HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。
HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息。
HTTPS（Hypertext Transfer Protocol Secure：超文本传输安全协议）是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：
-
1、TCP 三次同步握手
-
2、客户端验证服务器数字证书
-
3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
-
4、SSL 安全加密隧道协商完成
-
5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。
HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。
谁来加密 加密密钥
加密密钥如何从客户端安全传输到服务端
客户端如何识别服务端的合法性
传输信息如何高效进行
TLS 协议是如何解决 HTTP 的风险的呢？
-
信息加密：HTTP 交互信息是被加密的，第三方就无法被窃取；
-
校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；
-
身份证书：证明淘宝是真的淘宝网；
可见，有了 TLS 协议，能保证 HTTP 通信是安全的了，那么在进行 HTTP 通信前，需要先进行 TLS 握手。
4、RSA密钥协商握手过程
因为HTTPS是应用层协议，需要先完成TCP三次握手建立连接，然后进行TLS握手，建立安全的链接
-
ClientHello —— 客户端请求包
-
TLS Version —— TLS版本
-
client Random —— 客户端随机数
-
Cipher Suites —— 密码加密套件
TLS第一次握手
-
客户端向服务端发送一个请求连接包——ClientHello
-
Client Hello包含：TLS Version （TLS版本）、client Random（ 客户端随机数）、Cipher Suites （ 密码加密套件）
-
TLS Version （TLS版本）：客户端的TLS版本号，当客户端向服务端发送TLS版本号后，服务端会依据客户端发送来的TLS版本号进行匹配，在第二次握手时向客户端发送与之对应的TLS版本号。
-
client Random（ 客户端随机数）：客户端生成的随机数。随机数会被服务端保留，它是生成对称加密密钥的材料之一。
-
Cipher Suites （ 密码加密套件）：客户端支持的加密套件列表。服务端会依据客户端发送来的密码加密套件进行匹配，在第二次握手时向客户端发送与之对应的密码加密套件。
-
-
TLS第二次握手
-
服务端接收到Client Hello请求包后，先会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，还有选择压缩算法（安全性原因，一般不压缩），以及生成随机数（*Server Random*）。接着，返回「Server Hello」消息
-
Server Hello包含：
-
服务器确认支持客户端的TLS版本（Version）
-
服务器从客户端发来的加密套件列表中选出一个最合适的加密组合（Cipher Suite）
-
服务器生成的随机数（Server Random）
-
-
随后，服务端利用hash算法进行计算，生成一个hash值——Hash Value，利用CA进行私钥加密，最终得到私钥签名（Certificate signature），然后服务端为了证明身份，会给客户端发送数字证书，即
Certificate包：-
包含CA机构为服务器颁发的公钥、CA机构签名等信息。
-
-
客户端接收到Certificate signature报文后，利用相同的hash算法,将服务端发送的数字证书解密获取该证书的 Hash 值 H1，将解密的Hash Value H1 和浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 进行对比，如果H1和H2的值不同，则意味着信息泄密，客户端将该信息直接丢弃；如果H1和H2的值相同，则意味着信息加密成功；
-
最后，服务器发送
Server Hello Done消息给客户端，这条消息中并没有其他有价值的信息，仅仅是为了通知客户端第二次握手中服务器的所有消息都已发送完毕，
数字证书签发和验证流程
CA 签发证书的过程，如上图左边部分：
-
首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
-
然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
-
最后将 Certificate Signature 添加在文件证书上，形成数字证书；
客户端校验服务端的数字证书的过程，如上图右边部分：
-
首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
-
通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
-
最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。
TLS第三次握手
-
客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。
-
服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。
-
客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。
-
双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。
-
-
生成完会话密钥后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。
-
客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。
-
「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。
-
TLS第四次握手
-
服务器在收到客户端的
Client Key Exchange消息后，使用RSA私钥对其解密，得到客户端生成的随机数PreMaster，至此服务器也拥有了与客户端相同的三个随机数：Client Random、Server Random、PreMaster -
服务器也使用这三个随机数计算对称密钥，将计算后的结果通过
Change Cipher Spec消息返回给客户端。-
RSA非对称加密的作用就在于 对第三个随机数"PreMaster"的加密，前面两个随机数都是公开的
-
-
务器通过
Encrypted Handshake Message消息将之前握手过程中的数据生成的摘要 使用对称密钥加密后 发给 客户端，供客户端进行验证。至此TLS四次握手完毕。
总结TLS四次握手的具体消息流程：
1. client hello --- tls, client random, cipher suites
2. server hello --- tls, server random, cipher suite
3. certificate --- certificate(pubkey)
4. server hello done
5. client key exchange --- premaster (encrypted by pubkey)
6. change cipher spec --- master secret
7. encrypted handshake message(finished)
8. change cipher spec -- premaster (decrypt premaster by privatekey)
9. encrypted handshake message(finished)cipher [ˈsaɪfə(r)] n. 密码
encrypted [ɪnˈkrɪptɪd] v. 把...加密, 加密的
TLS四次握手过程中使用到的加密算法分类：
第一类：非对称加密算法：
RSA：
ECDHE：
非对称加密算法的作用是在四次握手过程中交换密钥。
第二类：对称加密算法：
AES：
DES：
对称加密算法的作用是在完成TLS四次握手后，在数据交换过程中对数据进行加密、解密。
DES = Data Encryption Standard, “数据加密标准”
AES = Advanced Encryption Standard, “高级加密标准”
AES是比DES更完善的对称加密算法。
第三类：散列算法（哈希算法、摘要算法）：
MD5：
SHA256：
散列算法的作用是对输入的数据生成固定长度的摘要，精简数据量量，且过程不可逆（只能从数据生成摘要，不能从摘要反推出数据）。SHA是比MD5更完善的散列算法。
备注：
1、证书链
但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：
对于这种三级层级关系的证书的验证过程如下：
-
客户端收到 baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是，客户端根据 baidu.com 证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 请求该中间证书。
-
请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，如果发现验证通过，就认为该中间证书是可信的。
-
“GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性，如果验证通过，就可以信任 baidu.com 证书。
在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书，于是客户端也信任 baidu.com 证书。
总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。
操作系统里一般都会内置一些根证书，比如我的 MAC 电脑里内置的根证书有这么多：
这样的一层层地验证就构成了一条信任链路，整个证书信任链验证流程如下图所示：
最后一个问题，为什么需要证书链这么麻烦的流程？Root CA 为什么不直接颁发证书，而是要搞那么多中间层级呢？
这是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。
2、RSA 算法的缺陷
使用 RSA 密钥协商算法的最大问题是不支持前向保密。因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
为了解决这一问题，于是就有了 DH 密钥协商算法，这里简单介绍它的工作流程。
客户端和服务端各自会生成随机数，并以此作为私钥，然后根据公开的 DH 计算公示算出各自的公钥，通过 TLS 握手双方交换各自的公钥，这样双方都有自己的私钥和对方的公钥，然后双方根据各自持有的材料算出一个随机数，这个随机数的值双方都是一样的，这就可以作为后续对称加密时使用的密钥。
DH 密钥交换过程中，即使第三方截获了 TLS 握手阶段传递的公钥，在不知道的私钥的情况下，也是无法计算出密钥的，而且每一次对称加密密钥都是实时生成的，实现前向保密。
但因为 DH 算法的计算效率问题，后面出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法。