【面试篇】：谈谈你对HTTP和HTTPS的理解？

前言：博主在面试阿里和拼多多的时候，都被问到过这个问题，可见其重要性。本文围绕HTTPS协议是如何保证数据安全性进行展开。

1、HTTP

HTTP协议是一种无状态的超文本传输协议，它以 TCP（传输层）作为底层协议，默认端口号是 80。

• 优点：是扩展性强、速度快、跨平台支持性好。
• 缺点：不安全，所有数据是以明文的形式传输。

2、HTTPS

HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证 ，默认端口号是 443。

• 优点: 保密性好、信任度高。
• 缺点：HTTPS 协议会使页面的加载时间延长近 50%，增加 10%到 20%的耗电。

3、HTTPS为什么安全？

通俗的理解：HTTPS = HTTP + TLS

而HTTPS之所以安全，跟TLS的原理有关，我们知道要想数据传输安全，就得解决以下三个问题：

（1）、可靠性传输
（2）、数据完整性
（3）、端点鉴别

而TLS就完美解决了这三个问题，主要依赖于三类基本算法：哈希函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于哈希函数验证信息的完整性。

1、非对称加密

非对称加密：指加解密使用的是不同的密钥，这两个秘钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。公钥是公开的，任何人都可向服务器获取，私钥则必须保密，只有服务器拥有，不会在网络上传输。加密时满足以下三点：

公钥加密私钥解
私钥加密公钥解
公钥加密公钥解不开

客户端与服务器交互图：

第一步：获取公钥（443端口）
第二步：真正数据传输

此时黑客拦截服务器给用户传输的数据：黑客同样可以使用公钥解密数据，轻而易举的就能知道服务器给用户发送的数据，但黑客无法篡改服务器传输的数据，但如果黑客采取以下的方式：

这种方式下，黑客去伪造服务端，当用户去请求服务器时，黑客拦截请求，下发假的公钥给用户，当用户拿着这个假的共钥在去发送消息的时候，黑客就可以用自己的私钥去解密，查看用户数据。甚至向服务器发送请求下载真正的公钥，黑客把解密得到的数据，修改之后利用服务器的公钥发送到服务器，这不仅仅是看到了用户的信息，还修改了用户的信息。极其也不安全。

细心的朋友就会发现，上述情况之所以不安全，是因为公钥需要在网络中传输，无法保证公钥是服务器的公钥。 基于这种情况，CA机构就诞生了：

CA：是一个组织，负责签发证书、认证证书、管理已颁发证书的机关。

2、非对称加密算法+CA

非对称加密算法不安全的原因：黑客拦截了用户数据，伪造并下发假的公钥，解析用户的数据，而CA机构的出现就是: 认证公钥，让用户得到的是服务器的公钥

用户与服务器交互图：

第一步：获取证书（内含经过CA机构私钥加密过的服务器公钥）。客户端向服务器发送请求时，如何黑客此时劫持了用户的数据，下发假的公钥给客户端，由于客户端的操作系统内置了CA机构的公钥，而黑客却没有CA机构的私钥，所以这个黑客下发的假的共钥是无法被操作系统的CA机构的公钥解析的，而服务器回传给客户端的证书，黑客尽管能劫持到这个证书，虽然能修改，但是同样是没有CA机构的私钥，修改之后的证书是无法被客户端解析的。所以客户端能获取到真正的服务器公钥。

第二步：发送真正请求。客户端通过服务器真正的公钥向服务器发送数据，虽然黑客能劫持到数据，但是黑客只能获取到公钥，不能获取到服务器的私钥，而公钥是不能解析公钥的数据的，所以黑客现在不仅仅不能修改用户的数据，连看一眼的资格也没有了。

我们拿到服务器真正的公钥之后，就可以加密我们要传输的数据，这时我们解决了数据传输的机密性和端点鉴别，但并没有解决数据完整性这个问题，我们只需要根据要传输的数据，通过信息摘要算法，如SHA,MD5等生成一个指纹，放到要传输的数据后面一起加密发给服务器，服务器拿到数据解密之后，使用同样的摘要算法也生成一个指纹，与客户端传输过来的指纹进行比对，就可以知道数据有没有篡改，这样就解决了数据的完整性问题。

摘要算法又称哈希算法、散列算法。它通过一个函数，把任意长度的数据转换为一个长度固定的数据串（通常用16进制的字符串表示）。消息摘要算法的主要特征是加密过程不需要密钥，并且经过加密的数据无法被解密，只有输入相同的明文数据经过相同的消息摘要算法才能得到相同的密文

