HTTPS加密方式

• HTTPS概述
  • 加密缘由
  • HTTPS
  • HTTPS VS HTTP
• 常见加密方式
  • 摘要算法
  • 对称加密（共享密钥加密算法）
  • 非对称加密
  • 对称 + 非对称
• 中间人攻击
  • 非对称加密中间人攻击
  • 非对称与对称方案中的中间人攻击
  • 信息抵赖
• 数字证书与签名
  • 数字证书
  • 数字签名
  • 证书掉包
  • 证书实例
  • 证书申请流程
  • 本地CA机构公钥
  • 证书链
  • 服务端找到正确的密钥X
• HTTPS请求流程图解
• 拓展
  • SSH
• 参考资料
• BMW WARNING

HTTPS概述

加密缘由

数据明文传输在经过wifi热点、路由、通信服务运营商等物理节点时信息容易被劫持暴露而不被发觉。

数据明文传输容易被中间人攻击，存在以下风险

• 窃听
• 篡改
• 冒充

HTTPS

超文本传输安全协议（（HyperText Transfer Protocol Secure）也被称为HTTP over TLS，HTTP over SSL）
HTTPS开发是为了解决上述风险，提供对网络服务器的认证，保证交换信息的机密性和完整性，在HTTP的基础上，我们需要进一步做信息传输加密，数据完整校验，身份认证等工作。

HTTPS VS HTTP

协议	端口	传输	证书
HTTPS	443	密文	需要
HTTP	80	明文	不需要

常见加密方式

摘要算法

说到加密时，首先想到的是摘要算法。
摘要算法的主要思路为从需要加密的数据中抽取一部分数据经过算法形成一段密文。
常见的摘要算法有

• MD5
• SHA256
• SHA512

摘要算法常见的用法为数字签名，例如软件提供商为了防止软件包被篡改滥用会在官方网站包下载页给出对应的MD5值，通过用户安装过程会给出MD5值或其他时机给出用户拿到包对应的MD5值，
这样用户对比后就可以知道自己的包中有没有被动手脚。
另外，在web领域，可以前后端可使用相同的摘要算法对数据进行校验来保证数据在传输过程中未被篡改，在数据库中的密码字段，也是经过摘要算法得到的一串HASH而不是明文。

摘要算法最常见的攻击为彩虹表攻击，
对于数据库中非明文的密码，攻击者只要拿到应用使用的摘要算法，
就可以在自己的数据库穷举该摘要算法与对应明文的组合，然后将得到的HASH秘钥在自己的库中做比对。
对应的破解方法就是在生成摘要时加盐（salt）。
摘要算法种类不多，应用实际实用的算法的容易被试探出，但是，加的盐基本无法探测出来。

HTTP数据加密不能单一使用摘要算法，摘要算法不算真正意义的加密，获取的秘钥内容其无法直接逆向获取原文内容，没有可行性。

对称加密（共享密钥加密算法）

对称加密算法中，使用的密钥只有一个，发送和接收双方都使用这个密钥对数据进行加密和解密。
HTTP数据使用对称加密，存在密钥传输问题，即如何保证密钥传输给众多客户端过程中不被泄露。
网络存在数量众多的传输节点，不是单单的一对一的问题，同时一台服务器也对应众多的访问客户，
如何把密钥传递给庞大的客户群并在传输过程不被泄露，是关键问题。

常见对对称加密算法为：

• DES
• AES

非对称加密

非对称加密将秘钥分为公钥与私钥，使用单组非对称加密密钥，只能保证单边通信可靠性。
客户端公钥加密，服务器私钥解密，客户端到服务器的通信是可靠的，
但是反之，服务器向客户端传递信息，如果用私钥加密，则由于公钥是公开的，发送的内容很容易就能解密
若使用两组公钥私钥，客户端服务器分别保留一把公钥，一把私钥，就可实现双边通信的可靠性。
但是，这种方案可行性差，主要原因是非对称加密算法非常耗时，非常影响用户体验，
同时，非对称加密也存在中间人攻击的风险。

常见的非对称加密算法：

• RSA
• DSA
• ECC

对称 + 非对称

HTTPS综合了对称与非对称加密算法的优势，使用了两种方案来一起进行加密。
采用非对称算法加密对称密钥，采用对称加密算法加密传输数据

