《图解HTTP》读书笔记（四）——HTTPS和用户身份认证

前言

       本文是本系列的第四篇，主要记录了HTTPS和用户身份认证的相关知识，如果有错误烦请大家指出。

确保Web安全的HTTPS

1.HTTP的缺点

• 使用明文通信，可能会被窃听。
         我们都知道，HTTP协议是基于TCP/IP协议族的，按照其工作机制，通信内容在所有通信线路上都有可能遭到窥视。这是因为任何一个服务器和客户端进行通信时，这条通信线路上的网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除在某个环节会遭到恶意窥探。
         这也就是说即使是已经经过加密的通信也会被窥视到通信内容，只不过通信经过加密后，恶意窃听通信的人可能无法破解加密的报文，但加密之后的报文还是会被看到的。
  
         而加密技术最常见的对象有两个——通信的加密和内容的加密。
         所谓通信的加密就是将HTTP与SSL或者TSL组合使用，用SSL建立安全通信线路之后就可以在这条线路上进行HTTP通信了（本文讲的HTTPS即HTTP与SSL的组合使用）。
         而内容的加密就更好理解，它是将参与通信的内容本身进行加密，也就是将HTTP报文的内容（注：报文首部是不加密的，报文主体进行加密）加密处理。诚然，对内容加密可以避免通信内容被窃听，但通信内容仍有可能被篡改。

• 不认证通信双方的身份，因此有可能遭遇伪装。
         HTTP协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求URI中指定的主机，返回的响应是否真的是返回到实际提出请求的客户端”等问题。也就是说，HTTP协议无法判定请求是来自何方、出自谁手；无法确定正在通信的对方是否具备访问权限，因为某些Web服务器上保存着一些重要信息，只想发给特定用户通信的权限；并且即使是无意义的请求也会照单全收，无法阻止DoS攻击。（有关DoS攻击的有关内容请移步我的另一篇文章：https://blog.csdn.net/weixin_41631970/article/details/88908482）
         虽然使用HTTP协议无法确定通信方，但如果使用SSL则可以。SSL提供了一种被称为证书的手段用以确定通信方。证书由值得信任的第三方颁发，用来证明服务器和客户端是实际存在的。另外客户端持有证书即可完成个人身份的认证，也可用于对Web网站认证的环节。
  

• 无法验证报文的完整性，所以有可能已经被篡改。
         所谓完整性是指信息的准确度，一个HTTP通信在请求或响应送出之后知道对方接收到之前的这段时间内，即使请求或响应的内容遭到篡改，也没办法获悉。换句话说，没有办法确认发送的请求或者响应和接受到的请求或者响应是前后相同的。
         例如，从某个Web网站上下载内容，无法确认客户端下载的文件和服务器的文件是一致的，文件内容有可能在传输过程中被篡改了。像这样在请求或响应传输途中，遭到攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack, MITM）。
         仅依靠HTTP确保完整性是非常困难的，因此需要通过其他协议的组合来实现这个目标。
  

       这些问题不仅在HTTP上出现，在其他未加密的协议上同样存在，HTTPS就是为了解决HTTP的安全性问题而生的。
2.HTTP+加密+认证+完整性保护=HTTPS
       HTTPS协议并非是应用层的一种新协议，只是HTTP通信接口部分用SSL和TSL协议代替而已。通常，HTTP直接和TCP通信，当使用SSL时，则变成HTTP先和SSL通信，再由SSL和TCP通信了。（注：SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在你应用层的协议均可配合SSL使用）
       近代加密方法中加密算法是公开的而密钥是保密的，通过这种方式以保证加密方法的安全性。如果密钥被攻击者获得，那加密就失去了意义。加密技术可以分为共享秘钥加密和公开密钥加密两种。

• 共享密钥加密
         加密和解密用同一个密钥的方式称为共享密钥加密，也被称为对称密钥加密。以共享密钥方式加密时必须将密钥也发给对方，在互联网上转发密钥时，如果通信被监听，那么密钥就会被劫持（发送密钥就有被窃听的风险，但不发送对方就无法解密。再者说，如果密钥能够安全发送，那么不加密的信息也能够安全发送）。
  

• 公开密钥加密
         公开密钥加密很好地解决了共享秘钥加密的困难。公开密钥加密使用一对非对称的密钥——公开密钥和私有秘钥。发送密文的一方使用公开密钥对信息进行加密处理，对方收到被加密的信息后使用自己的私有秘钥解密。使用这种方式，不需要发送解密用的密钥，所以不必担心密钥被盗走。
  

       HTTPS采用共享秘钥加密和公开密钥加密并用的混合加密机制。在密钥交换环节使用公开密钥加密方式，之后建立通信交换报文阶段则使用共享密钥加密，这是因为公开密钥加密处理起来比共享密钥加密复杂，在通信时使用公开密钥加密效率会不高。

       遗憾的是，公开密钥加密的方式仍存在一些问题，那就是无法验证公开密钥本身的真实性。例如，A在与B通信时，A如何证明拿到的公开密钥就是B发行的公开密钥，很有可能在公开密钥传输过程中被攻击者替换掉。
       为了解决上述问题，可以使用由数字证书认证机构（CA）和其相关机构颁发的公开密钥证书。整个流程如下：

