HTTP识别、认证与安全(https)

阅读的HTTP权威指南 # 客户端识别与cookie机制 Web服务器需要和成千上百个服务器通信。服务器通常需要记录下它们与谁交换，而不会认为所有请求都来自匿名的客户端。能使用的方法主要有： * HTTP首部 * 客户端IP地址 * 用户登录 * 胖URL * cookie

HTTP首部

常见http首部:

首部名称	首部类型	描述
From	请求	用户的Email地址
User-Agent	请求	用户的浏览器软件
Referer	请求	用户是从这个页面跳转过来的
Authorization	请求	用户名和密码
Client-IP	拓展(请求)	客户端的IP地址
X-Forwarded-For	拓展(请求)	客户端的IP地址
Cookie	拓展(请求)	服务器产生的ID标签

客户端IP地址

早期的Web先锋曾尝试将客户端IP作为一种标示形式使用，如果每一个用户一个IP地址，那这个用法说不定还行，不过。。。

用户登录

Web服务器无需被动的根据用户的IP地址来猜测他的用户，它可以要求用户通过用户名和密码进行认证(登录)来显式地询问用户是谁。下一节基本认证会再讲解，关于Authorization中包涵用户的登录信息。服务器不知道用户的时候(认证没通过)一般会返回401错误码。

胖URL

有些Web站点会为每个用户生成特定版本的URL来追踪用户的身份。这个胖URL存在很多问题。 * 丑陋的URL * 无法共享URL * 破坏缓存 * 额外的服务器负荷 * 逃逸口（跳转URL） * 在会话间是非持久的

cookie

cookie是当前识别用户，实现持久会话的最好方式。前面各种技术中存在的问题对他并没有什么影响。

有两种cookie类型，分别是：会话cookie和持久cookie。会话cookie是一种临时cookie，它记录了用户访问站点时的设置和偏好。用户退出浏览器时，会话cookie就删除了。持久cookie的生存时间更长一些，它们储存在硬盘上，计算器重启时，它们仍然存在。通常会用持久cookie维护某个用户会周期性访问的站点的配置文件或登录名。

这里我们需要知道，cookie常见也就是键值对，如：Cookie: name="Hdd"

基本认证机制

认证就是要给出一些身份证明。证明你是你。基本的：HTTP的质询/响应机制。

HTTP的质询/响应认证框架

安全域

Web服务器会将受保护的文档组织成一个安全域。每个安全域可以有不同的授权用户集。 如下图： 下面是一个假想的基本认证质询：

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm = "Corporate Financials"

Base-64 用户名/密码编码

密码和账户名用Base-64编码能无需担心字符集，还有能防止管理员无意间看到用户名和密码。

基本认证的安全缺陷

基本认证简单便捷，但并不安全。只能用它来防止非恶意用户无意间进行的访问，或将其与SSL这样的加密技术配合使用。 缺陷如下： 1. 基本认证会通过网络发送用户名和密码。这几乎与“明文”传送，容易被拦截破解。 2. 即使密码没有被破解，但第三方用户仍可以将修改过的捕获的用户名和秘密不断传送给原始服务器来访问。 3. 即使基本认证用于一些不太重要的应用程序，也要防止有心人用它来“撞库”。 4. 基本认证没有提供任何针对代理和作为中间人的中间节点的防护措施，它们没有修改认证首部，却修改了报文的其他部分，这样就很严重的改变的事物的本质，所以下一节会介绍摘要认证。 5. 假冒服务器很容易骗过基本认证，从而伪造钓鱼网站之类的。

摘要认证

摘要认证的改进

摘要认证是另一种HTTP认证协议，它试图修复基本认证的严重缺陷。如下改进： * 永远不会以明文方式在网络发送密码。

发送的都是密码的摘要，而只有服务端和客户端是知道密码的，那密码第三方就不会知道了。

• 可以防止恶意用户捕获并重放认证的握手过程。

  服务器会生成一个随机数发送给客户端，在进行摘要计算，常见算法为MD5。这时会进行随机数和密码进行摘要处理，随机数和时间戳有关，这样第三方无法得知原始密码，也就无法对新的摘要进行计算。质询握手过程。

