从HTTP的安全问题到HTTPS

在说HTTPS之前，我们先说说HTTP通信过程中的一些问题风险

无加密处理的HTTP

HTTP为我们的网络通信带来了很多益处，但HTTP同样也有它的缺点，我们知道，HTTP是一个未加密的协议，所以在传输过程中，它有可能遇到以下风险

1. 窃听风险

通信使用明文（不加密），内容可能会被窃听
事实上，即使是已经加密了的通信，也会被窥视到通信内容，只是通过加密处理，别人可能无法得知传输内容的真实信息
窃听相同段上的通信，只需要手机在互联网上流动的数据包（帧）就行了。对于收集来的数据包的解析工作，课交给那些抓包或嗅探器工具。比如Wireshark，相关的抓包原理可见wireshark学习笔记----抓包网络原理

加密处理防止窃听

目前如何解决窃听风险的几种对策中，最为普及的就是加密技术了。

通信的加密

一种方式是将通信加密，虽然HTTP没有加密处理，但我们可以通过和SSL（Secure Socket Layer 安全接套层）或TLS（Transport Layer Security 安全传输协议）的组合使用，加密HTTP的通信内容

内容的加密

除了对通信的过程进行加密外，我们也可以对内容来进行一个加密。其实这就像一种翻译，只要能窃听到你通信内容的人都看不懂你写的这种语言，而接受内容的人懂，那就不怕内容会被窃听了。所以这种内容的加密，要求客户端和服务器端双方都同时具备加密和解密机制。

但由于只是对内容进行加密，所以不同于通信加密，在传输过程中还是有被篡改的风险的。

2. 冒充风险

不验证通信方的身份，因此有可能遭遇伪装
在HTTP通信时，由于不存在确认通信方的步骤，所以任何人都可以发起请求。而服务端只要接受到请求，不管是谁发出的，都会返回一个响应。

这样的做法，就导致了以下的问题

• 客户端发起的请求，无法确认是否真的发送到想要发送到的服务器那里，有可能是冒充的服务器返回给给客户端响应
• 无法确定返回的响应是否真的返回给了正确的客户端，可能会被返回到冒充的客户端
• 无法确定正在通信的对方是否具备访问权限，因为部分Web服务器上保存着重要的信息，只想发给特定的用户通信的权限。
• 无法判断请求是谁发出的
• 即使是无意义的请求也会照单全收，无法阻止海量请求下的DoS攻击（Denial of Service，拒绝服务攻击）

通过SSL提供证书

虽然使用HTTP协议无法确定通信方，但如果使用SSL则可以。SSL不仅有我们上面提到的通信加密处理，还提供了证书，可用于确定通信方。
证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。从技术角度上来说，伪造证书是很困难的，所以基本上只要我们能够确认通信方持有的证书，即可判断通信方的真实意图。
在http状态码中，401就是用来表示需要提供证书但没有证书的错误

3. 篡改风险

无法证明报文的完整性，所以有可能已经已遭篡改

由于HTTP无法证明报文的完整性，所以如果在客户端发送请求到服务端和服务端接受到请求报文这段时间内，或者是服务端返回响应报文到客户端获得响应报文的这段时间内，报文内容被修改了，HTTP是无法得知的。
这种从中间的这段时间拦截并篡改内容的攻击叫做中间人攻击（Man-in-the-Middle attack，MITM）

跟上面两种风险的解决方式一样，这里我们仍要使用到SSL。在使用SSL协议时，会在应用层附加一种叫做MAC的报文摘要，MAC能够查知报文是否遭到篡改，从而保护报文的完整性。

HTTPS对于风险的处理

在《图解HTTP》中有这么一条等式

HTTP+加密+认证+完整保护 = HTTPS

可以从这条等式看出，HTTPS实际上就是用来解决上面提到过的那些风险的，那么具体是怎么做到的呢，我们先简单认识以下SSL/TLS协议

SSL/TLS协议

我们知道，HTTPS是基于SSL/TLS协议之上的，不使用SSL/TLS协议的HTTP通信，即不加密的通信，所有的信息在传输的时候都会以明文的形式进行一个传输，那么就会带来以下风险
SSL/TLS协议为了解决以上风险，希望达到

• 1. 所有信息都是加密传输，第三方无法窃听
• 2. 具有校验机制，一旦发生更改，传输双方都能发现
• 3. 配备身份证书，防止身份被冒充

相互交换密钥的公开密钥加密技术

SSL采用一种公开密钥加密的加密处理方式
近代的加密方法中加密算法是公开的，而密钥是保密的，也就是说公开了上锁的方法，但是开锁的钥匙藏起来了，通过这种方式来保持加密方法的安全性

共享密钥加密（对称加密）的困境

在密钥加密技术中，我们将加密和解密共用一个密钥的方式称为共享密钥加密，也被称为对称密钥加密

使用对称加密必须将密钥也发送给对方，但这就涉及到一个问题，我们如何将密钥发送给对方，如果直接发送，那密钥就可能被别人监听获取，那别人也就可以对信息进行加密解密，加密就变得没有意义了

