一、HTTP的不足

HTTP 主要有这些不足，例举如下：

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文使用明文（指未经过加密的报文）方式发送。

所谓互联网，是由能连通到全世界的网络组成的。无论世界哪个角落的服务器在和客户端通信时，在此通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到恶意窥视行为。

即使已经过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

HTTP 协议中虽然没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。

用 SSL建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）。

为了方便叙述，后续SSL/TLS统称为SSL，两者可以视为同一个东西的不同阶段。

HTTP协议在发送请求和接收响应的时候，不会去核实对方是不是真的目标。这就好比说，当你通过网址向一个服务器发请求时，协议本身不会检查这个服务器是不是你真正想要联系的那个；同样地，当服务器给你回复信息时，协议也不会确认这个回复是不是真的发给了提出请求的那个客户端。简而言之，HTTP协议在这个过程中不会验证双方的身份，这就可能存在一些不确定性。

虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL则可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。

证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。另外，客户端持有证书即可完成个人身份的确认，也可用于对Web 网站的认证环节。HTTPS使用 SSL 和 TLS 这两个协议。但当使用 SSL 时，它的处理速度就会变慢。因为HTTPS还需要做服务端、客户端双方加密解密处理，会消耗CPU和内容等硬件资源。

---

二、HTTP + 加密 + 证书 + 完整性保护 = HTTPS

如果在用HTTP协议上网的时候，你的信息没有加密，就像在网页上直接输入信用卡号，如果有人在这条线路上偷听，那你的信用卡号就可能被别人知道了。

而且，用HTTP协议的时候，不管是服务器还是你的电脑，都没法确定跟你通信的那边是不是真的。可能你以为是跟某个网站说话，实际上是跟别的不法分子在交流。还得考虑到在信息传递的过程中，可能被别人改过。为了解决这些问题，我们需要在HTTP协议上加一些加密和验证的机制。我们把加了这些安全机制的 HTTP 叫做 HTTPS（HTTP Secure）。

在上网的时候，像登录网站或者在网上买东西要付钱的那种页面，经常会用到一个叫HTTPS的安全通信方式。用这种方式的时候，网址前面不再是http://，而是变成了https://。而且，当使用浏览器访问这些用了HTTPS的安全网站时，会在浏览器的地址栏那里看到一个锁头标志。

HTTPS 并非是一种应用层的新协议。只是 HTTP 通信接口部分用 SSL 和 TLS 协议代替而已。通常 HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。在采用了SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。

---

三、加密与解密

简单来说，就是用密钥把能看懂的文字（明文）转换成看不懂的文字（密文）。解密和解密都会用到密钥，没有密钥就无法对密码进行解密，反之，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那么加密就失去了意义。

1、对称密钥加密

加密和解密同用一个密钥的方式称为对称密钥加密。

当我们使用对称密钥加密方法时，必须把密钥也传给对方，这样才能解密信息。但是，这里有个问题：怎么才能确保密钥在传递过程中的安全呢？如果在互联网上发送密钥的时候被别人监听了，那么这个密钥就可能被攻击者截获，这样一来，加密就失去了它的保护作用。而且，还得想个办法安全地保存收到的密钥，防止它被泄露或者被不当使用。这些都是使用对称密钥加密时需要解决的问题。

2、非对称密钥加密

非对称密钥加密使用了一对不一样的密钥，一把称为私钥，一把称为公钥。即，私钥不能让别人知道，公钥则可以随意发布，任何人都可以获得。

使用公开密钥加密的方法，可以解决对称密钥加密中密钥传递的安全问题。具体来说，当你想要发送加密信息的时候，你使用接收方的公开密钥来加密信息。这样，信息在网络上传输的时候，即使被别人拦截，他们也无法解密，因为解密需要接收方的私有密钥，而这个密钥是只有接收方自己知道的，没有发送出去。

这种方式的好处在于，你不需要担心在传递密钥的过程中密钥会被偷走，因为解密的私有密钥根本就没有在网络上传输。而且，即使有人得到了加密后的信息（密文）和公开密钥，他们想要恢复出原始信息（明文）是非常困难的。这是因为解密过程涉及到复杂的数学问题，比如离散对数的计算，这不是简单就能完成的任务。

