读书笔记——《图解HTTP》（三）

第六章 HTTP首部

HTTP请求报文

HTTP响应报文

HTTP首部字段类型

• 通用首部字段（General Header Fields）
  请求报文和响应报文两方都会使用的首部。
• 请求首部字段（Request Header Fields）
  从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
• 响应首部字段（Response Header Fields）
  从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
• 实体首部字段（Entity Header Fields）
  针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

HTTP/1.1通用首部字段

• Cache-Control
  
  
  

• public表示其他用户也可利用缓存

• private表示响应只以特定的用户作为对象

no-cache指令：

使用no-cache指令的目的是为了防止从缓存中返回过期的资源。客户端发送的请求中如果包含no-cache指令，则表示客户端将不会接收缓存过的响应。于是，“中间”的缓存服务器必须把客户端请求转发给源服务器。

如果服务器返回的响应中包含no-cache指令，那么缓存服务器不能对资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。

HTTP1.1警告码：

请求首部字段：

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

• 文本文件
  text/htm1，text/plain，text/css...
  application/xhtml+xml,application/xml...

• 图片文件
  image/jpeg,image/gif,image/png...

• 视频文件
  video/mpeg，video/quicktime....

• 应用程序使用的二进制文件
  application/octet-stream,application/zip...

• gzip
  由文件压缩程序gzip（GNUzip）生成的编码格式（RFC1952），采用Lempel-Ziv算法（LZ77）及32位循环冗余校验（Cyclic Redundancy Check，通称CRC）。

• compress
  由UNIX文件压缩程序compress生成的编码格式，采用Lempel-Ziv-Welch算法（LZW）。

• deflate
  组合使用zlib格式（RFC1950）及由deflate压缩算法（RFC1951）生成的编码格式。

• identity
  不执行压缩或不会变化的默认编码格式

  采用权重q值来表示相对优先级、这点与首部字段Accept相同。另外，也可使用星号（*）作为通配符，指定任意的编码格式。

响应首部字段：

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。     

实体首部字段：

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

为Cookies服务的首部字段：

管理服务器与客户端之间状态的Cookie，虽然没有被编入标准化HTTP/1.1的RFC2616中，但在Web网站方面得到了广泛的应用。   
Cookie的工作机制是用户识别及状态管理。Web网站为了管理用户的状态会通过Web浏览器，把一些数据临时写入用户的计算机内。接着当用户访问该      
Web网站时，可通过通信方式取回之前发放的Cookie。调用Cookie时，由于可校验Cookie的有效期，以及发送方的域、路径、协议等信息，所以正规发布的Cookie内的数据不会因来自其他Web站点和攻击者的攻击而泄露。   
至2013年5月，Cookie的规格标准文档有以下4种。     

• 由网景公司颁布的规格标准
  网景通信公司设计并开发了Cookie，并制定相关的规格标准。1994年前后，Cookie正式应用在网景浏览器中。目前最为普及的Cookie方式也是以此为基准的。
• RFC2109
  某企业尝试以独立技术对Cookie规格进行标准化统筹。原本的意图是想和网景公司制定的标准交互应用，可惜发生了微妙的差异。现在该标准已淡出了人们的视线。
• RFC2965
  为终结Internet Explorer 浏览器与Netscape Navigator的标准差异而导致的浏览器战争，RFC2965内定义了新的HTTP首部Set-Cookie2和Cookie2。可事实上，它们几乎没怎么投入使用。
• RFC6265
  将网景公司制定的标准作为业界事实标准（De facto standard），重新定义Cookie标准后的产物。

其他首部字段：

X-Frame-Options:
DENY：属于HTTP响应首部，用于控制网站内容在其他Web网站的Frame标签内的显示问题。主要为了防止点击劫持攻击。

• DENY：拒绝
• SAMEORIGIN：仅同源域名下的页面匹配时许可。

X-XSS-Protection：
属于响应首部，用于控制浏览器XSS防护机制的开关。

• 0：将XSS过滤设置成无效状态
• 1：将XSS过滤设置成有效状态

DNT：
请求首部，Do Not Track，拒绝个人信息被收集，是表示拒绝被精确广告追踪的一种方法。
0：同意
1：拒绝

P3P（在线隐私偏好平台）：
响应首部，可以让Web网站上的个人隐私编程一种仅供程序可理解的形式，以达到保护用户隐私的作用。

• 创建P3P隐私
• 保存在/w3c/p3p.xml
• 从P3P隐私中新建Compact policies后，输出到HTTP响应中。

第七章 确保Web安全的HTTPS

HTTP的缺点：

HTTP主要有这些不足，例举如下。

• 通信使用明文（不加密），内容可能会被窃听

• 不验证通信方的身份，因此有可能遭遇伪装

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