主要过程为：

• 客户端发起请求
• 服务器明文发送公钥A，客户端获取公钥A
• 客户端生成对称密钥X，用公钥A加密密钥X得到密文XXX后传给服务器
• 服务器私钥A’解密密文XXX获取密钥X
• 双方用密钥X对称加解密进行通信

中间人攻击

非对称加密中间人攻击

非对称加密存在中间人攻击的风险。
以单组非对称加密（客户端公钥加密，服务器私钥解密）为例来说明：

• 客户端发起请求
• 服务端发送公钥A
• 中间人获取服务器的公钥A拦截
• 中间人把自己生产的公钥B返给客户端
• 客户端用公钥B加密明文”QQ:123 密码：123”成密文XXXB
• 中间人用私钥B’解密获取明文
• 中间人用公钥A加密明文为XXXA并传给服务器

上述过程中，客户端与服务器正常通信，难以发觉信息已经被泄露。

非对称与对称方案中的中间人攻击

只要是采用了非对称加密算法，都会存在中间人攻击的风险。
上述对称 + 非对称的方案，非对称加密算法在传递公钥过程中同样存在公钥被中间人截取篡改的风险。
该方案没有解决针对非对称加密算法的此项漏洞，中间人可以在上述非对称与对称方案中进行攻击。具体过程如下

• 客户端发起请求
• 服务器发送公钥A，被拦截，中间人获取公钥A
• 中间人生成公钥B，私钥B’
• 中间人发送公钥B，客户端获取公钥B
• 客户端生成密钥X，用公钥B加密密钥X得到密文XXXB
• 客户端发送密文XXXB，中间人截取密文
• 中间人用私钥B’解密获取密钥X
• 中间人用公钥A加密密钥X得到XXXA，并发送给服务器
• 服务器私钥A’解密XXXA获取密钥X
• 双方用密钥X对称加解密进行通信

最终中间人成功的获取了客户端与服务器此次通信的密钥X，此次通行中所用信息都可被中间人解密获取

信息抵赖

由于存在中间人攻击的已知风险，如果SSL使用对称 + 非对称的方案而不解决非对称中的这个漏洞，
即便不存在中间人攻击，当服务器给出错误的信息时，也可以进行抵赖
（中间过程传递的是密文，为了便于理解直接明文展示）

中间人成功攻击的根本原因是浏览器无法确认获取的公钥真实性

数字证书与签名

数字证书

为了保证公钥的正确真实性，需要权威CA机构(证书授权中心/Certificate Authority )来颁发数字证书，数字证书里有证书持有者（持有网站）、持有者公钥等信息。
在传输过程中，服务器传输公钥A改为传输数字证书，客户端从证书里获取取公钥A

数字签名

数字证书通过网络传输，那么中间人也可以直接拦截后篡改内容之后再返回。
同样，中间人也可以向同一家机构申请证书然后换成自己的证书。
单独使用数字证书没有根本解决中间人攻击的问题。

• 签发证书

CA机构用非对称加密算法拥有一对公私钥，用摘要算法对证书明文信息获取摘要，然后用私钥对摘要进行加密形成签名，最后将签名与使用的摘要算法置入证书当中。这里，不直接用私钥加密明文主要是因为非对称加密算法存在性能问题，加密内容不宜过长，加密摘要显然优于加密明文。

• 验证签名

1. 客户端用CA机构公钥解密数字签名得到摘要A（由于是客户端（浏览器等）信任的机构，所以其保有对应证书签发机构的公钥）
2. 客户端用证书中的摘要算法对明文进行摘要得到摘要B
3. 对比摘要A与摘要B是否一致

如果摘要对比一致，则验证成功。

数字签名可以保证证书不被篡改，中间人即便篡改明文信息并按照摘要算法重新生成摘要，但是由于没有CA机构的私钥，无法对摘要加密形成有效签名。
在客户端验证签名过程中（上节步骤1中），无法正确获取摘要A，验证失败！

数字签名的本质是采用摘要算法获取明文摘要，采用非对称加密算法私钥加密摘要

证书掉包