另外，如果你能快速地分解一个非常大的整数，理论上是可以破解这种加密的。但是，以目前的技术水平来看，对于足够大的整数进行快速因式分解是不现实的，所以这种加密方法被认为是安全的。这就是为什么公开密钥加密被广泛用于安全通信，比如在HTTPS协议中，确保了网络传输的安全性和数据的机密性。

但是如果攻击者在发送公钥时，在通信双方之间插入自己，使得双方都认为他们正在与对方直接通信。攻击者可以截取并使用自己的公钥替换双方的公钥，从而解密和重新加密双方之间的通信。

HTTPS 采用对称密钥加密和非对称密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用对称密钥加密来通信。但是非对称加密与对称密钥加密相比，其处理速度要慢。

所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

3、证书

如上所述，非对称加密也存在问题。即无法证明非对称加密密钥的公钥就是对方发送给我的那个，有可能真正的公钥就已经被攻击者掉包了。

为了解决上述问题，使用了由数字证书认证机构和其相关机构颁发的证书。CA机构，即证书授权中心（Certificate Authority），是一个在公钥基础设施（PKI）中提供、管理、和验证数字证书的第三方信任机构。CA机构的主要职责是确保公钥确实属于它所声称的实体，并通过颁发数字证书来证实这一点。也就是说CA机构是一个客户端和服务器都信任的第三方机构。

下面是CA机构的业务流程：

1. 申请公开密钥：服务器运营人员向数字证书认证机构提出公开密钥的申请。
2. 验证身份：数字证书认证机构会验证申请者的身份，确保他们是他们声称的那个人或组织。
3. 数字签名：一旦身份得到确认，数字证书认证机构就会对申请的公钥进行数字签名。这个签名保证了公钥的真实性和完整性。
4. 颁发证书：数字证书认证机构将签名的公钥放入一个公钥证书中，并将这个证书颁发给服务器。
5. 发送证书：服务器将这份由数字证书认证机构颁发的公钥证书发送给客户端，以便进行公开密钥加密的通信。

公钥证书也被称为数字证书或简称为证书。客户端接收到证书后，会进行以下操作：

• 验证数字签名：客户端使用数字证书认证机构的公开密钥来验证证书上的数字签名。
• 确认证书有效性：如果签名验证通过，客户端就可以确认两件事情：一是证书是由一个真实有效的数字证书认证机构签发的；二是服务器的公开密钥是可以信赖的。

关于认证机关的公钥的安全转交问题，由于直接通过通信方式转交存在困难，大多数浏览器开发商在发布浏览器版本时，会预先在浏览器内部植入常用认证机关的公钥。这样，当客户端访问一个使用HTTPS的网站时，浏览器可以自动验证网站证书的有效性，确保用户的安全。

最后，我们看看数字证书通常包含了：

• 服务器的非对称密钥中的公钥；
• 持有者信息；
• 证书认证机构（CA）的信息；
• CA 对这份文件的数字签名及使用的算法；
• 证书有效期；
• 还有一些其他额外信息；

数据摘要，也叫数据指纹。其基本原理是利用单向散列函数（Hash函数）【这类函数接受输入（可以是任意长度的数据），并输出一个固定长度的散列值（哈希值）。这个过程是单向的，即无法从散列值反推出原始数据】对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被修改。

数据摘要可以用来检查数据在传输或存储过程中是否被篡改。通过比较原始数据的散列值和接收到的数据的散列值，可以确定数据是否保持完整。

数据签名是一种用于验证数字信息或文档完整性和来源的技术。下面是它的工作流程：

1. 生成签名：

   • 哈希函数：首先，对要签名的数据进行哈希处理，生成一个固定长度的数据摘要（哈希值）。
   • 私钥加密：然后，使用签名者的私钥对这个哈希值进行加密，生成数字签名。

2. 验证签名：

   • 公钥解密：接收方使用签名者的公钥对数字签名进行解密，得到哈希值。

   • 哈希比较：接收方对接收到的原始数据进行哈希处理，生成一个新的哈希值，并将其与解密得到的哈希值进行比较。

   • 如果两个哈希值相同，则验证成功，表明数据在传输过程中未被篡改，并且是由持有私钥的签名者所签名的。