3、对称加密算法

但是非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对信息的加密使用的是对称加密。

对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。

而TLS在握手的时候就解决了秘钥K的保密性：

4、TLS握手

我把TLS握手分为了四个阶段，如图：

TLS建立第一阶段：

TLS握手的第一阶段，协商支持的TLS版本、压缩算法、加密套件等信息：

1. 客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。
2. 收到客户端问候之后服务器必须发送服务器问候信息，服务器会检查指定诸如TLS版本和算法的客户端问候的条件，如果服务器不支持所有条件，服务器将发送握手失败消息。如果接受，服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1 和Random2），这两个随机数会在后续生成会话秘钥时用到。

TLS建立第二阶段：

TLS握手的第二阶段，该阶段分为4步：

1. 下发证书：服务器将证书发给客户端，使客户端能拿到真正的服务器公钥。
2. 服务器密钥交换（可选）：这里视密钥交换算法而定
3. 证书请求：服务端可能会要求客户自身进行验证。
4. 服务器握手完成：第二阶段的结束，第三阶段开始的信号

注意：这里的服务器密钥交换（Server Key Exchange并不是服务器的公钥，不要被Server Key这个词迷惑，因为使用某些算法（如：DH）客户端无法自行计算预主密钥，而Server Key Exchange消息中便会包含完成密钥交换所需的一系列参数，能帮助我们计算预主秘钥

TLS建立第三阶段：

TLS握手的第三个阶段，生成会话秘钥：

1. 客户端对Random1和Random2进行处理计算出第三个随机数，称为预主秘钥，客户端通过内置在操作系统的CA公钥解析证书中的信息，得到服务器的公钥，使用服务器的公钥加密传输给服务器，服务器收到加密的预主秘钥以后会用自己的私钥解析得到预主秘钥，这样双方都得到相同的预主秘钥了，客户端和服务器都使用之前得到的第一个随机数和第二个随机数和预主秘钥通过相同的算法计算出相同的会话秘钥,以后双方都基于这个会话秘钥进行对称加密。

TLS建立第四阶段：

完成握手协议，建立SSL连接，进行可靠传输：

1. 双方基于秘钥K进行对称加密，确保数据安全传输

总结TLS握手流程：

1. 浏览器将自己支持的一套加密算法发给服务器，同时发一个浏览器随机数
2. 服务器向浏览器发送选择的加密算法、服务器生成的随机数、服务器数字证书
3. 浏览器收到证书后对证书的CA签名进行验证，如果验证通过，会从证书中拿到服务器的公钥
4. 浏览器对浏览器随机数+服务器随机数进行处理，生成预备主密码
5. 浏览器用服务器的公钥对预备主密码进行加密，发给服务器。
6. 服务器收到后使用自己的私钥解密出预备主密钥
7. 浏览器和服务器分别使用预备主密钥和两个随机数，生成共享主密钥
8. 二者使用共享主密钥，使用对称加密算法加密数据

5、证书信任链

不知道大家有没有想过这样一个问题，世界上这么多的CA机构凭什么都能够在微软的操作系统中内置他们的公钥，这得付出多大代价？况且如果新增一个CA机构，那么在已生产的电脑上由于没内置新增的CA机构的公钥，是不是就不能使用这个新增的CA机构颁发的证书？那他们是如何保障数据传输安全的呢，这也是阿里的面试官追问的一个问题。其实是依赖证书信任链实现的：

事实上，系统中并没有内置世界上所有 CA 机构的证书，只是内置了顶级 CA 机构的证书，而其他机构则通过信任链的方式进行证书的颁发。

假设 A 是顶级 CA，系统中内置该机构的证书。B 是 A 的子机构，A 给 B 颁发了 CA 证书，B 给服务器 C 颁发了 CA 证书，客户端验证服务器 C 的证书的过程如图：

1. 按照上文提到了证书验证方式，检查服务器 C 下发的证书。
2. 由于服务器 C 下发的证书是由 B 颁发的，因此需要先获取 B 的证书，然后使用 B 的证书中的公钥解密指纹并对比信息摘要。
3. 为了保证 B 的公钥真实可靠，需要验证 B 的证书，而 B 的证书是由 A 颁发的，所以使用 A 的公钥解密指纹并对比信息摘要。
4. A 的公钥内置在操作系统中，认为是真实有效地。

4、总结

最后，希望大家都能掌握HTTP和HTTPS。