• 可以有选择的防止对报文内容的篡改

我们的内容也经过了摘要计算，所及Authentication-Info中qop(保护质量)的信息就也有内容摘要。

• 防范其他几种常见的攻击方式

预授权

在普通认证方式中，事务结束之前，每个请求都有一次请求/质询的循环，而预授权中，客户端知道了随机数就可以取消这一过程，减少报文数量。如图：

安全性考虑

要知道，摘要认证对于密码的保护确实厉害了很多，不过对于窃听报文内容等还是保护不够，真正的安全的事物只有通过SSL才能实现。

安全HTTP

HTTPS前瞻

功能： * 服务器认证（客户端知道他们是在于真正的服务器而不是伪造的服务器通话） * 客户端认证（服务器知道他们在与真正的客户端而不是伪造的客户端通话） * 完整性（保证数据不被修改） * 加密（通话是私密的，不用担心被窃听） * 效率（足够快） * 普适性（基本上所有的服务器端和客户端都能支持） * 管理的可扩展性（任何地方任何人都可以进行安全通信） * 适应性（能够支持当前最知名的安全方法） * 社会可行性（满足社会的政治文化需求）

关于HTTPS的传输：

大部分困难的编码及解码工作都是在SSL库中完成的，所以Web客户端和服务器在使用安全HTTP时无需过多的修改其协议处理逻辑。在大多数情况下，只需要用SSL的输入输出来取代TCP的调用，再增加其他几个调用来配置和管理安全信息就行。

数字加密

密码

对文本加密，使偷窥者无法识别的算法，明文经过密码编码变成密文，再解码为明文

密钥

改变密码行为的数字化参数。

对称密钥加密系统

在对称密钥加密系统，发送端和接收端要共享相同的密钥才能进行通信。 流行的对称密钥加密算法有：DES、Triple-DES、RC2、和RC4

密钥长度和枚举攻击

对于一台服务器，如果有成千上万的客户端进行加密通话，就需要成千上万的秘钥。 为了解决这个问题，可以采用公开密钥加密技术。

不对称密钥加密系统

编/解码使用不同密钥的算法。

公开密钥加密技术

公开密钥加密技术没有为每台主机使用单独的加密/解密密钥，而是使用了两个非对称密钥：一个用来对主机报文编码，另一个用来对主机报文编码。编码密钥是大家都知道的，而主机密钥只有主机知道，也就是只有服务器才知道。

即使你有了下列条件，也无法破解：

1. 公开密钥(市共有的，所有人都可以获得)
2. 一小片拦截下的报文(可通过对网络的嗅探获取)
3. 一条报文及与之相关的密文(对任意一段文本加密即可)

混合加密系统和会话密钥

RSA加密满足了公开加密的技术，但计算的速度可能会很慢，所以比较常见的两个节点的通信采用了混合使用对称和非对称加密。

两个节点通过便捷的公开密钥加密结束建立起安全的通信，然后再用那条安全的通道产生并发送临时的随机对称密钥，通过更快的对称加密技术对其余的数据进行加密。

数字签名

数字签名就是加了密的校验和。

数字签名在数字证书发布的用处就比较大了。

数字证书

发布了的数字证书是需要相关机构认证的。

HTTPS

如果 URL是 HTTP，客户端就会打开一条到服务器端口 80 （默认的HTTP端口）的连接，发送 HTTP 命令。

如果 URL是 HTTPS，客户端就会打开一条到服务器端口443（默认的HTTPS端口）的连接，然后与服务器握手，以二进制的格式与服务器交换一些 SSL 安全参数，握手完成之后 SSL 的初始化就完成了，客户端发送加密的 HTTP 命令。

如果 HTTPS 使用和HTTP 相同的 80端口，那么当加密的 HTTP 命令到达之后，普通的服务器会认为是普通HTTP 命令无法辨认导致错误关闭连接。

但是如果服务器的HTTP层包含了安全HTTP的解析，那么也可以重用80端口而不会引起问题。

SSL握手

内容： * 交换协议版本号 * 选择一个两端都了解的密码 * 对两端的身份进行认证 * 生成临时的会话密钥，用于加密信道

简化版SSL握手：