而如果我们能做到安全地发送密钥了，那说明数据也可以安全发送了，那又何必发送密钥来加密呢

使用两把密钥的公开密钥加密

为了解决上面的问题，我们可以采用非对称密钥加密，使用两把密钥，一把私有密钥，一把公有密钥。

所谓私有，自然就是不能被他人知道的，而公有密钥，是每个人都能知道的。使用公开密钥加密方式，发送密文的以方使用对方的公开密钥进行加密，对方收到被加密的信息后，再使用自己的私有密钥进行解密。

简单来说，就是一个锁，我们可以用公有的钥匙上锁，但是打开却只能用特有的一把私有的钥匙打开，只要自己不把私有的钥匙交出去，别人就无法去打开这个锁。

回到网络中，使用非对称加密，一开始由接收信息的一方，将公开密钥交给发送信息的一方，发送信息的一方使用该公开密钥对要发送的信息进行一个加密，发送给接收方，接收方再使用自己的私有密钥对信息进行解密，获取真正的内容。

这个方法的安全实现，需要一个技术上的不支持，那就是无法或者很难通过公开密钥和加密后的信息推导出原信息，否则公开密钥是所有人都能拿到的，而加密后的信息在传输过程中是可能被监听的，可以推导的话这个加密方法也显得不安全了。

好在要想根据密文和公开密钥，恢复到信息原文是异常困难的。在《图解HTTP》中就说到了

因为解密过程就是在对离散对数进行求职，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

HTTPS采用混合加密机制

虽然我们使用非对称的加密比起对称加密来说更为安全，但是非对称加密比起对称加密来说，消耗的时间更多，为了整合两者的优点，我们结合这两种方式来完成信息传输，这里会用到三把密钥，非对称加密的两把密钥，一把私有，一把公有，以及对称加密的一把公有密钥

我们知道，对称加密的问题就在于，我们无法保证公开密钥不会被他人知道，而通过使用非对称加密，我们可以讲公开密钥安全地交给发送方

所以，混合机密机制就是，在一开始通过使用非对称加密，将对称加密要用到的公开密钥交给发送方，然后后面的信息传递，都使用对称加密来对信息进行加密，这样后面的信息传递在加密这部分消耗的时间就会比较小，又通过非对称加密，保证了公开密钥的安全传输。

证明公开密钥正确性的证书

虽然我们上面采用的混合加密机制看起来好像已经足够安全了，但存在一个问题，我们如何确定一开始给我们发送对称加密时要用到的公开密钥的那个服务器，就是我们最终要连接的那个服务器呢。有可能在发送公开密钥的时候，发送密钥的这个服务器就是别人伪造的。

为了解决上面这个问题，可以使用由数字证书认证机构和其相关机关颁发的公开密钥证书。

数字证书认证机构出于客户端与服务器双方都可信赖的第三方机构的立场上，在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

所以，除了上面的混合加密机制中说到的步骤外，服务器还应将这份由数字证书认证机构办法的公钥证书发送给哭护短，以进行公开密钥加密方式通信。而接收到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确认证服务器的公开密钥时真实有效的数字证书认证机构，且服务器的公开密钥时值得信赖的。

整体步骤：

1. 服务器把自己的公开密钥登录至数字证书认证机构
2. 数字证书认证机构用自己的私有密钥向服务器的公开密码部署数字签名并颁发公钥证书
3. 服务器将公开密钥和数字证书认证机构的数字签名发送给客户端
4. 客户端拿到公钥证书后，使用数字证书认证机构的公开密钥想数字证书认证机构验证公钥证书上的数字签名后，以确认服务器的公开密钥真实性
5. 客户端使用服务器的公开密钥对报文进行加密后发送
6. 服务器用私有密钥对加密信息进行解密

HTTPS的安全通信机制

1. 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表
2. 服务器可进行SSL通信时，会以Server Hello报文做为应答。和客户端一样，在报文中包含SSL版本以及加密组件。
3. 之后服务器发送Certificate报文。报文中包含公开密钥证书。
4. 最后服务器发送Server Hello Done报文通知客户端，最初阶段的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报文。
10. 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。从此处开始，进行应用层协议的通信，即发送HTTP请求。
11. 最后由客户端断开连接。

HTTPS的缺点

HTTPS带来安全性的同时，不可避免地带来了一些缺点，最显著的，就是由于增加了很多额外的操作，导致处理速度变慢。

当HTTPS使用SSL时，有两个方面会导致处理速度变慢

1. 需要做服务器、客户端双方加密及解密处理，因此会消耗CPU和内存等硬件资源。
2. 和HTTP通信相比，SSL通信部分消耗网络资源。而SSL通信部分，又因为要对通信进行处理，所以时间上又延长了。

在《图解HTTP》中提到

针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种（专用服务器）硬件来改善问题。

除了速度变慢外，我们还需要去向认证机构购买使用的证书，而实际上，我们的一些个人网站完全没必要去做这样的安全性考虑，为这种意义不大的安全性考虑而花费经济，显然是不合算的。

参考文章：
https://developers.weixin.qq.com/community/develop/article/doc/000046a5fdc7802a15f7508b556413
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

参考书籍：
《图解HTTP》