HTTPS原理

加密算法

对称加密：加密和解密用同一个秘钥。如目前广泛应用的AES系列算法。

非对称加密：加密和解密不是用同一个秘钥，公钥加密的用私钥解密、私钥加密的用公钥加密。如 RSA、DH、DSA、ECC 等。

非对称加密相比于对称加密的一大缺点是速度慢。

摘要算法：MD5、SHA-2等

 

为了数据在网络上传输的安全，需要对数据加密后发送。加密可用对称加密、非对称加密，但单纯地使用它们都可能存在秘钥泄漏的情况从而导致安全问题。所以网络安全传输要解决的问题本质上就是如何在客户端和服务端间安全地协商秘钥，这实际上也是HTTPS的目标。

更准确地说，HTTPS解决的是非对称加密和对称加密结合的方案下的中间人攻击问题，即服务端公钥如何安全地传给客户端，详见下问分析。

 

网络安全传输的技术演进：（主要目标是两个：数据不被看到、数据不被篡改，对于秘钥协商过程这里的数据是指秘钥）

1 对称加密：服务端发送 对称秘钥 给客户端，之后两者间用该对称秘钥加密数据。

问题：1、双向裸奔——秘钥泄露就裸奔，持有秘钥的攻击者可以对客户端、服务端间传输的数据解密获取（数据被看到）。2、中间人攻击（数据被篡改）。

2 非对称加密：服务端发 公钥 给客户端，客户端加密数据发给服务端、服务端用 私钥 解密，服务端用私钥加密数据发给客户端、客户端用公钥解密。

问题：1、单向裸奔——公钥同样会泄露从而服务端发给客户端的数据可被解密获取；低效率——非对称加密相比对称加密效率低。2、中间人攻击篡改数据并导致数据双向裸奔。

SSH的密码登录就是这个原理，不过其只有客户端发数据给服务端而无反向发数据故不存在问题1，但问题2仍存在。详见 SSH小记-marchon。

3 两者结合：服务端发公钥给客户端，客户端用公钥将 对称秘钥 加密后给服务端，之后客户端和服务端间用该对称秘钥加密数据。也即握手和数据传输两个阶段。

问题：可解决单纯用非对称加密效率低的问题，但仍存在中间人攻击——攻击人拿到公钥后对客户端冒充服务器、篡改公钥后对服务端冒充客户端。比如网络代理就很容易作为中间人从经由其的网络交互中窃取数据。HTTPS要解决的就是此问题。

4 HTTPS：HTTPS = HTTP + SSL/TLS （SSL即Secure Socket Layer，标准化后改叫Transport Layer Security），在HTTP和TCP间加入一层SSL/TLS。

要解决的问题：上述两者结合方案中的中间人攻击问题，也就是如何将服务端的公钥安全地发送给客户端而不会被中间人攻击，或者说如何确保客户端收到的公钥是由真正的服务端发来的问题。

具体而言包括两方面：公钥不被别人看到（能看到则可直接拦响应截得到公钥从而对服务端伪装成客户端）、不被篡改（可篡改则中间人可改成自己的公钥发给客户端从而对客户端伪装成服务端）。但实际上只要做到不被篡改即可，因为此时中间人无法对客户端伪装成服务端，则即使能看到公钥从而对服务端伪装成客户端，则中间人也与真实客户端无任何交互了（相当于中间人和服务端自己去玩），那么真实客户端也不会拿到任何公钥，从而就不存在任何与服务端的交互。

SSL/TLS的核心思想：引入"第三方公证机构CA，用CA私钥对服务端公钥加密并签名，然后发给客户端，客户端用CA公钥解密获取服务端私钥。这样即使服务端公钥泄露了也无法中间人攻击，因为被修改后客户端无法用CA公钥解密。

HTTPS体现了“计算机中的任何问题都可以通过增加一层来解决”的思想：既然客户端、服务端原先不互相信任，那就增加一个双方都信任的第三方公证人来撮合它们互相信任。

具体而言：由权威的认证机构（即CA，全世界被公认的只有几家，负责颁发证书、验证证书合法性）来颁发身份证明（即所谓的证书）给一个站点，进行交互时服务端首先发送证书给客户端，客户端浏览器通常预置了CA的信息，因此可以根据该信息对证书进行有效性、合法性验证。证书中包含了服务端公钥数据，因此证书验证通过后客户端就拿到了服务端公钥。

如何验证证书有效性？

证书内容：CA颁发的证书包含 颁发证书的CA机构、证书版本、证书有效期、颁给的站点域名、服务端的公钥 、上述信息生成的摘要、摘要的数字签名、摘要算法、签名算法 等信息。除签名外其他信息是明文的。

CA机构生成证书和证书签名：CA机构对这些信息计算摘要信息并用CA的私钥加密摘要信息得到数字签名以使内容被篡改时可发现。颁发给服务端、客户端访问时由服务端传给客户端。

客户端：客户端浏览器或操作系统预置了权威CA机构的信息，包括 CA机构、CA的摘要算法、CA的公钥等。因此拿到服务端出示的证书后进行的操作与上述对应——先用该CA的摘要算法进行同样的计算得到摘要信息L，再用CA公钥解密签名得到摘要信息R，对比R、L一样则说明证书未被篡改，可靠。