既然签名不可伪造，证书内容不可篡改，那么，是否可以将证书整体掉包？
证书是可以被掉包的，但是由于证书里包含了申请者的信息比如域名，浏览器等客户端会把证书里的域名与请求时的域名进行比对，掉包随即就被发现。
证书被掉包时，浏览器会有如下警告

证书实例

证书通常包含以下信息：

• 申请者公钥
• 申请者的组织信息和个人信息
• 签发机构CA的信息
• 有效时间、证书序列号等信息明文
• 签名与签名算法

证书申请流程

（出自：http://yunlaiwu.github.io/）

本地CA机构公钥

加入数字证书是为了让客户端准确获取服务器的公钥。但是要想解开证书中的签名，必须有签发机构的公钥，这些公钥从何而来？
事实上，操作系统、浏览器等会在安装时附带其认为安全的 CA机构的根证书列表。
例如，在HTTPS通信中使用的服务端证书是CA机构W签发的，如果在浏览器中存在W的根证书，那么就可以直接拿到其公钥。
在实际过程中根证书往往不直接颁发服务端证书，而是授权给中间证书。

证书链

完整的证书链一般有三级

• 服务端证书（end-user certificates）
• 中间证书（intermediates Certificates）
• 根证书（root Certificates）

点击chrome上这个锁图标，可以看一个https网站经过了几级证书认证，并可以查看每一级证书详细信息

不管存在多少级证书，其最终的目的都是为了验证服务端证书未篡改。
中间证书可以存在多级，中间证书不会影响验证结果，证书的签发与验证原理不变，最终只要通过证书链最终被CA根证书验证通过即可
中间证书的优势：

• 分级管理，减少根证书管理量，高效签发与管理证书
• 根证书内置与客户端中，一旦根证书对应的私钥泄露，吊销根证书非常困难，而中间证书私钥泄露，可先在线吊销

常见证书链如下所示

当证书不是由受信任的机构颁发的，浏览器也会警告，用户可以根据网站提示安装证书或进行其他进一步操作。

服务端找到正确的密钥X

一台服务器一般情况是与多个客户端保持连接的，每一个连接都有自己的密钥，如何对对应的客户端用正确的密钥X呢？
真正的数据传输前，需要进行SSL/TSL握手，密钥X的传递包含其中。当连接建立后，服务器会为每个客户端维护一个session ID，客户端的每一个请求都会携带该sessionID，而服务器正是通过sessionID找到正确的密钥来解密内容

---

HTTPS请求流程图解

HTTPS请求的大致流程如下所示

拓展

SSH

常用的SSH协议中(Secure Shell安全外壳协议，简称SSH)，采用的就是非对称加密。
SSH不像https协议，SSH协议的公钥是没有证书中心（CA）公证，都是自己签发的，那么远程登录使用SSH时是如何防止中间人攻击的？
SSH登录有口令登录和公钥登录两种方式：

• 口令登录

第一次登录时服务器会返回公钥并会给出公钥指纹（摘要算法获取公钥的摘要），用户可以拿到指纹与服务器提供商提供的指纹做对比，验证是否一致

　　$ ssh user@host

　　The authenticity of host 'host (12.18.429.21)' can't be established.

　　RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.

　　Are you sure you want to continue connecting (yes/no)?

如果一致，用户确认之后，公钥将会加密用户输入的密码给服务器，然后建立连接

• 公钥登录

使用口令登录，每次都要输入用户名密码，非常繁琐。
在公钥登录方式中，用户自己生成一堆非对称密钥。私钥存于本地，公钥拷贝到服务器，建立连接即可。

参考资料

BMW WARNING

• Bulletin

本文首发于 skyline.show 欢迎访问。
文章实时更新，如果有什么错误或不严谨之处望请指出，十分感谢。
如果你觉得有用，欢迎到Github仓库点亮⭐️

I am a bucolic migant worker but I never walk backwards.

• Material

参考资料如下列出，部分引用可能遗漏或不可考，侵删。

彻底搞懂HTTPS的加密机制

HTTPS安全性原理以及其对前端的影响

• Warrant

本文作者： Skyline(lty)

文章链接：http://www.skyline.show/HTTPS加密方式.html

授权声明： 本博客所有文章除特别声明外， 均采用 CC BY - NC - SA 3.0 协议。 转载请注明出处！