【计算机网络】HTTPS协议原理
文章目录
- 一、认识HTTPS协议
- 二、为什么要发明HTTPS
- 三、HTTP与HTTPS的区别
- 四、常见的加密方式
-
- 1. 对称加密
- 2. 非对称加密
- 3. 数据摘要
- 4. 数字签名
- 五、HTTPS的原理探究
-
- 方案1：只使用对称加密
- 方案2：只使用非对称加密
- 方案3：双方都使用非对称加密
- 方案4：非对称加密 + 对称加密
- 引入证书
- 方案5：非对称加密 + 对称加密 + 证书认证
- 总结
一、认识HTTPS协议
HTTPS背景：
HTTPS是由网景公司（Netscape）于1994年发明的。在当时，网络刚刚兴起，人们开始使用互联网进行各种通信和交易，但是网络安全问题也随之成为人们关注的焦点。网景公司的工程师们在HTTP协议的基础上开发了SSL（Secure Sockets Layer）协议，通过在传输层对数据进行加密，从而保障网络传输的安全性。
后来，SSL协议逐渐得到了广泛的应用和推广，并在1999年被标准化为TLS（Transport Layer Security）协议。TLS协议是SSL的升级版，具有更高的安全性和可扩展性，被广泛应用于Web浏览器和Web服务器之间的数据传输，以确保网络通信的安全和隐私。
尽管网景公司在1998年被AOL收购，但HTTPS协议仍然被广泛应用于现代互联网中，成为了保护网络通信安全的标准协议。
HTTPS协议：
HTTPS是一种用于保护互联网通信安全的协议，全称为超文本传输安全协议（Hypertext Transfer Protocol Secure）。它是基于HTTP协议的加密传输协议，通过在传输数据之前使用加密算法（利用 SSL/TLS 来加密数据包）对数据进行加密，以确保通信的安全性。
HTTPS协议的加密过程主要分为三个步骤：握手、加密和身份验证。具体步骤如下：
-
握手阶段：客户端向服务器发起HTTPS连接请求，服务器会向客户端发送数字证书和公钥，客户端会验证证书的有效性，如果证书通过验证，客户端就生成一个随机数，使用服务器的公钥对其进行加密，然后将加密后的随机数发送给服务器。
-
加密阶段：服务器使用私钥解密客户端发送过来的随机数，然后使用这个随机数生成对称密钥，再将对称密钥用客户端的公钥进行加密，发送给客户端。客户端使用私钥解密服务器发送过来的对称密钥，然后使用这个密钥对所有传输的数据进行加密。
-
身份验证阶段：在握手阶段，客户端会验证服务器的数字证书，以确认连接的安全性。而服务器也可以要求客户端进行身份验证，以确认客户端的身份。
使用HTTPS协议可以有效地保护网站的访问安全性，防止数据被窃听、篡改、伪造等问题。对于一些需要保密性的数据交互，例如金融交易、个人账户信息等，使用HTTPS协议进行加密传输是非常必要的。
二、为什么要发明HTTPS
HTTPS的发明主要是为了解决HTTP协议的安全问题。
因为HTTP协议是一种基于文本的协议，所有传输的数据都是明文传输，因此容易被黑客截获并窃取敏感信息。例如，当用户在浏览器中输
入用户名和密码时，这些信息就以明文形式在网络上传输，黑客可以通过截获这些数据来获取用户的敏感信息。
HTTPS通过在HTTP协议的基础上增加了加密传输的功能，将传输的数据进行加密，从而保证通信的安全性。这使得HTTPS协议可以有效地保护网站的访问安全性，防止数据被窃听、篡改、伪造等问题。
此外，随着网络的发展和应用场景的不断拓展，越来越多的网站需要进行身份验证和身份认证。HTTPS协议通过数字证书的方式，可以对服务器和客户端进行身份验证，防止恶意用户伪造网站，从而保护用户的隐私和财产安全。
因此，HTTPS协议的发明是为了保障网络通信的安全和隐私，保护用户敏感信息不被窃取、篡改和伪造，使用户能够更加安全地浏览网页和进行网上交易。
三、HTTP与HTTPS的区别
HTTP（HyperText Transfer Protocol）是一种基于文本的协议，用于在Web浏览器和Web服务器之间传输数据，它的数据传输是明文传输，不提供加密和安全保障。而HTTPS（HyperText Transfer Protocol Secure）是HTTP协议的安全版本，提供了加密和身份认证的功能。
以下是HTTP和HTTPS之间的主要区别：
-
数据传输安全性
HTTP传输的数据是明文传输的，容易被黑客截获并窃取敏感信息。而HTTPS在HTTP的基础上增加了加密传输的功能，将传输的数据进行加密，从而保证通信的安全性。 -
传输协议
HTTP是基于TCP/IP协议进行通信的，而HTTPS在HTTP的基础上加入了SSL/TLS协议进行加密，以保证数据传输的安全性。 -
端口号
HTTP默认使用80端口进行传输，而HTTPS默认使用443端口进行传输。 -
证书和身份认证
HTTPS使用数字证书进行身份验证和身份认证，确保客户端和服务器的安全连接。而HTTP不需要进行身份验证和身份认证，容易被攻击者伪装。 -
性能
由于加密和身份验证的额外开销，HTTPS相对于HTTP会增加一些网络负载和延迟，因此会有一定的性能损失。
综上所述，HTTPS相比于HTTP具有更高的安全性和可信度，但会增加一定的性能开销。因此，对于需要保护用户隐私和数据安全的网站，应该采用HTTPS协议来确保通信的安全性。
四、常见的加密方式
1. 对称加密
采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密。其特征是：加密和解密所⽤的密钥是相同的。
最常见的对称算法包括AES（Advanced Encryption Standard）、DES（Data Encryption Standard）和3DES（Triple Data Encryption Algorithm）。
对称加密的特点：
- 算法公开、计算量⼩、加密速度快、加密效率⾼。
对称加密其实就是通过同⼀个 “密钥”，把明文加密成密文，并且也能把密文解密成明文。例如一个简单的对称加密：按位异或。
假设明文：a = 1234，密钥：key = 8888。
则加密 a ^ key 得到的密文b为9834。
然后针对密文 9834 再次进行运算 b ^ key，得到的就是原来的明文 1234。
对于字符串的对称加密也是同理，每⼀个字符都可以表示成⼀个数字。
当然，按位异或只是最简单的对称加密，而HTTPS中并不是使用按位异或来进行加密。
2. 非对称加密
非对称加密需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
常见的非对称加密算法包括RSA（Rivest-Shamir-Adleman）、DSA（Digital Signature Algorithm）和ECC（Elliptic Curve Cryptography）。
非对称加密的特点：
- 算法强度复杂、安全性依赖于算法与密钥。但是由于其算法复杂，使得加密解密速度没有对称加密解密的速度快。
公钥和私钥是配对的，最大的缺点就是运算速度非常慢，比对称加密要慢很多。一般加密和解密方式如下：
- 通过公钥对明文加密，变成密文
- 通过私钥对密文解密，变成明文
也可以反着使用：
- 通过私钥对明文加密，变成密文
- 通过公钥对密文解密，变成明文
3. 数据摘要
数据摘要（Data digest），也称为哈希值（Hash），是指将任意长度的数据通过一个特定的算法，转化成固定长度的数字或字母序列。摘要值通常具有以下特点：
-
输入数据的任意微小变化都会导致输出结果的明显差异。
-
输入数据相同，生成的摘要值也必定相同。
-
摘要值是不可逆的，无法通过摘要值推算出原始数据，通常用来进行数据对比判断数据有没有被窜改。
摘要常见算法包括MD5、SHA-1、SHA-2等。需要注意的是，由于摘要值是固定长度的，因此无论输入数据有多长，摘要值的长度总是相同的。这意味着在输入数据较大时，可能会发生哈希碰撞（Hash collision），即两个不同的输入数据生成了相同的摘要值，因此在使用哈希算法时需要注意这种风险。
4. 数字签名
数字签名（Digital Signature）是指利用公钥密码学技术对数字信息进行签名，以证明信息的完整性、来源和不可抵赖性。数字签名通常包括两个过程：签名和验证。
在签名过程中，发送方使用私钥对原始数据进行加密，生成数字签名。数字签名可以证明发送方对原始数据进行了签名，并且保证数据的完整性和不可抵赖性。在验证过程中，接收方使用发送方的公钥对数字签名进行解密，以验证数字签名的真实性和完整性。
数字签名的主要作用是确保数字信息的可靠性和安全性。它可以防止信息被篡改、冒充和否认，同时也能确保信息的来源和完整性。数字签名技术在电子商务、电子政务、网络支付和数字版权保护等领域得到了广泛的应用。
常用的数字签名算法包括RSA、DSA、ECDSA等。其中，RSA是最常用的数字签名算法之一，它使用公钥加密、私钥解密的方式对数字信息进行签名和验证。DSA和ECDSA则是基于椭圆曲线密码学的数字签名算法，具有更高的安全性和更短的密钥长度。
五、HTTPS的原理探究
方案1：只使用对称加密
如果通信双方都各自持有同⼀个密钥X，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。
引入对称加密之后，即使数据被截获，由于黑客不知道密钥是啥，因此就无法进行解密，也就不知道请求的真实内容。
但事情没这么简单。服务器同一时刻其实是给很多客户端提供服务的。这么多客户端，每个的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了，黑客就也能轻易拿到)。因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情。
比较理想的做法就是能在客户端和服务器建立连接的时候，双方协商确定这次的密钥：
但是如果直接把密钥明文传输，那么⿊客也就能获得密钥了，此时后续的加密操作就形同虚设。因此密钥的传输也必须加密传输，但是要想对密钥进行对称加密，就仍然需要先协商确定⼀个 “密钥的密钥”，这就成了 “先有鸡还是先有蛋” 的问题了。此时密钥的传输再用对称加密就行不通了。
方案2：只使用非对称加密
鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，从客户端到服务器信道似乎是安全的，因为只有服务器有相应的私钥能解开公钥加密的数据。
但是服务器到浏览器的这条路怎么保障安全？
如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是⼀开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了，因此只使用非对称加密也是行不通的。
方案3：双方都使用非对称加密
例如：
- 服务端拥有公钥S与对应的私钥S’，客户端拥有公钥C与对应的私钥C’ 。
- 然后客户端和服务端交换公钥。
- 客户端给服务端发信息：先用S对数据加密，再发送，此数据只能由服务器解密，因为只有服务器有私钥S’ 。
- 服务端给客⼾端发信息：先用C对数据加密，在发送，此数据只能由客户端解密，因为只有客户端有私钥C’ 。
这样的加密方式看似行得通，但是别忘了非对称加密最大的缺点就是运算速度非常慢，因此效率会非常低，并且也会存在安全问题。
例如中间人在双方建立连接一开始就截取了服务端发送给客户端的公钥，然后替换成自己的公钥，因此客户端就会误以为是服务端的公钥，导致此后双方通信的数据被破解。
方案4：非对称加密 + 对称加密
这样的加密方式可以解决效率问题：
- 服务端具有非对称公钥S和私钥S’ 。
- 客户端发起HTTPS请求，获取服务端公钥S。
- 客户端在本地生成对称密钥C，通过公钥S加密，发送给服务器。
- 由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥（理论上如此）。
- 服务器通过私钥S’解密，还原出客户端发送的对称密钥C，并且使用这个对称密钥加密给客户端返回的响应数据。
- 后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客户端和服务器两个主机知道，其他主机不知道密钥即使截获数据也没有意义。
由于对称加密的效率比非对称加密高很多，因此只是在开始阶段协商密钥的时候使用非对称加密，后续的传输仍然使用对称加密。
虽然上面的加密方式已经比较接近实际原理了，但是依旧有安全问题。因为方案2、方案3、方案4都存在⼀个共同的问题：那就是如果最开始建立连接的时候，中间人（Man-in-the-MiddleAttack，简称“MITM攻击”。）就已经开始攻击了呢？
中间人攻击：针对上面的场景：
在方案 2/3/4 中，客户端获取到公钥S之后，对客户端形成的对称秘钥X用服务端给客户端的公钥S进行加密，中间⼈即使窃取到了数据，此时中间⼈确实无法解出客⼾端形成的密钥X，因为只有服务器有私钥S’。但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不⼀定了，假设hacker已经成功成为中间人：
- 服务器具有非对称加密算法的公钥S，私钥S’。
- 中间人具有非对称加密算法的公钥M，私钥M’。
- 客户端向服务器发起请求，服务器明文传送公钥S给客户端。
- 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端。
- 客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了)，形成对称秘钥X，用公钥M加密X，形成报文发送给服务器。
- 中间人劫持后，直接用自己的私钥M’进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器。
- 服务器拿到报文，用自己的私钥S’解密，得到通信秘钥X。
- 双方开始采用X进行对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进行窃听甚至修改数据，都是可以的。
上⾯的攻击方案，同样适用于方案2和方案3。其问题的本质就是：客户端无法确定收到的含有公钥的数据报⽂，就是目标服务器发送过来的！
引入证书
CA认证：
CA证书（Certificate Authority Certificate）是一种数字证书，由认证机构（Certificate Authority，简称CA）颁发给其它数字证书。它是一种用于身份验证和加密通信的工具，用于确保网络通信的机密性、完整性和可信性。
CA是一个第三方机构，其任务是验证证书申请人的身份，并为该申请人颁发数字证书。数字证书中包含了证书申请人的公钥、CA的公钥以及其他相关信息，包括证书有效期和用途等。
当一个用户在浏览器中访问一个使用了数字证书保护的网站时，浏览器会验证该网站的数字证书是否由已知和可信任的CA颁发，并且证书是否已被撤销。如果验证成功，浏览器将建立一个安全的加密连接，确保所有通信都是加密的、完整的和安全的。
这个 证书 可以理解成是⼀个结构化的字符串，里面包含了以下信息：
- 证书发布机构
- 证书有效期
- 公钥
- 证书所有者
- 签名
- 服务器的基本信息
- …
需要注意的是：申请证书的时候，需要在特定平台生成，才会同时生成一对公钥和私钥。这对密钥就是用来在网络通信中进行明文加密以及数据签名的。其中公钥会随着CSR文件，⼀起发给CA进行权威认证，私钥服务端自己保留，用来后续进行通信（其实主要就是用来交换对称秘钥）。
例如下列流程：
当服务端申请CA证书的时候，CA机构会对该服务端进行审核，并专门为该网站形成数字签名，过程如下：
- CA机构拥有非对称加密的私钥A和公钥A’。
- CA机构对服务端申请的证书明文数据进行Hash，形成数据摘要。
- 然后对数据摘要用CA私钥A’加密，得到数字签名。
服务端申请的证书明文和数字签名S，共同组成了数字证书，这样一份数字证书就可以颁发给服务器了。
方案5：非对称加密 + 对称加密 + 证书认证
在客户端和服务器刚⼀建⽴连接的时候，服务器给客户端返回⼀个证书，其中包含了之前服务端的公
钥，也包含了网站的身份信息。
客户端进行认证：
当客户端获取到这个证书之后，会对证书进行以下校验，以防止证书是伪造的。
- 判定证书的有效期是否过期。
- 判定证书的发布机构是否受信任，现在操作系统中已内置的受信任的证书发布机构。
- 验证证书是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到⼀个hash值(称为数据摘要)，设为hash1。然后计算整个证书的hash值，设为hash2。对比hash1和hash2是否相等。如果相等，则说明证书是没有被篡改过的。
中间人有没有可能篡改该证书？
- 假如中间人篡改了证书的明文。
- 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后
的证书形成匹配的签名 - 如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
如果中间整个掉包证书?
- 因为中间人没有CA私钥，所以无法制作假的证书。
- 所以中间人只能向CA申请真证书，然后用自己申请的证书进行掉包。
- 这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
- 因为中间人没有CA私钥，所以对任何证书都无法进行合法修改，包括自己的证书。
使用HTTPS进行通信的完整流程：
总结
HTTPS工作过程中涉及到的密钥有三组：
- 第一组(非对称加密)：用于校验证书是否被篡改。服务器持有私钥(私钥在形成CSR文件与申请证书时获得)，客⼾端持有公钥(操作系统包含了可信任的CA认证机构有哪些，同时持有对应的公钥)。服务器在客户端请求是，返回携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性。
- 第二组(非对称加密)：用于协商⽣成对称加密的密钥。客户端用收到的CA证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。
- 第三组(对称加密)：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。
其实⼀切的关键都是围绕这个对称加密的密钥，其他的机制也都是辅助这个密钥进行工作的。
- 第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器。
- 第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥。