【应用层3】Https

要点

Http的缺点

HTTP 主要有这些不足，如下，这些问题不仅在 HTTP 上出现，其他未加密的协议中也会存在这类问题。

• 通信使用明文，内容可能会被窃听
• 不验证通信方的身份，通信方有可能为伪装的
• 无法证明报文的完整性，报文内容有可能已遭篡改

1、通信使用明文，内容可能会被窃听

HTTP 本身不具备加密的功能，所以无法做到对通信的请求报文、响应报文进行加密。HTTP 报文使用明文方式发送。

（1）为啥需要加密呢？

Http协议属于TCP/IP协议族中应用层协议，按TCP/IP 协议族的分层工作机制，通信内容在所有的通信线路上都有可能遭到窥视。为了防止通信内容被窃听这时就需要加密了。

注意已经过加密处理的通信，也会被窥视到通信内容。只是说通信经过加密可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

（2）加密处理的方式

1、将通信进行加密，也即通信的Http报文全部加密处理。

http协议本身是不具有加密机制的，这就需要结合SSL（安全传输协议）或者TSL（安全套接层）了，他们提供了加密功能，可将通信进行加密。

2、内容的加密，也即只加密报文的请求报文内容和响应报文内容。

http协议本身是不具有加密机制的,在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送请求。为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。

注意：该方式不同于 SSL或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。

2、不验证通信方的身份，通信方有可能为伪装的

（1）HTTP 协议中的请求和响应不会对通信方进行确认这就可能出现哪些问题？

1、服务器是伪装的

无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。

2、客户端是伪装的

无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。

3、服务端无法判断请求来自哪里
4、服务端有请求就会响应

即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）。

5、无法确定正在通信的对方是否具备访问权限

某些Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。

（2）如何验证通信方的身份？

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

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

通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。另外，客户端持有证书即可完成个人身份的确认，也可用于对Web 网站的认证环节。

3、无法证明报文的完整性，报文内容有可能已遭篡改

由于 HTTP 协议无法证明通信的报文完整性，也即没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的。

（1）如何防止被篡改

有使用MD5、SHA1、等散列值校验的方法来确认Http协议报文的完整性，但是这并不可靠、便捷。

如常见的文件下载网站会提供相应的以 PGP（Pretty Good Privacy，完美隐私）创建的数字签名及 MD5 算法生成的散列值。PGP 是用来证明创建文件的数字签名，MD5 是由单向函数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。

为了有效防止这些弊端，有必要使用 HTTPS。SSL提供认证和加密处理及摘要功能。

HTTPS 与SSL简介

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。

通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。

SSL提供了加密、证书和完整性保护这些功能。SSL是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术。

SSL技术最初是由浏览器开发商网景通信公司率先倡导的，该公司开发了SSL1.0 、SSL2.0。但是存在一些问题。目前主导权已转移到 IETF（Internet Engineering Task Force，Internet 工程任务组）的手中。IETF完善协议开发了SSL3.0，IETF 以 SSL3.0 为基准，后又制定了 TLS1.0、TLS1.1 和TLS1.2。TSL是以 SSL为原型开发的协议，有时会统一称该协议为 SSL。当前主流的版本是 SSL3.0 和 TLS1.0。

公开密钥加密技术

SSL采用公开密钥加密（Public-key cryptography，也即非对称加密）的加密处理方式。

近代的加密方法中加密算法是公开的，而密钥却是保密的。加密和解密都会用到密钥，没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。

1、共享密钥加密及其弊端

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。常见的对称加密算法：DES，AES，3DES等等。

共享密钥加密只有一个秘钥，作为私钥，通信双方以共享密钥方式加密时必须将密钥也发给对方。加密解密用同一个密钥，被黑客拦截不安全如下图解：

以共享密钥方式加密时必须将密钥也发给对方，究竟怎样才能安全地转交？这时另一种加密方式出来了，非对称加密。

2、公开密钥加密

公开密钥加密又叫非对称加密，公开密钥加密方式很好地解决了共享密钥加密的困难。

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。公有密钥公布出去因此得名。

（1）原理& 好处

发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。

利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。

退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

3、共享密钥加密&公开密钥加密的优缺点

（1）共享密钥加密

优点：

• 算法公开
• 计算量小、
• 加密速度快、
• 加密效率高。

缺点：

• 秘钥的管理和分发非常困难，不够安全。在数据传送前，发送方和接收方必须商定好秘钥，然后双方都必须要保存好秘钥，如果一方的秘钥被泄露，那么加密信息也就不安全了。
• 每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

（2）公开密钥加密

优点：

• 安全性更高，
• 公钥是公开的，秘钥是自己保存的，不需要将私钥给别人。

缺点：

• 加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

4、https的抉择

HTTPS 采用混合加密机制，结合二者的优点在交换密钥时使用公开密钥加密方式。这样就可保证共享密钥的安全性。之后的建立通信交换报文阶段则使用共享密钥加密方式，因为公开密钥加密太消耗性能、浪费时间。

证书的概念

上述的http混合加密机制看起来已经很完美了，但是还是存在一个弊端的：那就是无法证明公开密钥本身就是货真价实的公开密钥。

比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。流程如下图解：

Https安全通信机制

1、SSL第一次握手

上图步骤1、2、3、4是SSL第一次握手部分，这次握手的目的主要是协商加密信息：

• 步骤1：客户端向服务端发送送Client Hello 报文开始 请求SSL通信。请求报文中主要是SSl的一些信息如：客户端支持的 SSL的指定版本、使用的加密算法、密钥长度等。

• 步骤2：服务器可进行 SSL通信时，会以 Server Hello 报文作为应答。应答报文中包含 SSL版本以及加密组件信息。服务器的加密组件信息是从接收到的客户端加密组件内筛选出来的。

• 步骤3：服务器发送 Certificate 报文。报文中包含公开密钥证书。

• 步骤4：最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL握手协商部分结束。

2、SSL第二次握手

• 步骤5：SSL第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
• 步骤6：接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
• 步骤7：客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。（这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。）
• 步骤8：服务器同样发送 Change Cipher Spec 报文。
• 步骤9： 服务器同样发送 Finished 报文。

3、进行http

• 步骤10：服务器和客户端的 Finished 报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到 SSL的保护。从此处开始进行应用层协议的通信，客户端发送 HTTP 请求。
• 步骤11：服务器发送 HTTP 响应。

4、Https通信结束

• 步骤12：最后由客户端断开连接。断开连接时，发送 close_notify 报:文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

在以上流程中，应用层发送数据时会附加一种叫做 MAC（MessageAuthentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。

整体图解:

The End

参考<图解HTTP>