也就是说，客户端第一次请求时，得到的返回结果，不仅仅得到了服务器的非对称密钥中的公钥，实际上客户端是得到了一个证书。证书：明文信息+签名数据。证书在服务端，但是证书是从哪里的？服务端在使用 HTTPS 前，要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。

存在中间人攻击并对数字证书进行了篡改，我们是如何保证客户端收到的服务器发送的数字签名的正确性？

存在以下情况：

1. 证书篡改：攻击者可能会修改证书的内容，比如更改公钥为攻击者自己的公钥，或者修改证书中的其他信息。
2. 证书替换：攻击者可能会用自己的证书（可能是自签名的或者由不可信的CA签发的）替换掉原始的证书。

数字签名的验证过程：

1. CA证书的签发：当客户端向服务器发起请求时，服务器会发送它的数字证书。这份证书中包含了服务器用于加密的公钥和其他信息（如服务器的身份信息）。服务器的数字证书是由CA机构签署的，签名是由CA使用其私钥生成的。服务器在向CA机构申请生成CA证书时，CA机构会对证书中的数据（如服务器的公钥和身份信息）进行哈希运算，最后CA机构使用CA的私钥对这个哈希值进行加密，生成数字签名。服务器将申请到的这个数字签名和证书一起发送给客户端。

2. CA证书的验证：当客户端收到服务器发送的证书后，它会使用内置的CA公钥来解密证书中的数字签名。如果解密成功，并且解密后的哈希值与客户端自己计算的哈希值一致，那么客户端就可以确认这个证书确实是由受信任的CA签发的，且在传输过程中没有被篡改。

如果收到了中间人攻击：

1. 中间人无法伪造签名：

   • 即使中间人截获了服务器发送的证书，并试图篡改证书内容（例如，替换服务器的公钥），他也无法生成一个有效的数字签名，因为他没有CA的私钥。
   • 只有拥有CA私钥的机构（即真正的CA）才能生成匹配的签名。中间人即使知道生成签名的算法，也无法在没有CA私钥的情况下生成合法的签名。

2. 篡改后的证书会导致验证失败：

   • 如果中间人篡改了证书内容（如替换了服务器公钥），客户端在解密数字签名后会发现，解密得到的哈希值与客户端计算出的哈希值不匹配。

   • 这意味着证书已经被篡改，客户端会拒绝信任这个证书，并且中止与服务器的通信。

3. 内置的CA证书：

   • 客户端（如浏览器）内置了很多受信任的CA证书。这些CA证书中的公钥是用来验证服务器证书的签名的。

   • 这些内置的CA证书是由浏览器厂商和操作系统开发商精心管理和更新的，它们确保客户端可以信任来自这些CA的证书。

也就是说中间人如果强行篡改服务器发向客户端的证书，客户会发现证书中的明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

也就是说HTTPS工作过程设计到的密钥有三组：CA的非对称密钥、服务器的非对称密钥，以及客户端和服务器之间的对称密钥。

HTTPS共作过程中涉及到的密钥有三组：

第⼀组（非对称加密）：用于校验证书是否被篡改。服务器持有私钥（私钥在形成CSR文件与申请证书时获得），客户端持有公钥（操作系统包含了可信任的CA认证机构有哪些，同时持有对应的公钥）。服务器在客⼾端请求时，发送携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性。

第二组（非对称加密）：用于协商生成对称加密的密钥。客户端用收到的CA证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器,服务器通过私钥解密获取到对称加密密钥。

第三组（对称加密）：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。其实⼀切的关键都是围绕这个对称加密的密钥。其他的机制都是辅助这个密钥工作的。

第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器，即服务端生成的非对称密钥中的公钥。第⼀组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥，CA机构的公钥。

HTTPS的整体过程：

在服务器收到客户端请求的时候，服务器把自己生成的一个非对称加密的公钥通过CA证书传递给客户端，然后客户端通过CA证书的公钥对证书进行验证。验证成功后，根据得到服务器发送过来的公钥，对自己生成的对称加密的密钥进行加密。服务器得到由客户端使用服务器公钥加密过的数据（这个数据是客户端生成的对称加密的密钥），最后使用服务器的私钥进行解密 得到对称密钥。

1. 客户端发起请求：客户端向服务器发送HTTPS请求，要求建立安全连接。

2. 服务器响应并发送证书：服务器收到请求后，会发送自己的数字证书（包含服务器自己生成的非对称密钥中的公钥、数字签名以及其他的信息）给客户端。这个证书由可信的证书颁发机构（CA）签名。

3. 验证证书：客户端收到证书后，会使用内置的CA公钥来验证服务器证书的真实性。如果证书有效且可信，客户端会继续，否则会中断连接并向用户发出警告。

4. 生成对称加密密钥：客户端验证证书成功后，会生成一个随机的对称加密密钥，并使用服务器的公钥对客户端自己生成的密钥进行加密。

5. 发送加密的对称加密密钥：客户端将加密后的对称加密密钥发送给服务器。

6. 服务器解密对称加密密钥：服务器使用自己的私钥解密收到的对称加密密钥，从而获得客户端生成的对称加密密钥。

7. 建立安全通信：从此刻起，客户端和服务器都使用这个对称加密密钥进行通信。这种对称加密方式可以保证数据传输的保密性和完整性，因为对称加密在速度和效率上优于非对称加密。

整个过程确保了数据在传输过程中是加密的，并且只有通信的双方能够解密，防止中途被窃听或篡改。操作系统和浏览器会定期更新信任的CA证书列表，确保新增的信任根证书和已撤销的CA证书的变化能及时反映在用户设备上。

非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的数据摘要（哈希值）加密。

CA证书的安全性和中间人攻击的情况？

当访问一个网站时，服务器会将其公钥连同CA签发的数字证书一并发送给浏览器。浏览器会使用已信任的CA的公钥对证书进行验证，确保公钥的合法性。

浏览器通常会内置一组经过审核的CA证书，这些证书的公钥用来验证其他证书的签名。这种方式确保用户无需手动获取和管理信任的CA证书，并提供即时的安全性。

用户可以手动下载和安装CA证书，并将其标记为信任。这样可以在访问相关网站时，使用手动下载的证书进行验证。假设你在两个月前手动下载并验证了一个CA证书的公钥，那么此时该证书的公钥在你的设备上是安全和可信的。

如果我在两个月前下载了正确的CA证书，并且该证书的公钥没有被篡改，那么即使黑客在中间进行了攻击，只要我们在访问网站时使用的是这个可信的公钥，攻击者就无法伪造或篡改我们的通信。这是因为即使黑客截获了我们与服务器之间的通信，他们也无法解密或伪造使用该公钥加密的数据，除非他们掌握了对应的私钥。

虽然下载的CA证书的公钥是安全的，但CA证书本身是有有效期的，通常需要定期更新。如果证书出现问题或被发现不再可信，证书撤销列表（CRL）或在线证书状态协议（OCSP）会及时标记该证书，防止浏览器继续信任它。

TTPS和HTTP的区别主要在于安全性和加密方式：

1. 建立连接时：HTTPS比HTTP多了TLS的握手过程。当使用HTTPS时，客户端和服务器在建立连接之前，会先进行一个叫做TLS握手的过程。这个过程包括客户端向服务器索要并验证服务器的公钥，确保服务器是它声称的那一个。然后，双方会协商产生一个会话秘钥，这个秘钥用来加密双方之间的通信内容。
2. 传输内容时：HTTPS会把数据进行加密，通常是使用对称加密。这意味着在传输过程中，数据是以加密的形式传输的，这样即使数据在传输过程中被截获，攻击者也无法理解数据的内容。

HTTP协议是一种以字符串明文传输的简单的请求-响应协议，在传输层基于TCP协议实现。HTTP协议默认使用80端口。HTTPS协议是一种对HTTP加密后的协议，主要是多了身份验证以及加密传输等功能，HTTPS协议默认使用443端口。

总结来说，HTTPS通过TLS协议提供了一种加密的通信方式，可以防止数据在传输过程中被截获和窃取，而HTTP则是明文传输，没有加密。因此，HTTPS比HTTP更加安全。