• TCP/IP是可能被窃听的网络
  如果要问为什么通信时不加密是一个缺点，这是因为，按TCP/IP协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。
  所谓互联网，是由能连通到全世界的网络组成的。无论世界哪个角落的服务器在和客户端通信时，在此通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到恶意窥视行为。

• 通信的加密
  一种方式就是将通信加密。HTTP协议中没有加密机制，但可以通过和SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密HTTP的通信内容。
  用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure，超文本传输安全协议）或HTTP over SSL。

• 内容的加密
  还有一种将参与通信的内容本身加密的方式。由于HTTP协议中没有加密机制，那么就对HTTP协议传输的内容本身加密。即把HTTP报文里所含的内容进行加密处理。在这种情况下，客户端需要对HTTP报文进行加密处理后再发送请求。
  由于该方式不同于SSL或TES将整个通信线路加密处理，所以内容仍有被篡改的风险。稍后我们会加以说明。

• 任何人都可以发起请求
  HTTP协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患。

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

SSL中的数字证书：

证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外、伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。通过使用证书，以证明通信方就是意料中的服务器。这对使用者个人来讲，也减少了个人信息泄露的危险性。另外，客户端持有证书即可完成个人身份的确认，也可用于对Web网站的认证环节。    
由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。   
换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。      

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

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

  SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。可以说SSL是当今世界上应用最为广泛的网络安全技术。

• 使用两把密钥的公开密钥加密
  公开密钥加密方式很好地解决了共享密钥加密的困难。
  公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
  另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

• HTTPS采用混合加密机制
  HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。
  在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

• HTTPS中的数字证书：
  为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。
  数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

  • 首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
  • 服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。
  • 接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。
    此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
    数字证书认证机构的私有密钥
  • 服务器把自己的公开密钥登录至数字证书认证机构
  • 数字证书认证机构用自己的私有密钥向服务器的公开密码署数字签名并颁发公钥证书
  • 数字证书认证机构的公开密钥已事先植入到浏览器里了。客户端拿到服务器的公钥证书后，使用数字证书认证机构的公开密钥，向数字证书认证机构验证公钥证书上的数字签名，以确认服务器的公开密钥的真实性。
  • 使用服务器的公开密钥对报文加密后发送
  • 服务器用私有密钥对报文解密

• 可证明组织真实性的EV SSL证书
  证书的一个作用是用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是EVSSL证书（Extended Validation SSL Certificate）。
  EVSSL证书是基于国际标准的认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针，因此，通过认证的Web网站能够获得更高的认可度。
  持有EVSSL证书的Web网站的浏览器地址栏处的背景色是绿色的，从视觉上就能一眼辨别出。而且在地址栏的左侧显示了SSL证书中记录的组织名称以及颁发证书的认证机构的名称。

HTTPS安全通信机制：

1. 步骤1：客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
2. 步骤2：服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
3. 步骤3：之后服务器发送Certificate报文。报文中包含公开密钥证书。
4. 步骤4：最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
5. 步骤5：SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
6. 步骤6：接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
7. 步骤7：客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
8. 步骤8：服务器同样发送Change Cipher Spec报文。
9. 步骤9：服务器同样发送Finished报文。
10. 步骤10：服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
11. 步骤11：应用层协议通信，即发送HTTP响应。
12. 步骤12：最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCPFIN报文来关闭与TCP的通信。

SSL和TLS：

HTTPS使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）这两个协议。  
SSL技术最初是由浏览器开发商网景通信公司率先倡导的，开发过SSL3.0之前的版本。目前主导权已转移到IETF（Internet Engineering Task Force，Internet工程任务组）的手中。IETF以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。  
TSL是以SSL为原型开发的协议，有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TLS1.0。由于SSL1.0协议在设计之初被发现出了问题，就没有实际投入使用。SSL2.0也被发现存在问题，所以很多浏览器直接废除了该协议版本。  

SSL速度慢吗

HTTPS也存在一些问题，那就是当使用SSL时，它的处理速度会变慢。  
由于HTTPS还需要做服务器、客户端双方加密及解密处理，因此会消耗CPU和内存等硬件资源。和HTTP通信相比，SSL通信部分消耗网络资源。而SSL通信部分，又因为要对通信进行处理，所以时间上又延长了。HTTPS比HTTP要慢2到100倍。   
SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU及内存等资源，导致处理速度变慢。和使用HTTP相比，网络负载可能会变慢2到100倍。除去和TCP连接、发送HTTP请求+响应以外，还必须进行SSL通信，因此整体上处理通信量不可避免会增加。  
另一点是SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起HTTP会更多地消耗服务器和客户端的硬件资源，导致负载增强。  
针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通信专用硬件，相对软件来讲，能够提高数倍SSL的计算速度。仅在SSL处理时发挥SSL加速器的功效，以分担负载。   

解决方法：

• 不全都用HTTPS
  如果是非敏感信息则使用HTP通信，只有在包含个人信息等敏感数据时，才利用HTTPS加密通信。
• 通信内容部分加密
  在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。