基本认证_摘要认证_HTTPS

1.HTTP基本认证

HTTP提供了一个原生的质询/响应（challenge/response）框架。

• Web应用程序收到一条HTTP请求报文时，服务器没有按照请求执行动作，而是以一个“认证质询”进行响应，要求用户提供一些保密信息来说明他是谁，从而对其进行质询。

• 用户再次发起请求时，要附上保密证书(用户名和密码)。如果不匹配，服务器可以再次质询客户端，或产生一条错误信息。如果证书匹配，就可以正常完成请求。

• 总结：就是客户端发起一个请求，服务器说你把能验证你身份的信息(用户名密码)告诉我，客户端把自己用户信息告诉服务端，服务端验证信息是否正确。

1.请求质询首部：WWW-Authenticate(服务器发出)
2.授权首部：Authorization(客户端发出)
3.认证成功首部：Authentication-Info(服务器发出，可选)

WWW-Authenticate是服务端用来质询客户端的，质询的同时，还带着安全域。例如：WWW-Authenticate: Basic realm=”Family”

Authorization向服务器提供用户名密码冒号连接以后用base64加密，例如：>BASE64ENC(totty:ow)=dG90dHk6b3c=；请求时：Authorization:Basic dG90dHk6b3c=

如果验证成功，会返回200OK的文档，有授权算法会在可选的Authentication-Info首部返回一些与授权回话相关的附加信息。

2.摘要认证

基本认证便捷灵活，但是极不安全，用户名密码都是以明文传送的，安全使用基本认证的唯一方式就是将其与SSL配合使用。
摘要认证做到了以下几点：

• 永远不会以明文方式在网络上发送密码。
• 可以防止恶意用户捕获并重新认证的握手过程。
• 可以有选择地防止对报文内容的篡改。

常见的摘要认证：摘要认证是一种单向函数，主要用于将无限的输入值转换为有限的浓缩输出值，常见的有MD5加密。

为了防止重放攻击（截取摘要，并一遍遍的发送给服务器），服务器可以向客户端发送一个成为“随机数”的特殊令牌，这个数会经常变化（可能是每毫秒，或是每次认证都变化），客户端计算摘要之前要先将这个随机数令牌附加到密码上去。随机数在在WWW-Authenticate质询中从服务器传给客户端的。

为了减少“请求/质询”的次数，可以使用预授权。预授权的几种方式：

• 服务器预先在Authentication-Info成功首部中发送下一个随机数。
• 服务器允许在一小段时间内使用同一个随机数。
• 客户端和服务器使用同步的，可预测的随机数生成算法。

3.加密技术基础知识

• 对称加密：加密和解密时使用的密钥是一样的。对称加密的缺点之一就是发送者和接收者在互相对话前，一定要有一个共享的保密密钥。

• 非对称加密：加密和解密时使用两个密钥，一个加密(公钥)，一个解密(解密)。所有的非对称加密的公钥都需要保证知道以下几点都无法计算出私钥：公开秘钥(是共有的，所有人都可以获得)，一小片拦截下来的密文(可通过对网络嗅探获取)，一条报文及与之相关的密文(对任意一段文本运行加密器就可以得到)。

好的加密算法会迫使攻击者试遍每一个可能的密钥，才能破解。

• 数字签名：数字签名是附加在报文上的特殊加密校验码。数字签名的好处：只有作者才能计算出校验和，可以证明是作者编写了这条报文；可以防止报文被篡改。举例说明：节点A是如何向节点B发送一条报文的。1.节点A将变长报文提取为定长的摘要(类似于MD5的方式，无论报文多长经过MD5函数以后都能变成一样长)。2.节点A对“摘要”应用了一个“签名”函数，这个签名函数要将私钥作为参数。3.节点A将算出的签名放在报文的末尾，将报文和签名都发送给节点B。4.节点B检查签名时，使用公钥(与生成签名时用的私钥对应的公钥)的反函数进行拆包得到摘要，再将报文进行提取摘要（此时提取摘要的方式与节点A传输报文前提取摘要的方式一样），看两者是否一致。

4.HTTPS

在实际应用中需要一种能够提供下列功能的HTTP安全技术。

• 服务器认证：客户端知道它们是在与真正的而不是伪造的服务器通话。
• 客户端认证：服务器知道它们是在与真正的而不是伪造的客户端通话。
• 完整性：客户端和服务器的数据不会被篡改。
• 加密：客户端和服务器的对话是私密的，无须担心被窃听。
• 效率：一个运行的足够快的算法，以便低端的客户端和服务器使用。
• 普适性：基本上所有的客户端和服务器都支持这些协议。
• 管理的可扩展性：在任何地方的任何人都可以立即进行安全通信。
• 适应性：能够支持当前最知名的安全方法。
• 在社会上的可行性：满足社会的政治文化需要。

HTTPS是在HTTP的传输层和应用层中间加了一个安全层（SSL）。

Web浏览器对某Web资源执行某些事务时，它会去检查URL的方案。

• 如果URL的方案为http，客户端就会打开一条到服务器端口80(默认情况下)的连接，并向其发送HTTP的命令。
• 如果URL的方案为https，客户端就会打开一条到服务器端口443(默认情况下)的连接，然后与服务器“握手”，以二进制格式与服务器交换一些SSL安全参数，附上加密的HTTP命令。

SSL握手(在发送已加密的HTTP报文之前，客户端和服务器要进行一次SSL握手)：

• 交换协议版本号；
• 选择一个两端都了解的密码；
• 对两端的身份进行认证；
• 生成临时的会话密钥，以便加密信道；

上述握手的实现过程：

• 客户端发送可供选择的密码并请求证书。
• 服务器发送选中的密码和证书。
• 客户端发送保密信息，客户端和服务器生成秘钥。
• 客户端和服务器互相告知，开始加密过程。

HTTPS建立了一个安全的Web事务之后，现代浏览都会自动获取所连接服务器的数字证书。如果服务器没有证书，安全连接就会失败。证书包括的主要内容：

• Web站点的名称和主机名
• Web站点的公开密钥
• 签名颁发机构的名称
• 来自签名颁发机构的签名

浏览器检测站点证书的有效性：

• 日期检测：浏览器检查证书的起始日期和结束日期，以确保证书仍然有效。如果证书过期了，或者还未被激活，则证书有效性验证失败，浏览器显示一条错误信息。
• 签名颁发者可信度检测：每个证书都是由某些证书颁发机构（CA）签发的，它们负责为服务器担保。证书有不同的等级，不能级别的证书申请时需要不同级别的背景验证。比如申请电子商务服务器证书，通常需要提供一个营业的合法证明。
• 签名检测:一旦判定签名授权是可信的，浏览器就要对签名使用签名颁发机构的公开秘钥，并将其与校验码进行比较，以检查证书的完整性。
• 站点身份检测： 为了防止服务器复制其他人的证书，或拦截其他人的流量，大部分浏览器都会试着去验证证书中的域名与它们所对话的服务器的域名是否匹配。服务器证书中通常都包含一个域名，但是有一些CA会为一组或一群服务器创建一些包含服务器名称列表或通配域名的证书。如果主机名与证书中的标识符不匹配，面向用户的客户端要么就去通知用户，要么就以表示证书不正确的差错报文来终止连接。

浏览器收到证书时会对签名颁发机构进行检查。如果这个机构是个很有权威的公共签名机构，浏览器可能已经知道其公开密钥了(浏览器会预先安装很多签名颁发机构的证书)。这样，就可以直接验证签名了，即验证证书的完整性。

HTTPS握手过程: