本系列是对于《图解HTTP》的知识点整理。

《图解HTTP》出版于2014年，此时的HTTP2协议还未修订完成，故全书只讲解HTTP1.0、HTTP1.1以及会涉及到一点HTTP2.0依赖的协议。

本文涉及第六章到第九章的内容。

一、确保Web安全的HTTPS

1、HTTP的缺点

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

1.1 加密处理

通信的加密

　　HTTP协议中没有加密机制，但可以通过和SSL或TLS的组合使用，加密HTTP的通信内容。

 

内容的加密

　　由于HTTP协议中没有加密机制，那么就对HTTP协议传输 的内容本身加密。即把HTTP报文里包含的内容进行加密处理。

 

 　　为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。该方式不同于SSL或TLS将整个通信线路加密处理，所以内容仍有被篡改的风险。

1.2 不验证通信双方

　　HTTP协议中的请求和响应不会对通信方进行确认。

　　任何人都可以发起请求。不论是谁发送过来的请求都会返回响应。

 

 　　因此，会存在一下隐患。

• • 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web服务器。
  • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
  • 无法确定正在通信的对方是否是具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
  • 无法判定请求是来自何方、出自谁手。
  • 即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击（Denial of Service，拒绝服务攻击）

证书

　　SSL不仅提供加密处理，还使用了一种被称为证书的手段，可用于确认通信方。

　　证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。

 

 

1.3 报文完整性

 

 　　像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。

 

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

 

 2.1 HTTPS

　　HTTPS是HTTP通信接口部分用SSL和TLS协议代替而已。

　　通常HTTP和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。

 

 　　在采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整形保护这些功能。

　　SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。

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

共享密钥的困境

 

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

　　公开密钥加密也成为非对称加密，使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥可以随意发布，任何人都可以获得。

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

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

 

 HTTPS采用混合加密机制

　　HTTPS采用共享密钥和公开密钥两者并用的混合机密机制。

　　在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

 

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

　　公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。

　　为解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

 

 可证明组织真实性的EV SSL证书

　　EV SSL证书不仅用来证明作为通信一方的服务器是否规范，还可以确认对方服务器背后运营的企业是否真实存在。

用来确认客户端的客户端证书

　　客户端证书只能用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。

自签名证书

　　由自认证机构颁发的证书称为自签名证书。常使用Open SSL开源程序独立构建认证机构。

2.4 HTTPS的安全通信机制

　　下面是HTTPS的通信步骤。

 

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

 

 SSL和TLS

　　SSL技术最初是由浏览器开发商网景通信公司率先倡导的。TLS的以SSL为原型开发的协议。

SSL速度慢吗

 

 　　SSL的慢分两种。一种是至通信慢，另一种是指由于大量消耗CPU及内存等资源，导致处理速度变慢。

二、确认访问用户身份的认证

　　计算机为了判断坐在显示器前的使用者的身份，可以核对登陆者本人才知道的信息，核对的信息通常指以下这些。

• • 密码：只有本人才会知道的字符串信息
  • 动态令牌：仅限本人持有的设备内显示的一次性密码
  • 数字证书：仅限本人（终端）持有的信息
  • 生物认证：指纹和虹膜等本人的生理信息
  • IC卡等：仅限本人持有的信息

　　HTTP使用的认证方式如下所示。

• • BASIC认证（基本认证）
  • DIGEST认证（摘要认证）
  • SSL客户端认证
  • FormBase认证（基于表单认证）

2、BASIC认证

　　BASIC认证的认证步骤如下。

 

 　　BASIC认证谁让采用Base64编码方式，但这不是加密处理。除此之外，如果想再进行一次BASIC认证，一般的浏览器无法实现认证注销操作。BASIC认证使用上不够便捷灵活。

3、DIGEST认证

　　DIGEST认证同样采用质询/响应的方式，但是不会像BASIC认证那样直接发送明文密码。

 

 　　因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起BASIC认证，密码泄露的可能性就降低了。

 

 　　DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。

4、SSL客户端认证

　　SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。

　　为了达到SSL客户端认证的目的，需要实现将客户端证书发给客户端，且客户端必须安装此证书。

 

 4.1 双因素认证

　　在多数情况下，SSL客户端认证不仅会依靠证书完成认证，一般会和基于表单认证组合形成一种双因素认证（Two-factor authentication）来使用。

　　第一个认证因素是SSL客户端证书用来认证客户端计算机，另一个认证因素用来确定这是用户本人的行为。

5、基于表单认证

　　下面就是一个基于表单认证的示例。

 

　　基于表单认证的标准规范尚未由定论。

 　　基于表单认证本身是通过服务器端的Web应用，将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。

　　但鉴于HTTP是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来，及无法实现状态管理，故一般会使用Cookie来管理Session（会话）。

 

 　　另外，服务器端应如何保存用户提交的密码等登录信息等也没有标准化。

　　通常，一种安全的保存方法是，先利用给密码加盐（salt）的方式增加额外信息，再使用散列（hash）函数计算出散列值后保存。

三、基于HTTP的功能追加协议

1、消除HTTP瓶颈的SPDY

• SPDY - The Chromium Projects

　　http://www.chromium.org/spdy/

1.1 HTTP的瓶颈

• 一条连接数只可发送一个请求
• 请求只能从客户端开始。客户端不可以接收除响应以外的指令。
• 请求/响应首部未经压缩就发送。首部信息越多延迟越大。
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
• 可任意选择数据压缩格式。非强制压缩发送。

1.2 Ajax

　　Ajax想达到局部Web页面替换加载的异步通信手段。但利用Ajax实时地从服务器获取内容，有可能会导致大量请求产生。另外，Ajax仍未解决HTTP协议本身存在的问题。

 

 1.3 Comet

　　Comet通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。

 

 1.4 SPDY协议

　　SPDY协议是为了在协议级别消除HTTP所遭遇的瓶颈。

2、SPDY的设计与功能

　　SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层与传输层之间通过新加会话层的形式运行。SPDY规定通信中使用SSL。

 

 　　使用SPDY后，HTTP额外获得以下功能。

• • 多路复用流，通过单一的TCP连接，可以无限制处理多个HTTP请求。
  • 赋予请求优先级
  • 压缩HTTP首部
  • 推送功能，支持服务器主动向客户端推送数据的功能。
  • 服务器提示功能，服务器可以主动提示客户端请求所需的资源

　　SPDY基本上只是将单个域名（IP地址）的通信多路复用，所以当一个Web网站上使用多个域名下的资源，SPDY的改善效果就会受到限制。

3、全双工通信的WebSocket

　　WebSocket是一个独立的协议标准。它的主要特点如下。

• • 推送功能
  • 减少通信量，只要建立起WebSocket连接，就希望一致保持连接状态，而且WebSocket的首部信息很小。

　　为了实现WebSocket通信，在HTTP连接建立之后，需要完成一次“握手”（Handshaking）的步骤。

3.1 握手.请求

　　使用HTTP的Upgrade首部字段。

 

 　　Sec-WebSocket-Key字段内记录着握手过程中必不可少的键值。Sec-WebSocket-Protocol字段内记录使用的子协议。

　　子协议按WebSocket协议标准在连接分开使用时，定义那些连接的名称。

3.2 握手.响应

　　对于之前的请求，返回状态码101 Switching Protocols的响应。

 

 　　Sec-WebSocket-Accept的字段值是由握手请求中的Sec-WebSocket-Key的字段值生成的。

　　成功握手确立WebSocket连接之后，通信时不再使用HTTP的数据帧，而采用WebSocket独立的数据帧。

 

 4、HTTP/2.0的实现讨论

　　我们以下述协议为基础讨论HTTP/2.0的实现。

• • SPDY
  • HTTP Speed + Mobility
  • Network-Friendly HTTP Upgrade

4.1 HTTP/2.0的7项技术及讨论

 

 5、Web服务器管理文件的web DAV

　　web DAV（Web-based Distributed Authoring and Versioning，基于万维网的分布式创作和版本控制）是一个可对Web服务器上的内容直接进行文件赋值、编辑等操作的分布式文件系统。它作为扩展HTTP/1.1的协议定义在RFC4918。

 

 5.1 Web DAV的扩展

 

•  集合（Collection）：是一种统一管理多个资源的概念。以集合为单位可进行各种操作。也可实现类似集合的集合这样的叠加。
• 资源（Resource）：把文件或集合称为资源。
• 属性（Property）：定义资源的属性。定义以“名称=值”的格式执行。
• 锁（Lock）：把文件设置成无法编辑状态。多人同时编辑时，可防止在同一时间进行内容写入。

5.2 web DAV内新增的方法及状态码

　　web DAV为了实现远程文件管理，向HTTP/1.1中追加了以下这些方法。

　　PEOPFIND：获取属性

　　PROPPATCH：修改属性

　　MKCOL：创建集合

　　COPY：复制资源及属性

　　MOVE：移动资源

　　LOCK：资源加锁

　　UNLOCK：资源解锁

　　为了配合这些扩展的方法，状态码也随之扩展了。

　　102 Processing：可正常处理请求，但目前是处理中状态

　　207 Multi-Status：存在多种状态

　　422 Unprocessible Entity：格式正确，内容有误

　　423 Locked：资源以被加锁

　　424 Failed Dependency：处理与某请求关联的请求失败，因此不再维持依赖关系

　　507 Insufficient Storage：保存空间不足

Web DAV的请求实例

　　下面是使用PROPFIND方法对http://www.example.com/file发起获取属性的请求。

 

 Web DAV的响应实例

　　下面是上述请求的响应。

 

 

　　HTTP通常使用80/tcp，HTTPS通常使用443/tcp。

标签：加密,认证,SSL,HTTP,图解,公开密钥,客户端
来源： https://www.cnblogs.com/unrealCat/p/16537142.html