【通信系列 5 -- HTTPS 介绍】

1.1 HTTPS链接网址

HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol) 协议，它 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。HTTPS 的全称是 Hypertext Transfer Protocol Secure，

1.1.1 HTTPS 产生背景

由于 HTTP 天生明文传输的特性，在 HTTP 的传输过程中，任何人都有可能从中截获、修改或者伪造请求发送，所以可以认为 HTTP 是不安全的；在 HTTP 的传输过程中不会验证通信方的身份，因此 HTTP 信息交换的双方可能会遭到伪装，也就是没有用户验证；在 HTTP 的传输过程中，接收方和发送方并不会验证报文的完整性，综上，为了结局上述问题，HTTPS 应用而生。

HTTP 通信接口部分由 SSL 和 TLS 替代而已。通常情况下，HTTP 会先直接和 TCP 进行通信。在使用 SSL 的 HTTPS 后，则会先演变为和 SSL 进行通信，然后再由 SSL 和 TCP 进行通信。
在 HTTPS 中，使用传输层安全性(TLS)或安全套接字层(SSL)对通信协议进行加密。也就是 HTTP + SSL(TLS) = HTTPS。

note:SSL 即安全套接字层，它在 OSI 七层网络模型中处于第五层，,SSL 是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用，比如 SMTP(电子邮件协议)、Telnet(远程登录协议) 等都可以使用。 SSL 在 1999 年被 IETF(互联网工程组)更名为 TLS。

1.1.2 HTTPS工作内容

HTTPS 协议其实非常简单，RFC 文档很小，只有短短的 7 页，里面规定了新的协议名，默认端口号443，至于其他的应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP，没有任何新的东西。

HTTPS 协议提供了三个关键的指标：

• 加密(Encryption)， HTTPS 通过对数据加密来使其免受窃听者对数据的监听，这就意味着当用户在浏览网站时，没有人能够监听他和网站之间的信息交换，或者跟踪用户的活动，访问记录等，从而窃取用户信息。
• 数据一致性(Data integrity)，数据在传输的过程中不会被窃听者所修改，用户发送的数据会完整的传输到服务端，保证用户发的是什么，服务器接收的就是什么。
• 身份认证(Authentication)，是指确认对方的真实身份，也就是证明你是你（可以比作人脸识别），它可以防止中间人攻击并建立用户信任。

1.1.3 SSL/TLS

TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的后续版本，它们是用于在互联网两台计算机之间用于身份验证和加密的一种协议。

SSL/TLS 通过将称为 X.509 证书的数字文档将网站和公司的实体信息绑定到加密密钥来进行工作。每一个密钥对(key pairs) 都有一个 私有密钥(private key) 和 公有密钥(public key)，私有密钥是独有的，一般位于服务器上，用于解密由公共密钥加密过的信息；公有密钥是公有的，与服务器进行交互的每个人都可以持有公有密钥，用公钥加密的信息只能由私有密钥来解密。

TLS 用于两个通信应用程序之间提供保密性和数据完整性。TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学。

1.1.4 TLS 的命名规范

CDHE-ECDSA-AES256-GCM-SHA384

TLS 的密码套件比较规范，基本格式就是 密钥交换算法(CDHE) - 签名算法(ECDSA) - 对称加密算法(AES) - 摘要算法 (SHA384)组成的一个密码串。有时候还有分组模式(GCM)。

使用 ECDHE 进行密钥交换，使用 ECDSA 进行签名和认证，然后使用 AES 作为对称加密算法，密钥的长度是 256 位，使用 GCM 作为分组模式，最后使用 SHA384 作为摘要算法。

1.1.5 TLS 加密算法

DES、3DES、AES、ChaCha20、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK 等。目前最常用的是 AES-128, AES-192、AES-256 和 ChaCha20。

DES 的全称是 Data Encryption Standard(数据加密标准) ，它是用于数字数据加密的对称密钥算法。尽管其 56 位的短密钥长度使它对于现代应用程序来说太不安全了，但它在加密技术的发展中具有很大的影响力。

AES-128, AES-192 和 AES-256 都是属于 AES ，AES 的全称是Advanced Encryption Standard(高级加密标准)，它是 DES 算法的替代者。

ChaCha20 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，纯软件运行性能要超过 AES，曾经在移动客户端上比较流行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错算法。

1.1.6 分组模式

对称加密算法还有一个分组模式 的概念，对于 GCM 分组模式，只有和 AES，CAMELLIA 和 ARIA 搭配使用。

早有 ECB、CBC、CFB、OFB 等几种分组模式，但都陆续被发现有安全漏洞，所以现在基本都不怎么用了。最新的分组模式被称为 AEAD（Authenticated Encryption with Associated Data），在加密的同时增加了认证的功能，常用的是 GCM、CCM 和 Poly1305。

