【HTTP】学习总结三

1. HTTPS

1.1 HTTP的缺点

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改
  用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS。

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

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

公开密钥加密使用一对非对称的密钥。一把私有密钥，一把公开密钥。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理。对方收到被加密的信息后，在使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

1.2.2 HTTPS采用混合加密机制

1. 使用公开密钥加密方式安全的交换在稍后的共享密钥加密中要使用的密钥
2. 确保交换的密钥是安全的前提下，使用共享密钥加密方式进行通信

1.2.3 HTTPS的安全通信机制

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连接就算建立完成。当然，通信会收到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求；
11. 应用层协议通信，即发送HTTP响应；
12. 最后由客户端断开连接。断开连接时，发送close_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信

HTTPS通信图解：

1.2.4 HTTPS存在的问题

1. 当使用SSL时，处理速度会变慢；
2. SSL必须进行加密处理，在服务器和客户端都需要进行加密和解密的运算处理。

2. HTTP的认证

2.1 BASIC认证

基本认证步骤：
1. 客户端访问一个受http基本认证保护的资源。
2. 服务器返回401状态，要求客户端提供用户名和密码进行认证。（验证失败的时候，响应头会加上WWW-Authenticate: Basic realm=”请求域”。）
401 Unauthorized
WWW-Authenticate： Basic realm=”WallyWorld”
3. 客户端将输入的用户名密码用Base64进行编码后，采用非加密的明文方式传送给服务器。
Authorization: Basic xxxxxxxxxx.
4. 服务器将Authorization头中的用户名密码解码并取出，进行验证，如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。

2.2 DIGEST认证

1. 客户端希望取到服务器上的某个资源，向服务器发送Get请求。
2. 服务器收到客户端的请求后，发现这个资源需要认证信息，判断请求报文中是否带有Authorization头，如果没有，返回一个401(Unauthorized)给客户端。在这个401的回复中，同时服务器会加入一个WWW-Authenticate的头。WWW-Authenticate内必须包含realm和nonce这两个字段的信息。客户端就是依靠想服务器会送这两个值进行认证的；
3. 客户端收到服务器的401(Unauthorized)回复后，使用服务器回复报文中的nonce值，加上username，password, http method, http uri利用MD5（或者服务器指定的其他算法）计算出request-digest，作为repsonse头域的值。并重新发送请求，请求报文中包含Authorization 头；
4. 服务器收到客户端发来的请求后，根据username，查找出用户的password，用和客户端同样的方法计算出request-digest（response）。然后和收到的request-digest进行对比，如果一致，则验证成功，接受客户端的请求，成功返回结果。并带有Authentication-Info消息头。客户端根据该消息头中的参数进行服务器鉴权。

认证过程有两次请求-响应交互：
1. 摘要质询，服务器返回WWW-Authenticate消息头，请求终端做消息摘要。
2. 交互中，客户端在HTTP请求里带有Authorization消息头，包含摘要信息和其他参数，服务器收到后做客户端鉴权，在鉴权成功后送回响应，并带有Authentication-Info消息头。客户端根据该消息头中的参数进行服务器鉴权。

2.3 SSL客户端认证

借由HTTPS的客户端证书完成认证的方式。
凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。

SSL客户端认证的步骤：
需事先将客户端证书分发给客户端，且客户端必须安装此证书。

1. 服务器接收到需要认证资源的请求时，服务器会发送Certificate Request报文，要求客户端提供客户端证书。
2. 客户端将客户端证书信息以Client Certificate报文方式发送给服务器。
3. 服务器验证客户端证书验证通过后才能领取证书内客户端的公开密钥，然后开始HTTPS加密通信。

2.4 Session管理和Cookie应用

由于HTTP是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来。即无法实现状态管理，我们使用Cookie来管理Session（会话），以弥补HTTP协议中不存在的状态管理功能

步骤：
1. 客户端把用户ID和密码等登录信息放入报文的实体部分，通常以POST请求的方式发送给服务器。
2. 服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，将用户的认证状态和Session ID绑定后记录在服务器端。
3. 客户端接收到Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器自动发送Cookie，Session ID会随之发送到服务器。服务端通过验证接收到的Session ID识别用户和其认证状态。

参考链接

https://www.jianshu.com/p/f1f3538b3798
https://www.cnblogs.com/xzwblog/p/6834663.html
https://blog.youkuaiyun.com/u013238950/article/details/51392992
https://www.cnblogs.com/JohnTsai/p/4919369.html