【HTTP权威指南】笔记之三，识别、认证与安全

一. 客户端识别与cookie机制

服务器可以通过以下几种方式来识别客户端：

1. HTTP header 属性
   from - 记录用户email （通常只有爬虫会填写，以便于管理）
   user-agent - 浏览器信息
   referer - 来源网页（从什么网页链接到该网站）
2. IP跟踪识别
   在公共代理时会遇到麻烦
3. 用户登录
   通过header的authorization属性来说明用户身份
4. 胖URL
   对会话生成一个独特的ID， 并重写所有的url以便于标志这些页面都是同一个用户访问的。
   存在缺点（共享连接时信息泄露，破坏公共缓存，服务器负载，非持久）
   
5.  cookie
   服务器会通过数据库存储cookie以为用户更个性化的服务
   客户端的cookie通常存在于一个txt文件中
   在处理缓存时，一般删除set-cookie首部，或者设置为must-revalidate以缓存cookie图片

二. 基本认证机制

认证流程：

1. 用户请求某资源
2. 服务器发送401 authorization required首部要求认证
3. 用户输入账号密码，发送authorization首部
4. 服务器验证并会送200 OK

三. 摘要认证

客户端使用约定好的随机数和密码进行计算得出一个摘要，以代替密码在网络中传输，在服务器端获得认证。

常见的摘要函数有MD5， MD5-sess(ion) 

预授权：在每条事务之后，为了避免客户端都向服务器询问随机数的开销，服务器将随机数连同上一次的200 OK一起发送给客户端

对称认证：客户端也可以向服务器认证，以确定这是真正的服务器

实际问题：

1. 多重质询 - 由于不是所有客户端都支持很强的质询机制，服务器通常会发送很多种认证机制。最理想的做法是客户端选择最强的一种机制作为应答，但是通常客户端会选择第一种
2. 差错处理 - 识别一些攻击现象
3. 保护空间 - 认证域问题
4. 重写URI - 一些代理或者浏览器会重写URI（比如转义或加上'/'），这样会破坏摘要
5. 缓存 - 除非cache-control的值为must-revalidate或者public，否则一定不能讲这条响应用作其他任何请求

词典攻击：攻击者准备好一定数量的密码和随机数以及他们笛卡尔积生成的“摘要”，向客户端发送一定随机数，通过他的应答来确定本身密码

四. 安全HTTP

HTTPS相比HTTP在HTTP和TCP之间还有一个安全层（SSL或TLS）

SSL同HTTP的自然语义不同，是一个二进制传输协议，确认身份后生成临时的会话密钥来加密会话

通过证书来颁发密钥和签名

通过代理传输安全流量时，如果header已经被加密，则代理根本不知道这个信息将发往何方。

客户端会明文发送connect以告知代理