发布时间：2020-04-23 17:18
常用HTTP代理认证协议主要包括基本（BASIC）认证协议、NTLM认证协议、Kerberos认证协议和RADIUS认证协议四种，其中NTLM认证协议和Kerberos认证协议在实际应用中被称为集成式认证，具体使用哪一种认证协议是通过代理客户端与代理服务器协商来确定的。
2.3.1 HTTP基本认证协议
在HTTP协议进行通信的过程中，基本认证是一种用来允许Web浏览器，或其他客户端程序在请求时提供以用户名和口令形式的凭证。HTTP协议定义了基本认证过程以允许HTTP服务器对WEB浏览器进行用户身份证的方法，当一个客户端向HTTP服务器进行数据请求时，如果客户端未被认证，则HTTP服务器将通过基本认证过程对客户端的用户名及密码进行验证，以决定用户是否合法。
客户端在接收到HTTP服务器的身份认证要求后，会提示用户输入用户名及密码，假设用户输入的用户名为“testuser”，密码为“888888”，客户端会首先将用户名、密码合并，中间用“：”来隔开，合并后的的字串就是“testuser:888888”，然后
将该字串以BASE64加密，并将加密后的密文附加在HTTP请求头（Request Header）数据中。
HTTP服务器收到客户端的请求包后，会对对用户名及密码进行验证，如果正确，则返回客户端所需要的服务数据；如果不正确，会返回错误代码并且要求客户端重新提供认证信息。整个交互过程如下（模拟个登录百度首页的过程，并假设登录百度需要认证）：
（1）客户端向服务器请求数据，内容可能为一个网页或者一个其它的MIME
类型，此时，假设客户端尚未被验证，客户端请求如下：
Get/index.html HTTP/1.0
Host:www.baidu.com
客户端向www.baidu.com请求其根目录下的index.html页面，使用HTTP 1.0协议。
（2）服务器向客户端反馈401代码：
HTTP/1.0 401 Unauthorised
Server:SokEvo/1.0
WWW-Authenticate:Basic realm="baidu.com"
Content-Type:text/html
Content-Length:xxx
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type"CONTENT="text/html;charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorised.</H1></BODY>
</HTML>
当符合HTTP 1.0或HTTP 1.1规范的客户端（如IE、Opra、Chorme等浏览器）收到返回值为401时，会自动弹出登录窗口，来要求用户输入用户名、密码。
（3）当用户输入用户名和密码后，客户端将用户名和密码用BASE64方式进行处理，并将处理后的BASE64扰码放入前一条请求信息中，具体内容如下：
Get/index.html HTTP/1.0
Host:www.baidu.com
Authorization:Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx
注：xxxx....表示经过BASE64加密处理后的用户名及密码。
（4）当服务器收到请求信息后，会取出Authorization字段后的字符串先进行解密，然后验证解密后用户名及密码的有效性，如果用户名和密码正确，服务器
再将请求资源发送给客户端：
HTTP/1.0 200 OK
Server:www.baidu.com/http1.0
Content-Type:text/html
Content-Length:xxxx
<html>网页内容
</html>
如果经验证用户名及密码不正确，则重新返回到第2步。
（5）通过代理验证后，整个通信会话的过程中，客户端都会在请求包中附加
BASE64处理后的用户名和密码信息。
HTTP基本认证的提供了简单的用户验证功能，适合于安全性要求不高的系统中，如大家所用路由器的配置页面的认证，几乎都采取了这种方式。其缺点是没有灵活可靠的认证策略，如无法提供域（domain或realm）认证功能，另外，BASE64的加密强度非常低，可以说仅能防止搜索把它搜到了。当然，HTTP基本认证系统也可以与SSL或者Kerberos结合，实现安全性能较高（相对）的认证方式[15]。基本认证是定义在HTTP1.0规范（RFC 1945）[16]中，后续的有关安全的信息可以在
HTTP1.1规范（RFC 2616）[17]和HTTP认证规范（RFC 2617）[18]中找到。
基本认证的一个优点是所有流行的网页浏览器都支持基本认证。但基本认证很少在可公开访问的互联网网站上使用，常在小的私有系统中使用。
虽然基本认证非常容易实现，但该方案建立在以下的假设的基础上，即：客户端和服务器主机之间的连接是安全可信的。特别是，如果没有使用SSL/TLS这样的传输层安全的协议，那么以明文传输的密钥和口令很容易被拦截。该方案同样没有对服务器返回的信息提供保护。现存的浏览器保存认证信息直到标签页或浏览器被关闭，或者用户清除历史记录。HTTP没有为服务器提供一种方法指示客户端丢弃这这些被缓存的密钥。这意味着服务器端在不须关闭浏览器的情况下，其实并没有一种有效的方法来登出。
2.3.2 NTLM认证协议
NTLM是NT LAN Manager的缩写，这也说明了协议的来源。NTLM是
Windows NT早期版本的标准安全协议，Windows 2000支持NTLM主要是为了保持其向后兼容性。
早期微软（Microsoft）公司是采用SMB网络通讯协议在网络上传输明文口令。
这个协议是微软（Microsoft）公司和英特尔（Intel）公司在1987年共同制定的，主要是作为Microsoft网络的通信协议，它是一个可允许协议扩展的开放性协议。但是后来出现了LAN Manager Challenge/Response验证机制，简称为LM，但是因为太简单所以很容易被破解。为了解决这个问题，微软于是提出了基于Windows NT的挑战/响应验证机制，简而称之为NTLM。发展到现在，该协议已经有了更新的NTLMv2和Kerberos验证体系。NTLM也属于Windows早期的安全协议。从
Win2000开始默认协议为Kerboros，下列情况会调用NTLM：
（1）遗留客户端或服务器需要登录到网络或本地时。
（2）UNIX客户端需要与NT服务器通话时。
（3）有正在使用验证NTLM的服务器信息块（SMB）后台程序的UNIX客户端时。也即认证方或被认证方有仅支持NTLM情况时。
NTLM以挑战/响应（Challenge/Response）顺序为基础。
（1）客户端发送用户名和域名到服务器。
（2）服务器转发到域控制器DC。
（3）DC用客户端密码随机产生一个8字节得挑战(Challenge)，发送给服务器。
（4）服务器将挑战转发给客户端。
（5）客户端用密码经过hash及DES加密算法等操作得到一个加密结果响应
(Response)发送给服务器。
（6）服务器将响应转发给DC。
（7）DC做同样操作验证客户端响应。
（8）验证结束，返回结果通知服务器。
NTLM认证可以运用在很多地方，以下将采用HTTP协议来说明NTLM认证的原理和过程。
从第一HTTP GET请求开始到后成功接受到HTTP 200 OK的响应，一共有
6个步骤（注：C代表客户端，P代表代理）：第1步：C=>P客户端发送请求GET。
第2步：P=>C HTTP 407。
给出三个Proxy-Authenticate参数：Negotiate、Kerberos、NTLM。Negotiate会根据用户环境选择NTLM或Kerberos。用户一般不直接调用NTLM或Kerberos，而是调用Negotiate。
Negotiate策略：如果用户系统不支持Kerberos，或者没有提供支持Kerberos的信息，则Negotiate会默认返回NTLM给客户端）。第3步：C=>P HTTP/1.1 CONNECT NTLMSSP
选择NTLM算法，向P发送Base64(Type1 message)，带有用户的HOST名字
和域名。这些通过获取计算机信息得到，如果在Linux或其它系统，可以填NULL、
NULL。
第4步：P=>C HTTP 407
P给出Base64(Type2 Message)，其中包含nonce，提供给客户端计算，并给出NTLM算法特性，这个特定的步骤由第3步给出的NTLM flags，P来进行选择，可以指定使用v1还是v2。
第5步：C=>P HTTP/1.1 CONNECT NTLMSSP
C根据NTLM算法计算nonce、user、passwd，给出Base64(Type3 Message)第6步：HTTP/1.1 200 OK
经过第1步的请求后，会给出参数如下所示：
Proxy-Authenticate:Negotiate
Proxy-Authenticate:Kerberos
Proxy-Authenticate:NTLM
然后选择在选择NTLM认证方式后（一般通过调用Negotiate来实现），就需
要构造Type1 Message，然后第4步将由代理给出Type2 Message，后通过发送Type3 Message来完成终验证。
2.3.3 Kerberos认证协议
Kerberos协议是基于对称密钥体制的一种网络授权协议，整个认证过程中需要一受通信双方信赖的第三方（Kerberos服务器）来参与。该协议主要用于非安全网路中个人通信的身份认证，作为TCP/IP网络的可信第三方鉴别协议，可以有效防止中间人攻击和重放攻击，保护数据的完整性。其中Kerberos服务器用于提供安全的网络鉴别，允许用户访问网络中存在的不同服务器。此协议早是在20世纪80年代麻省理工学院开发的一套软件中使用的。为推动Kerberos的持续发展，麻省理工学院在2007年成立了Kerberos协会。该协议目前也存在多个版本，其中前三个版本只在麻省理工学院内部使用，而新版本Kerberos v5是在1993年颁布的。基于Kerberos协议的典型系统为单点登录身份认证系统，即单域身份认证系统，而关于用户到用户的身份认证系统，多采用NTLM协议。为了研究基于Kerberos协议的用户到用户认证系统，在充分研究Kerheros协议的体系结构和工作流程的基础上，对用户到用户的Kerberos身份认证系统的认证过程进行了详细的设计，分析了用户到用户的Kerbers身份认证系统的典型结构。并证明，当一个客户端需要访问另一个客户端的服务时，其支持在两个客户端之间的身份认证。
2.3.3.1 Kerberos的体系结构
整个Kerberos认证系统体系模型可以分为Kerberos服务器（密钥分发中心
KDC）、客户端(Client)和应用服务器(Server)三个部分，下面我们分别对这三个部分进行说明。
（1）密钥分发中心（KDC）
由于对称密码学需要通信双方事先对密钥达成一致协议，但在通信双方只能通过网络进行通信的前提下是无法对密钥进行提前协商的，因此采用的解决方法就是找一个双方都信任的第三方，也就是密钥分发中心，来进行协商。而密钥分发中心与每个注册用户都共享不同的对称密钥，这个密钥是用来进行身份认证的，通过Kerberos注册设置密钥的过程必须是面对面进行的。在两个独立实体（计算机）间进行通信时，密钥分发中心还会产生一个用来加密它们之间交互信息的会话密钥，这个密钥在会话完毕后即销毁。如果密钥分发中心不能正常工作，那么基于其认证的整个网络的通信安全就无法得到保障了。
密钥分发中心主要由认证服务器和票据授权服务器两个独立的逻辑部分构成。认证服务器用于验证实体的身份，假如通过身份验证则为该实体提供票据授权票据(Ticket Granting Ticket，TGT)，实体再通过票据授权票据从票据授权服务器中申请得到服务授权票据(Service Ticket，ST)，然后再依据服务授权票据申请应用服务器来提供相应的服务。用于证明用户身份的票据是Kerberos工作的基础，因此，密钥分发中心是整个Kerberos认证体系的核心[19][20]。
（2）客户端（Client）
Kerberos的客户端(Client)的主要功能就是向密钥分发中心和应用服务器发送各类应用请求消息，然后接收从密钥分发中心和应用服务器返回的对应消息和服务。Kerberos的客户端程序会首先把用户输入的登录密码通过单向散列函数转换为用户的密钥，该密钥对应于密钥分发中心中存储的用户信息通过相同的方式转换得到密钥。
Kerberos的客户端通常采用两种方式来与操作系统进行集成。第一种是把
Kerberos的客户端和操作系统的登陆会话软件（如NT为winlogon）进行关联，当用户输入用户名和口令进行系统登录认证时，Kerberos客户端软件也会同时得到相同的用户名和口令。第二种是就是使用智能卡或者独立客户端登陆的方式，其基本原理是一样的。
（3）应用服务器(Server)
Kerberos的应用服务器主要是用于接收并处理用户的各类服务请求，它会依据会话密钥验证用户的身份，在用户身份得到确认后，为合法用户提供所请求的各类服务。
2.3.3.2 Kerberos的工作流程
Kerberos的工作流程主要可以分为三个阶段[21]，如图2-8 Kerberos工作流程。
图2-8 Kerberos工作流程
（1）客户端（Client）与认证服务器（AS）的通信。
用户通过认证客户端向认证服务器发出进行认证的请求。认证请求消息中包含用户名，而且是以明文发送的（这里不需要加密）。
在认证服务器验证用户身份后，会返回给用户以下两条信息：
消息1：会话密钥（用户与票据授权服务器之间的）。消息1使用用户的密钥进行加密。
消息2：包含用户身份、用户的网络地址、票据的有效期、用户与票据授权服务器之间的会话密钥等信息的票据授权票据。消息2使用票据授权服务器的密钥进行加密。当用户收到上面两条消息（1、2）后，会使用自己的密钥解密消息1并得到用户与票据授权服务器之间的会话密钥。
（2）客户端（Client）与票据授权服务器(TGS)的通信。
用户通过客户端向票据授权服务器发出用户服务认证请求。包括以下两条消息：
消息3：消息3是由从消息2中获取的票据授权票据和申请的服务的身份组成。
消息4：通过用户票据授权服务器会话密钥加密的认证消息，该消息由用户身份信息与时间戳组成。
当票据授权服务器收到上面两条消息（3、4）后，授权服务器从消息3中重新获取消息2，并且使用自己的秘密密钥解密消息2，得到用户身份等信息，并使用该会话密钥解密消息4后取出用户信息，然后与票据授权服务器中的用户信息进行比较，从而验证用户身份的合法性。票据授权服务器在验证了用户身份合法后，从消息3中提取出用户申请服务的身份信息，然后返回以下两条信息给用户：消息5：用户与应用服务器之间的会话密钥。
消息6：服务授权票据，主要包含用户身份、票据有效期、用户网络地址、用户与应用服务器间会话密钥等信息。
当用户收到上面两条消息（5、6）后，会使用自己的秘密密钥解密消息5，然后得到用户与应用服务器之问的会话密钥。
（3）Client与Server的通信
当用户通过客户端向应用服务器发出用户服务认证服务请求时，会发送以下两条消息给应用服务器：
消息6：服务授权票据，包括用户身份、票据有效期、用户网络地址、用户与应用服务器之间的会话密钥等信息。
消息7：用应用服务器会话密钥加密的认证消息。
当应用服务器收到上面两条消息（7、8）后，会使用该会话密钥解密消息7，并将取出的用户信息与ST中的用户信息进行比较，在用户身份的合法性用户得到确认后，应用服务器会返回消息8给用户，确认用户的身份真实有效，并向用户提供服务。
消息8：在用户认证信息中找到时间戳，然后加1，并使用用户与应用服务器会话密钥加密。用户会检查时间戳是否已经被更新，如果都没有问题，则认为该应用服务器是可信的，之后向该应用服务器发送服务请求。
