图解http(二)

本篇主要介绍图解http的第二大部分，包括web服务器相关的内容、http报文的一些字段，针对http不满足需求而追加的协议、功能，web安全等方面。and 虽然是笔记，但是里面不定期穿插着楼主的思考跟总结，特别是ssl的部分思密达

chapter5 与http有关的web服务器

为什么请求头中要指定uri
因现实生活中，有可能一个服务器上部署着多个服务，（虚拟服务器存在）域名不同，那么光有IP是没有用的都会定位到这个服务器，因此需要有指定的uri来唯一识别
客户端代理服务器源服务器
每次经过代理服务器，都需要写入 via 首部信息到头请求头或者响应头。

chapter6 http首部

chapter6 是http首部字段的一些说明，包括通用首部、请求首部、响应首部、实体首部以及一些没有放到http1.1的rfc里面但很常用的首部字段，包括cookie的一些字段及属性，如set-cookie的secure，httpOnly属性,cookie字段。还有其他的如DNT（do not trace，拒绝个人信息被搜集），p3p（保护用户隐私）的等等。具体可以查看书上的介绍，这部分不再赘述。

chapter7 确保web安全的https

part1: 起因

本章是基于http的以下三个缺点展开的：

通信内容可能被窃听（明文不加密）
被篡改（报文完整性X）
通信双方身份无法确认。

为什么不加密？因为加密了其实也可能被窃听，只是可能不会被破解而已。

如何防止被窃听——加密
- 通信加密：http+ ssl/tls 此处SSL出没
  相当于整个通信信道是安全的。
  
  ssl:
  secure socket layer 安全套接字
  tls:
  transport layer security 传输层安全协议
- 内容加密
  此处仅对报文主体，不包括报文首部（请求头（请求行+请求首部））。
  缺点：内容有被篡改的可能。

如何确认通信方的身份——证书
不确认通信方的身份，可能会带来若干隐患：
- 服务器/客户端的伪造、
- 通信方的权限无法确认、
- 海量请求接受导致的Dos攻击
  SSL使用了一种被称为证书的手段。证书是有可信第三方颁发，用于确认服务器和客户端是实际存在的，并且证书的伪造极其困难。
  客户端在开始通信前先确认服务器的证书，保证是自己要访问的服务器。
如何保证通信内容不被篡改——摘要
现实生活中，请求或者响应在传输过程中是可能被攻击者拦截后进行篡改的，这种就是中间人攻击。通常避免的方法有MD5和SHA-1等hash值校验的方法、数字签名（文件的数字签名可以用PGP来生成）。
但这些方法都需要客户端的用户去亲自检查验证是否自己下载的文件就是服务器上的文件。
而且一旦MD5，PGP这些被篡改的话，用户其实也无法发现。

综上，HTTPS可以解决以上三种问题，SSL提供了认证+加密处理+摘要的功能。它可以总结为
HTTPS = HTTP+ 加密+ 认证 +完整性保护

part2 HTTPS

1. 使用ssl时，就从通常的http与tcp通信变成http->ssl->tcp->ip..

【注】ssl是独立于http的协议的，其他运行在应用层的SMTP,Telnet等协议都可以与ssl配合使用。

2. https采取了共享秘钥加密+公开秘钥加密的混合加密方式

补充知识：

加密分两种，对称/非对称，ssl采取的是非对称即公开秘钥加密

对称密钥（共享密钥），即加密解密都用同一个秘钥，缺点在于秘钥必须发送给对方，而传送时有可能就被窃听甚至获取到。

公开秘钥使用非对称密钥，公钥加密，私钥解密，公钥可以被任意共享。具体来说是，A发送给B，就用B的公钥加密，B收到后用自己的私钥解密
优点在于安全性得到了极大的保障：

同时获取公钥私钥很困难

即使获得了破解也困难（大素数分解）

实际中，由于公开秘钥加密很慢，因此https采取了两种方式混合使用的方式，用公开密钥加密的方法去交换接下来在共享秘钥加密方式中的密钥，然后在确保密钥安全的前提下用共享秘钥的方式通信。

问题又来了…当你用公开秘钥加密的方法传输时，你怎么知道这个被你传的就是真正的公开秘钥。
但是光有不行，因为不能证明公钥本身就是真正的公钥，有可能这个公钥已经被攻击者替换。
因此，就需要证书来验证。

3. 证书

目的：用于确认服务器背后企业是否真实存在
流程：

服务器运营人员向数字证书认证机构申请，机构用自己的私钥对申请的公开秘钥做数字签名，然后把这个公开密钥A放入公钥证书。然后服务器把证书给客户端。客户端要验证这个公钥证书是否是正确的，就直接把证书（公钥A+机构私钥组成的数字签名）连同浏览器内置好的认证机构的公钥B，去验证数字签名，以确定公钥A的真实性。

一旦验证这个公开密钥A是真实的，就可以继续用原来的方式（公开密钥加密方式去交换对称密钥，然后共享秘钥方式加解密）….好绕口=。=

其实就相当于在原来的基础上多了一步验证公开密钥的真实性。而这个秘钥的真实性的验证是借助可信证书机构的公私密钥来解决的。

4. 完整版本的https 通信机制

正确的流程是：
服务器：
服务器~~每次传送，都需~~要发：
//服务器sendData = 信息+ signature +数字证书。
//signature = md5(信息)+ 服务器私钥加密
//数字证书 = 服务器公钥 + 机构私钥加密后结果

客户端
客户端拿到以后，用浏览器的机构公钥解密，得到服务器公钥，然后去解谜收到的东西，得到的就是 md5以后的信息 A。然后将信件本身md5后生成B 。AB进行判断是否相等。就可以看信件是否篡改了。

在这个过程中，先用机构公钥解密验证身份，再用服务器公钥揭秘再比对实现篡改验证。

更好的的应该是客户端把握掌控权：客户端发一段随机串给服务器，让他用私钥加密后传过来，客户端用公钥解密，发现与之前的一致，说明公私钥正确，服务器身份可信。

=== 更新 2017/03/25
这边还是有没说清楚的地方，
客户端得到公钥后可以来验证服务器身份，（验证通信方身份）但是发送数据不能直接这么发送，因为每个人都可以持有公钥，那么信息就会被窃取。
因此，客户端应该在下一个会话中告诉服务器：

我把我们以后会话所需要用的加密算法和密钥用你的公钥加密了，喏，拿去哈。

因为这个信息只有私钥才能解析，而只有服务器有私钥，因此保证了信息即使被窃取也没有用。因此保证了信道安全（通信内容加密）。
再下一次会话，（就回到我们上面说的过程了），就是服务器用刚刚的加密算法和密钥（比较朴素的是hmac(data,secret)，one-way不可逆）。连同data原文发过去。然后客户端收到以后，因为它自己也知道算法和密钥，因此对原文做一次处理，然后比对，实现 数据防篡改验证。
至此，ssl的三大认证点就都说通了。