WilsonLiu's blog 首发地址
识别,认证与安全
第三部分的4章提供了一系列的技术和机器，可用来跟踪身份，进行安全性检测，控制对内容的访问。
客户端识别与cookie机制 第十一章
HTTP最初是一个匿名，无状态的请求/响应协议。服务器处理来自客户端的请求，然后向客户端回送一条响应。web服务器几乎没有什么信息可以用来判定是哪个用户发送的请求，也无法记录来访用户的请求序列。
用户识别机制
承载用户身份信息的HTTP首部
客户端IP地址跟踪，通过用户的IP地址对其进行识别
用户登录，用认证方式来识别用户
胖URL，一种在URL中嵌入识别信息的技术
cookie，一种功能强大且高效的持久身份识别技术
HTTP首部
下表给出了7种常见的用来承载用户相关信息的HTTP请求首部。后面3个首部是扩展类型的请求首部。
| 首部名称 | 描述 |
|---|---|
| From | 用户的E-mail地址 |
| User-Agent | 用户的浏览器软件 |
| Referer | 用户是从这个页面上依照链接跳转过来的 |
| Authorization | 用户名和密码 |
| Client-IP | 客户端的IP地址 |
| X-Forwarded-For | 客户端的IP地址 |
| Cookie | 服务器产生的ID标签 |
用户登录
为了使web站点的登录更加简便，HTTP中包含了一种内建机制，可以用WWW-Authenticate首部和Authorization首部向web站点传送用户的相关信息。一旦登录，浏览器就可以不断地在每条发往这个站点的请求中发送这个登录信息了。
缺点：保密性不强，不能跨站点，不同的站点需要重新输入账户密码。
胖URL
可以通过胖URL将服务器上若干个独立的HTTP事务捆绑成一个"会话"或"访问"。用户首次访问这个web站点时，会生成一个唯一的ID，用服务器可以识别的方式将这个ID添加到URL中，然后服务器就会将客户端重新导向这个胖URL。
问题：
丑陋的URL
无法共享URL
破坏缓存
额外的服务器负荷
逃逸口
在会话间是非持久的
cookie
cookie是当前识别用户，实现持久会话的最好方式。最初由网景公司开发，但现在所有的主要浏览器都支持他。
cookie的类型
可以笼统的分为:会话cookie和持久cookie。会话cookie和持久cookie的唯一区别就是他们的过期时间。 如果设置了Discard参数，或者没有设置Expires或Max-Age参数来说明扩展的过期时间，这个cookie就是一个会话cookie。
不同的站点使用不同的cookie
cookie的域属性
产生cookie的服务器可以向Set-Cookie响应首部添加一个Domain属性来控制哪些站点开业看到那个cookie。
Set-cookie: user="wilson";domain="wilsonliu.cn"则用户访问的任何以wilsonliu.cn结尾的站点都会讲此cookie发布出去。
cookie的路径属性
cookie规范甚至允许用户将cookie与部分web站点关联起来。可以通过Path属性来实现这一功能。
Set-cookie: year="21";domain="wilsonliu.cn";path=/year/则只会在/year/下的站点时才会发布此cookie。
cookie成分
cookie版本0 (Netscape)
Set-Cookie首部
Name=Value
Expires
domain
Path
Secure
cookie首部
客户端发送请求时，会将所有与域，路径，安全过滤器匹配的未过期的cookie都发送给这个站点。
cookie版本1 (RFC 2965)
Set-Cookie2
Name = Value
Version
Comment
CommentURL
Discard
domain
Max-Age
Path
Port
Secure
cookie首部
版本1的cookie会带回与传输的每个cookie相关的附加信息，用来描述每个cookie途径的过滤器。每个匹配的cookie都必须包含来自相应的Set-Cookie2首部的所有Domain,Port和Path属性。
基本认证机制 第十二章
基本认证质询首部
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm=quoted-realm响应首部(通过base64编码传输)
Authorization:Basic base64-username-and-password摘要认证 第十三章
基本认证便捷灵活，但极不安全。用户名与密码明文传输，也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与SSL配合使用。
摘要认证与基本认证兼容。但却更为安全。
摘要认证的改进
永远不会以明文的方式在网络上发送密码
可以防止恶意用户捕获并重放认证的握手过程
可以有选择地防止对报文内容的篡改
防范其他几种常见的攻击方式
用摘要保护密码
摘要认证遵循的箴言是"绝不通过网络发送密码"。客户端不会发送密码，而是会发送一个“指纹”或密码的"摘要"，这是密码的不可逆扰码。
单向摘要
摘要是"对信息主体的浓缩"。摘要是一种单向函数，主要用于将无限的输入值转换为有限的浓缩输出值。常见的摘要函数MD5，会将任意长度的字节序列转换为一个128位的摘要。
有时也将摘要函数称为加密的校验和，单向散列函数或指纹函数。
用随机数防止重放攻击
使用单向摘要就无需以明文形式发送密码，没有哪个而已用户能够轻易地从摘要中解码出原始密码。
但是仅仅隐藏密码并不能避免危险，因为即便不知道密码，也可以截获摘要，并重放给服务器。摘要和密码一样好用。
为防止此类重放攻击的发生服务器可以向客户端发送一个称为随机数(nonce)的特殊令牌，这个数会经常发生变化(可能是每毫秒，或者是每次认证都变化)。客户端在计算摘要之前要先将这个随机数令牌附加到密码上去。
摘要的计算
摘要认证的核心就是对公共信息，保密信息和有时限的随机值这个组合的单项摘要。
数据
与安全性相关的数据(A1) ——包含有用户名，密码，保护域和随机数等内容
与报文有关的数据(A2) ——比如URL，请求方法和报文实体，A2有助于防止方法，资源或报文被篡改
预授权
在普通的认证方式中，事务结束之前，每条请求都要有一次请求/质询的循环。
如果客户端事先知道下一个随机数是什么，就可以取消这个请求/质询循环。
服务器预先在Authentication-Info成功首部中发送下一个随机数
服务器允许在一小段时间内使用同一个随机数
客户端和服务器使用同步的，可预测的随机数生成算法
应该考虑的实际问题
多重质询
差错处理
保护空间
重写URI
缓存
安全性考虑
首部篡改
重放攻击
多重认证机制
词典攻击
恶意代理攻击和中间人攻击
选择明文攻击
存储密码
安全HTTP 第十四章
保护HTTP的安全
服务器认证
客户端认证
完整性
加密
效率
普适性
管理的可扩展性
适应性
在社会的可行性
HTTPS
HTTPS是最流行的HTTP安全形式，它是由网景公司首创，所有主要的浏览器和服务器都支持此协议。
使用HTTPS时，所有的HTTP请求和响应数据在发送到网络之前，都要进行加密。HTTPS在HTTP下面提供了一个传输级的密码安全层——可以使用SSL，也可以使用其后继者，传输层安全(Transport Layer Security,TLS)。
大部分困难的编码及解码工作都是在SSL库中完成的，所以web客户端和服务器在使用安全HTTP时无需过多地修改器协议处理逻辑。在大多数情况下，只需要用SSL的输入/输出调用取代TCP的调用，再增加其他几个调用来配置和管理安全信息就行了。
数字加密
密码 对文本进行编码，使偷窥者无法识别的算法
密钥 改变密码行为的数字化参数
对称密钥加密系统 编/解码使用相同密钥的算法
不对称密钥加密系统 编/解码使用不同密钥的算法
公开密钥加密系统 一种能够使数百万计算机便捷地发送机密报文的系统
数字签名 用来验证报文未被伪造或篡改的校验和
数字证书 由一个可信的组织验证和签发的识别信息
密码
密码学基于一种名为密码(cipher)的秘密代码。密码是一套编码方案——一种特殊的报文编码方式和一种稍后使用的相应解码方式的结合体。加密之前的原始报文通常被称为明文(plaintext或cleartext)。使用了密码之后的编码报文通常被称作密文(ciphertext)。
使用密钥的密码
编码算法和编码机器都可能落入敌人手中，所以大部分机器上都有一些盘号，可以将其设置为大量不同的值以改变密码的工作方式。这些密码参数被称为密钥(key)，要在密码机中输入正确的密钥，解密过程才能正确进行。
对称密钥加密技术
编码时使用的密钥值和解码时一样，这就是对称密钥(symmetric-key)。
保持密钥的机密状态是很重要的，在很多情况下，编/解码算法都是众所周知的，因此密钥就是唯一保密的东西了。好的加密算法会迫使攻击者试遍每一个可能的密钥，才能破解代码。用暴力去尝试所有的密钥值称为枚举攻击(enumeration attack)。可用密钥的数量取决于密钥中的位数，以及可能的密钥中有多少是有效的。
对称密钥加密技术的缺点之一就是发送者和接受者在互相对话之前，一定要有一个共享的保密密钥。每对通信实体都需要自己的私有密钥。如果有N个节点，每个节点都要和其他所有的N-1个节点进行安全对话，总共需要N的平方个保密密钥，这将是一个管理噩梦。
公开密钥加密技术
公开密钥使用了2个非对称密钥:一个用来对主机报文编码，另外一个用来对主机报文解码。编码密钥是众所周知的，但只要主机才知道私有的解密密钥。
所有的公开密钥非对称加密系统所面临的共同挑战是，要确保即便有人拥有了下面所有的线索，也无法计算出保密的私有密钥:
公开密钥
一小片拦截下来的密文(可通过对网络的嗅探获取)
一条报文及与之相关的密文(对任意一段文本运行加密器就可以得到)
混合加密系统和会话密钥
两节点间通过便捷的公开密钥加密技术建立起安全通信，然后再用那条安全的通道产生并发送临时的随即对称密钥，通过更快的对称加密技术对其余的数据进行加密。
数字签名
除了加/解密报文之外，还可以用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证明报文未被篡改过。这种技术被称为数字签名(digital signing)。
客户端将变长报文提取为定长的摘要
客户端对摘要应用了一个"签名"函数，这个函数会将用户的私有密钥作为参数。因为只有用户才知道私有密钥，所以正确的签名函数会说明签名者就是其所有者。
一旦计算出签名，客户端就将其附加在报文的末尾，并将报文和签名都发送给对方。
在接收端，会用公开密钥对签名进行检查，如果不匹配则表示已被篡改。
使用数字签名的好处
签名可以验证是作者编写了这条报文，只有作者才会有最机密的私有密钥，因此，只有作者才能计算出这些校验和。校验和就像来自作者的个人“签名”一样。
签名可以防止报文被篡改，如果有恶意攻击者在报文传输过程中对其进行了修改，校验和就不再匹配了。由于校验和只有作者保密的私有密钥才能产生，所以攻击者无法为篡改了的报文伪造出正确的校验码。
数字证书
数字证书中包含了由某个受信任组织担保的用户或公司的相关信息。数字证书都是由官方的"证书颁发机构"以数字方式签发的。
通过HTTPS建立了一个安全web事务之后，现代浏览器都会自动获取所连接服务器的数字证书。如果服务器没有证书，安全连接就会失败。浏览器收到证书的时候会对签名颁发机构进行检查。
HTTPS——细节介绍
HTTPS将HTTP协议与一组强大的对称，非对称和基于证书的加密技术结合在一起，使得HTTPS不仅很安全，而且很灵活，很容易在处于无序状态的，分散的全球互联网上进行管理。
客户端会对web资源执行某事务时，他会去检查URL的方案，如果URL的方案是https，客户端就会打开一条到服务器端口443(而不是传统的http默认的80端口)的连接，然后与服务器进行SSL"握手"，以二进制格式与服务器交换一些SSL安全参数，附加上加密的HTTP命令。
站点证书的有效性
日期检测
签名颁发者可信度检测
签名检测
站点身份检测
通过代理以隧道形式传输安全流量
客户端通常会用web代理服务器代表它们来访问web服务器。但只要客户端开始用服务器的公开密钥对发往服务器的数据进行加密，代理就再也不能读取HTTP首部了！就无法知道应该将请求转向何处了。
为了使HTTPS与代理配合工作，可以用HTTPS SSL隧道协议。使用HTTPS隧道协议，客户端首先告诉代理，它想要连接的安全主机和端口。这是在开始加密之前，以明文形式告知的。