• 服务器向CA申请公开密钥
• CA人员在判明申请者身份后，对已申请的公开密钥做数字签名
• 将该公开密钥与公钥证书绑定在一起

       在通信时，服务器会将这份由CA颁发的公钥证书发送给客户端，拿到证书的客户端使用CA的公开密钥，向CA验证公钥证书上的数字签名，一旦验证通过，客户端便可以确定数字证书的有效性和公开密钥的可靠性。这样便解决了无法验证公开秘钥是否真实可靠的问题。
       但与此同时，客户端在验证证书的数字签名时，需要用到CA的密钥，所以就要CA将密钥发给客户端，这同样会有潜在风险。所以多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

       HTTPS也存在一些问题，那就是当使用SSL时，它的处理速度会变慢。和HTTP相比，网络负载可能会变慢2-100倍。这是因为HTTPS除去和TCP连接、发送HTTP请求（响应）以外，还必须进行SSL通信，因此整体上处理通信量不可避免的会增加。另外一点是SSL必须进行加密处理，在服务端和客户端都需要进行加密和解密的运算，因此会消耗更多的CPU和内存资源。

       HTTPS变慢这一问题没有根本性的解决方案，一般会使用SSL加速器这种硬件来改善，仅在SSL处理时发挥SSL加速器的作用，以分担负载。

确认访问用户身份的认证

1.何为认证
       计算机本身无法判断使用者的身份，也就是说无法判断网络的另一头究竟是谁。为了弄清究竟是谁在访问服务器，就得让客户端自报家门。可是就算正在访问服务器的客户端生成自己是XXX，身份是否属实也无从谈起。为了确认XXX是否真的具有访问系统的权限，就需要核对一些只有登陆者本人才知道的信息。例如：密码、动态令牌、数字证书、生物认证等。
       HTTP/1.1使用的认证方式有：BASIC认证（基本认证）、DIGEST认证（摘要认证）、SSL客户端认证、FormBase认证（基于表单认证）。
2.BASIC认证
       为了通过BASIC认证，需要将用户名和密码发送给服务器，发送的内容是由用户名和密码构成，两者中间以冒号连接后，在经Base64编码处理得到的字符串。将处理完的字符串写入首部字段Authorization后发送请求，由服务器进行身份验证。
       BASIC认证虽然采用了Base64编码方式，但这不是加密处理。攻击者不需要任何信息就可以对其解码，换言之，由于解码后就是用户的用户名和密码，所以安全性不好。除此之外，BASIC认证上还有一个大问题，就是想再进行一次BASIC认证时，一般的浏览器没法实现认证注销操作。
3.DIGEST认证
       为了弥补BASIC认证存在的缺点，从HTTP/1.1开始就有了DIGEST认证。DIGEST认证同样是采用质询/响应的方式，但不会像BASIC那样直接发送明文密码。一开始A会先发送认证要求和一个质询码给另一方B，B使用接收到的质询码计算生成响应码，最后将响应码返回给A由A对身份进行验证。
4.SSL客户端认证
       从使用用户名和密码的认证方式来看，只要二者匹配成功，就可以认证是本人的行为。但如果用户名密码被盗，就很有可能被第三者冒充，利用SSL客户端认证就可以避免该情况的发生。
       为了达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，并且客户端必须安装此证书。服务器在接收到对需要认证的资源的请求时会要求客户端提供证书，用户选择发送的客户端证书并发送给服务器。服务器验证客户端证书后领取证书内的客户端公开密钥，然后开始HTTPS通信。
       在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和基于表单认证组合形成一种双因素认证来使用。第一个认证因素的SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。
5.FormBase认证
       基于表单的认证方法不是在HTTP协议中定义的，客户端会向服务器上的Web应用程序发送登录信息，按登录信息的验证结果认证。由于使用上的便利性及安全性问题，现在的认证大多数为基于表单认证。
       基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session。这是因为HTTP是无状态协议，之前已认证的用户状态无法通过协议层面保存下来，即无法实现状态管理。这样的话即使该已认证用户继续访问，也无法区分他和其他用户。于是我们会使用Cookie来管理Session，以弥补HTTP协议中不存在的状态管理功能。

       这里可能有同学对BASIC认证和FormBase认证有些疑惑，这两种方法都是使用用户名密码进行身份验证，有什么区别呢？
       BASIC认证是将用户名密码拼接成的字符串编码后放在报文头里，很容易被窃听。而FormBase认证时，账号密码是作为报文主体通过HTTPS发送的，这样一来安全性能够得到保证。

小结

       本系列的下一篇将带来HTTP追加协议和Web攻击的相关内容。