ECDHE_ECDSA_AES128_GCM_SHA256 表示的是具有 128 位密钥， AES256 将表示 256 位密钥。GCM 表示具有 128 位块的分组密码的现代认证的关联数据加密（AEAD）操作模式。

1.1.7 摘要算法

如何实现完整性呢? 在TLS 中，实现完整性的手段主要是 摘要算法(Digest Algorithm)。哪怕你在文件中改变一个标点符号，增加一个空格，生成的文件摘要也会完全不同。

• MD5(Message Digest Algorithm 5): 属于密码哈希算法(cryptographic hash algorithm)的一种，MD5 可用于从任意长度的字符串创建 128 位字符串值。MD5 最常用于验证文件的完整性。

什么是加盐？ 在密码学中，盐就是一项随机数据，用作哈希数据，密码或密码的单向函数的附加输入。盐用于保护存储中的密码。

• SHA-1(Secure Hash Algorithm 1) 也是一种常用的加密算法，不过 SHA-1 也是不安全的加密算法，在 TLS 里面被禁止使用。目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2。

• SHA-2(Secure Hash Algorithm 2): SHA-2 系列包含六个哈希函数，其摘要（哈希值）分别为 224、256、384 或 512 位：SHA-224, - SHA-256, SHA-384, SHA-512。分别能够生成 28 字节、32 字节、48 字节、64 字节的摘要。

• HMAC(hash message authentication code)：不过 SHA-2 是基于明文的加密方式，还是不够安全, HMAC 的计算中可以使用任何加密哈希函数，例如 SHA-256 等。

1.1.8 非对称加密

在HTTPS的传输场景下，服务端事先并不知道客户端是谁，你也不可能在事先不通过互联网和每一个网站的管理员都悄悄商量好一个通信密钥出来，那么必然存在一个密钥在互联网上传输的过程，如果在传输过程中被别人监听到了，那么后续的所有加密都是无用功。这时，我们就需要另一种神奇的加密类型，非对称加密。

当客户端发起连接请求，服务端将公钥传输过去，客户端利用公钥加密好信息，再将密文发送给服务端，服务端里有私钥可以解密。

非对称加密(Asymmetrical Encryption) 也被称为公钥加密，使用公钥加密的文本只能使用私钥解密。公钥不需要具有安全性，因为公钥需要在网络间进行传输。
非对称加密可以解决密钥交换的问题。网站保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。

非对称加密算法常见的 DH、DSA、RSA、ECC 等。RSA 加密算法是最重要的，例如 DHE_RSA_CAMELLIA128_GCM_SHA256。

• RSA 基于整数分解，使用两个超大素数的乘积作为生成密钥的材料，由于秘钥交换。
• ECC（Elliptic Curve Cryptography）也是非对称加密算法的一种，它基于椭圆曲线离散对数的数学难题，使用特定的曲线方程和基点生成公钥和私钥，
• ECDHE 用于密钥交换，
• ECDSA 用于数字签名。

note: RSA 的运算速度非常慢，而 AES 的加密速度比较快。

但是，当服务端要返回数据，如果用公钥加密，那么客户端并没有私钥用来解密，而如果用私钥加密，客户端虽然有公钥可以解密，但这个公钥之前就在互联网上传输过，很有可能已经有人拿到，并不安全，所以这一过程只用非对称加密是不能满足的。

注意，严格来讲，私钥并不能用来加密，只能用作签名使用，这是由于密码学中生成公钥私钥时对不同变量的数学要求是不同的，因此公钥私钥抵抗攻击的能力也不同，在实际使用中不可互换。签名的功能在HTTPS里也有用到，下文中会说明。

最终选用了 “非对称加密+对称加密的方案”

• 服务端有非对称加密的公钥A1，私钥A2；
• 客户端发起请求，服务端将公钥A1返回给客户端；
• 客户端随机生成一个对称加密的密钥K，用公钥A1加密后发送给服务端；
• 服务端收到密文后用自己的私钥A2解密，得到对称密钥K，此时完成了安全的对称密钥交换，解决了对称加密时密钥传输被人窃取的问题
• 之后双方通信都使用密钥K进行对称加解密。

看起来是一个非常完美的方案，兼顾了安全性和性能，但是，真的就安全了么？
依然考虑中间人攻击的情况，非对称加密的算法都是公开的，所有人都可以自己生成一对公钥私钥。
当服务端向客户端返回公钥 A1 的时候，中间人将其替换成自己的公钥 B1 传送给浏览器。
而浏览器此时一无所知，傻乎乎地使用公钥 B1 加密了密钥K发送出去，又被中间人截获，中间人利用自己的私钥 B2 解密，得到密钥K，再使用服务端的公钥 A1 加密传送给服务端，完成了通信链路，而服务端和客户端毫无感知。