总结：CA生成【包含服务端公钥的证书、CA私钥加密后的证书签名】给服务端，客户端访问后获取证书及签名并用CA公钥解密签名以验证证书未被修改过。可见，本质上看就是引入了客户端、服务端都信任的第三方（CA），借助CA的公钥、私钥来保证服务端的公钥安全地传给了客户端。服务端的公钥用CA私钥加密后传给客户端、客户端用CA公钥解密获取服务端公钥。

为何要用CA私钥对证书的摘要加密？因为若不用私钥加密则知道摘要算法后完全可以修改证书及相应的摘要，此时客户端发觉不了。用CA私钥加密后因CA私钥别人不知故签名无法被更改，就算改了也会因客户端CA公钥解密不了而被发现。

怎么就防中间人攻击了（jerry.ai技术顾问面的问题）？中间人可以完全伪装成服务端，只要拦截到DNS报文就可以伪装成服务端的域名、IP等所有信息、还可以拦截到服务端证书，为什么此时仍然不用担心数据泄露？因为中间人没有服务端私钥，虽然伪装成功了看不到数据内容。

类似例子：网络上下载的程序可能被恶意修改过，为了验证文件真伪，文件提供者通常会同时提供文件的摘要和数字签名（用提供者的私钥对摘要进行加密得到的结果），这与HTTPS防范中间人攻击（证明客户端拿到的公钥确实是服务端的公钥）类似。参阅：http://www.ruanyifeng.com/blog/2019/11/hash-sum.html

摘要可以用来校验文件未被修改过。但文件和摘要完全可能被同时修改过且是配对的，此情况依赖于数字签名来避免。

数字签名可以用来校验文件确实是提供者提供的：下载者可从网上获得文件提供者公开的公钥并解密数字证书以验证合法性。数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用。

为啥不用私钥直接对文件文件加密，这样就不用摘要，而是下载者直接用提供者的公钥解密就拿到文件了？理论上是可行的，但因为文件内容可能很大，加密耗时费劲，故不这样，采用摘要后只需要加密摘要。

self-signed certificate（自签名凭证）：HTTPS证书的申请、安装流程挺麻烦的，在开发环境中，可以使用self signed certificate 来提高证书获取的效率，以快速使用上HTTPS。与正常的CA证书相比：

优点：不由权威CA机构生成，而是直接用openssl、java keytool等工具生成（只用一条命令即可），因此不涉及证书的申请流程，证书的获取很快；

缺点：CA的私钥、公钥分别为站点的私钥、公钥。可见，这种证书是CA证书的特例。实际上，此法本质上相当于服务端把公钥塞在证书里直接给了客户端（即上面技术演进的3的过程），这也正是 "self-signed" 的体现；也因此，此法是不安全的（存在中间人攻击的风险）。

具体实践可参阅如下文章：openssl或Java keytool生成自签名证书。

TLS：

版本：v1.1、v1.2、v1.3，目前1.2应用最广

算法：

DES（Data Encryption Standard）：56位秘钥，太短，已不安全

3DES：DES的改进，过时

AES（Advanced Encryption Standard）：DES的替代，应用最广泛。AES-128、AES-192、AES-256。

ChaCha20：Google设计的加密算法，固定256位

其他：TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK等

关于SSL/TLS可参阅：https://mp.weixin.qq.com/s/L4kZyb4zpPpn40t2CS7YAg

 

其他

key + sinature 方式：

上面技术演进1中的对称加密存在秘钥泄露的风险，但该方案并不是无用武之地了——当不需要对内容解密时（因此不传输秘钥）这种方案就很有用了，典型的是非HTTPS环境下的登录场景：客户端登录时不传【用户名、密码】，而是传【用户名、用密码作为摘要的盐对用户名算摘要结果】；服务端收到请求后根据用户名找到对应的密码、用密码对用户名算摘要（注意须用不可逆的算法而不能用base64等明文转换算法）、比较算得的摘要与请求传来的摘要是否一致。这样就避免了密码在请求过程中暴露的风险；即使摘要暴露了攻击者也无法得知原始密码。这里所用的摘要方法可以事先约定，也可以与用户名等一起明文传输，别人知道也没事。

实际上，这种方法很多地方用到，比如OAuth1.0、很多API的鉴权等。详情可参阅OAuth1.0的Protocol flow。OAuth 1.0 specifies how to construct a base message string and then sign that string using the secret. 其中的base string里除了业务数据，还包括有效期、所用的摘要算法、盐等。

HTTPS的劣势：主要缺点就是性能问题。造成https性能低于http的原因有两个：

1 对数据进行加解密决定了它比http慢；2，https禁用了缓存。相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。

 

关于RSA及其他算法在加解密中的使用，可以用gpg软件实践下。gpg是个流行的加密套件。
linux下默认安装 gpg，关于其使用看参阅文章：https://www.ruanyifeng.com/blog/2013/07/gpg.html 

 

 

参考资料：

https://www.cnblogs.com/sujing/p/10927569.html

https://mp.weixin.qq.com/s/2z7NaoYEgbZ_hDxbcbMdYw