1.1.9 CA认证

出现上面的核心原因是客户端无法确认收到的公钥是不是真的是服务端发来的。为了解决这个问题，互联网引入了一个公信机构，这就是CA，全称是 Certificate Authority，证书认证机构，你必须让 CA 颁布具有认证过的公钥，才能解决公钥的信任问题。全世界具有认证的 CA 就几家，分别颁布了 DV、OV、EV 三种，区别在于可信程度。

服务端在使用HTTPS前，去经过认证的CA机构申请颁发一份数字证书，数字证书里包含有证书持有者、证书有效期、公钥等信息，服务端将证书发送给客户端，客户端校验证书身份和要访问的网站身份确实一致后再进行后续的加密操作。

但是，如果中间人也聪明一点，只改动了证书中的公钥部分，客户端依然不能确认证书是否被篡改，这时我们就需要一些防伪技术了。

前面说过，非对称加密中一般公钥用来加密，私钥用来解密，虽然私钥加密理论上可行，但由于数学上的设计这么做并不适合，那么私钥就只有解密这个功能了么？

私钥除了解密外的真正用途其实还有一个，就是数字签名，其实就是一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败。具体过程如下：

• CA机构拥有自己的一对公钥和私钥
• CA机构在颁发证书时对证书明文信息进行哈希
• 将哈希值用私钥进行加签，得到数字签名

明文数据和数字签名组成证书，传递给客户端。

• 客户端得到证书，分解成明文部分Text和数字签名Sig1
• 用CA机构的公钥进行解签，得到Sig2（由于CA机构是一种公信身份，因此在系统或浏览器中会内置CA机构的证书和公钥信息）
• 用证书里声明的哈希算法对明文Text部分进行哈希得到H
• 当自己计算得到的哈希值T与解签后的Sig2相等，表示证书可信，没有被篡改

这时，签名是由CA机构的私钥生成的，中间人篡改信息后无法拿到CA机构的私钥，保证了证书可信。

注意，这里有一个比较难以理解的地方，非对称加密的签名过程是:私钥将一段消息进行加签，然后将签名部分和消息本身一起发送给对方，收到消息后对签名部分利用公钥验签，如果验签出来的内容和消息本身一致，表明消息没有被篡改。

1.2 openssl

openssl是一个开源程序的套件、这个套件有三个部分组成:
一是 libcryto、这是一个具有通用功能的加密库、里面实现了众多的加密库。
二是 libssl、这个是实现ssl机制的、他是用于实现TLS/SSL的功能。
三是 openssl、是个多功能命令行工具、他可以实现加密解密、甚至还可以 当CA来用、可以让你创建证书、吊销证书。

1.2.1 RSA 签名验签

(1) 用 OpenSSL 生成一个 2048 位的 RSA 密钥对：

openssl genpkey -out privkey.pem -algorithm rsa 2048

可以舍去 -algorithm rsa 标志，因为 genpkey 默认为 RSA 类型。文件的名称（privkey.pem）是任意的，但是 隐私增强邮件(Privacy Enhanced Mail)（PEM）扩展名 .pem 是默认 PEM 格式的惯用扩展名。（如果需要的话，OpenSSL 有命令可以在各种格式之间进行转换。）如果需要更大的密钥大小（例如 4096），那么最后一个参数 2048 可以改成 4096。这些大小总是二的幂。

(2) 接下来的命令就会从私钥中提取出这对密钥的公钥：

openssl rsa -in privkey.pem -outform PEM -pubout -out pubkey.pem

(3) 源文件 client.c 是要签名的工件：

openssl dgst -sha256 -sign privkey.pem -out sign.sha256 client.c

client.c 源文件的摘要是 SHA256，私钥在前面创建的 privkey.pem 文件中。由此产生的二进制签名文件是 sign.sha256，这是一个任意的名字。要得到这个文件的可读版本（比如 base64），后续命令是：

openssl enc -base64 -in sign.sha256 -out sign.sha256.base64

(4) 用公钥验证数字签名，作为验证的一个重要步骤，应重新计算用于签署工件（在本例中，是可执行的 client 程序）的哈希值，因为验证过程应表明工件在签署后是否发生了变化。
有两个 OpenSSL 命令用于这个目的:
第一条命令是对 base64 签名进行解码:

openssl enc -base64 -d -in sign.sha256.base64 -out sign.sha256

第二条是核实签名：

openssl dgst -sha256 -verify pubkey.pem -signature sign.sha256 client

第二条命令的输出，应该是这样的：

Verified OK

推荐阅读：
https://zhuanlan.zhihu.com/p/130333796