-->
当前位置:首页 > 实验 > 正文内容

HTTP协议-认证 实验

Luz3年前 (2020-12-11)实验2100

【实验目的】

  • 了解几种HTTP认证方式

【实验原理】
1为什么需要认证:

  如今,使用 Web 系统处理数据、访问信息的人越来越多。通过 Web 可以很方便的进行操作,但仅仅方便是不够的,很多的敏感信息以及特事件处理是不能公开发布的,我们要保证只有特定的人才能看到特定的信息。

  未授权用户无法查看我们的在线档案,也不能在未经许可的情况下向 Web 站点发布文档。我们还要确保,组织中未经授权或不怀好意的成员无法获取那些最敏感的公司计划文档。我们与其他人的私人 Web 通信都是在带有隐私保护的情况下进行的,这样我们才能放心。

  服务器需要通过过某种方式来了解用户身份以及确认用户身份,认证就意味着要证明你是谁。HTTP 为认证提供了一种原生工具,通常是通过提供用户名密码来进行认证。尽管我们可以在 HTTP 的认证形式和 cookie 基础之上"运行自己的"认证工具,但在很多情况下,HTTP 的原生认证功能就可以很好地满足要求。

  本部分主要介绍了最常见的认证形式,基本认证(Basic Authentication)以及摘要认证(Digest Authentication),和一些其他的认证方式。
  注:本次实验为介绍实验,不需要实际操作。了解即可。

##【实验步骤】

###步骤1:Basic Authentication
  1.1 HTTP 协议规范中有两种认证方式,一种是 Basic 认证,另外一种是 Digest 认证,这两种方式都属于无状态认证方式.所谓无状态即服务端都不会在会话中记录相关信息,客户端每次访问都需要将用户名和密码放置报文一同发送给服务端,但这并不表示你在浏览器中每次访问都要自己输入用户名和密码,可能是你第一次输入账号后浏览器就保留在内存中供后面的交互使用。

  基本认证最初是在 HTTP/1.0 中提出的,后来被移到了 RFC2617 中。基本认证的步骤如下:

  1. 服务器收到客户端发送的对受限资源的访问请求

  2. 服务端的 web 容器将 http 响应报文的响应码设为 401,响应头部加入 WWW-Authenticate ,这个首部请求对受限资源进行基本认证

  3. 浏览器收到401响应码,弹出对话框提示用户输入用户名及密码,用冒号连接并进行 base64 编码,然后将其放入 Authorization 首部字段中返回

  4. 服务器对用户名密码进行解码并验证,如果成功则返回 HTTP 200 OK 以及请求的资源信息

  客户端请求(没有认证信息):

GET /private/index.html HTTP/1.0

Host: localhost

  服务器响应:

HTTP/1.0 401 Authorization Required

Server: HTTPd/1.0

Date: Sat, 27 Nov 2017 10:18:15 GMT

WWW-Authenticate: Basic realm="Secure Area"

Content-Type: text/html

Content-Length: 311

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

<HTML>

 <HEAD>

   <TITLE>Error</TITLE>

   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">

 </HEAD>

 <BODY><H1>401 Unauthorized.</H1></BODY>

</HTML>

  客户端请求(用户名"admin",密码"password"):

GET /private/index.html HTTP/1.0

Host: localhost

Authorization: Basic YWRtaW46cGFzc3dvcmQ=

  (跟随一个空行)

  Authorization 消息头的用户名和口令的值可以容易地编码和解码:

print "admin:password".encode("base64")

print "YWRtaW46cGFzc3dvcmQ=".decode("base64")

  服务器响应:

HTTP/1.0 200 OK

Server: HTTPd/1.0

Date: Sat, 27 Nov 2017 10:19:07 GMT

Content-Type: text/html

Content-Length: ***

  (跟随一个空行,随后是 HTML 文本)。

  1.2 下图显示了使用 Base64 编码的基本认证实例:

 

图1

  1.3 基础认证存在两个缺陷:

  1. 无状态导致每次通信都要带上认证信息,即使是已经认证过的资源;

  2. 传输安全性不足,认证信息用 Base64 编码,基本就是明文传输,很容易对报文截取并盗用认证信息。

本节考核:
知识点:基本认证
题目:基本认证最初是在HTTP/【 】中提出的(请按标准填写)
正确答案:1.0

###步骤2:Digest 认证
  2.1 HTTP 协议规范的另一种认证模式是 Digest 模式(HTTP 摘要认证),在 HTTP1.1 时被提出来,它主要是为了解决 Basic 模式安全问题,用于替代原来的 Basic 认证模式,Digest 认证与 Basic 认证基本的认证流程比较类似,使用 质询 / 响应(Challenge / Response)方式:

  1. 服务器返回 401 Authorization Required, 响应中首部字段包含 临时质询码(nonce 随机数)及 Request-URI 安全域字串(realm, 即 digestURI)

  2. 客户端的认证响应计算公式 Response = MD5(HA1:nonce:HA2),其中 HA1=MD5(username:realm:password), HA2=MD5(method:digestURI)

  客户端请求(无认证):

GET /dir/index.html HTTP/1.0

Host: localhost

  (跟随一个新行,形式为一个回车再跟一个换行)

  服务器响应:

HTTP/1.0 401 Unauthorized

Server: HTTPd/0.9

Date: Sun, 10 Apr 2005 20:26:47 GMT

WWW-Authenticate: Digest realm="testrealm@host.com",

                       qop="auth,auth-int",

                       nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

                       opaque="5ccc069c403ebaf9f0171e9517f40e41"

Content-Type: text/html

Content-Length: 311

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

<HTML>

 <HEAD>

   <TITLE>Error</TITLE>

   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">

 </HEAD>

 <BODY><H1>401 Unauthorized.</H1></BODY>

</HTML>

  客户端请求(用户名"Mufasa", 密码"Circle Of Life"):

GET /dir/index.html HTTP/1.0

Host: localhost

Authorization: Digest username="Mufasa",

                    realm="testrealm@host.com",

                    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

                    uri="/dir/index.html",

                    qop=auth,

                    nc=00000001,

                    cnonce="0a4f113b",

                    response="6629fae49393a05397450978507c4ef1",

                    opaque="5ccc069c403ebaf9f0171e9517f40e41"

  (跟随一个新行)

  服务器响应:

HTTP/1.0 200 OK

Server: HTTPd/0.9

Date: Sun, 10 Apr 2005 20:27:03 GMT

Content-Type: text/html

Content-Length: 7984

  (随后是一个空行,然后是请求的 HTML 页面)

  2.2 摘要认证的安全性说明:

  1. 使用 MD5 加密是为了达成 "不可逆的",但如果没有加入随机数 nonce,容易遭到破解攻击(如彩虹表)

  2. RFC 2617 引入了一些安全增强的选项,如质量保护(QoP),客户端随机数(clientNonce),以防止重放攻击

  3. 可能遭受中间人攻击,即伪装服务器告知客户端使用基本认证或早期的 RFC 2069 摘要访问认证模式(安全级别弱);进一步而言,摘要访问认证没有提供帮助客户端验证服务器身份的机制

  2.3 其实通过哈希算法对通信双方身份的认证十分常见,它的好处就是不必把具备密码的信息对外传输,只需将这些密码信息加入一个对方给定的随机值计算哈希值,最后将哈希值传给对方,对方就可以认证你的身份。Digest 思想同样采如此,用了一种 nonce 随机数字符串,双方约好对哪些信息进行哈希运算即可完成双方身份的验证。Digest 模式避免了密码在网络上明文传输,提高了安全性,但它仍然存在缺点,例如认证报文被攻击者拦截到攻击者可以获取到资源。

###步骤3:SSL/TLS 认证
  3.1 SSL/TLS 介绍

  SSL 即安全套接层 (secure sockets layer),TLS 是 SSL 的继任者,即传输层安全协议 (transport layer security),目的是为互联网通信提供安全及数据完整性保障。SSL 由网景公司于1994年推出。IETF 将 SSL 进行标准化,1999 年公布第一版 TLS 标准文件。随后又公布 RFC 5246 (2008 年 8 月)与 RFC 6176 (2011 年 3 月),目前已成为互联网上保密通信的工业标准。

  SSL 包含记录层(Record Layer)和传输层,记录层协议确定传输层数据的封装格式。传输层安全协议使用 X.509 认证,之后利用非对称加密演算来对通信方做身份认证,之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密,保证两个应用间通信的保密性和可靠性,使客户与服务器应用之间的通信不被攻击者窃听。

  一个 HTTPS 协议栈大致如下图所示:

 

图2

  相关基本概念:

  • 数字证书:一种文件的名称,好比一个机构或人的签名,能够证明这个机构或人的真实性。其中包含的信息,用于实现上述功能。

  • 加密和认证:加密是指通信双方为了防止铭感信息在信道上被第三方窃听而泄漏,将明文通过加密变成密文,如果第三方无法解密的话,就算他获得密文也无能为力;认证是指通信双方为了确认对方是值得信任的消息发送或接受方,而不是使用假身份的非法者,采取的确认身份的方式。只有同时进行了加密和认证才能保证通信的安全,因此在 SSL 通信协议中这两者都被应。早期一般是用对称加密算法,现在一般都是不对称加密,最常见的算法就是 RSA。

  • 消息摘要:这个技术主要是为了避免消息被篡改。消息摘要是把一段信息,通过某种算法,得出一串字符串。这个字符串就是消息的摘要。如果消息被篡改(发生了变化),那么摘要也一定会发生变化(如果 2 个不同的消息生成的摘要是一样的,那么这就叫发生了碰撞)。

  3.2 单向认证和双向认证

  何为 SSL/TLS 单向认证,双向认证?
  单向认证指的是只有一个对象校验对端的证书合法性。
  通常都是 client 来校验服务器的合法性。那么 client 需要一个 ca.crt, 服务器需要 server.crt,server.key
  双向认证指的是相互校验,服务器需要校验每个 client,client 也需要校验服务器。
  server 需要 server.key 、server.crt 、ca.crt
  client 需要 client.key 、client.crt 、ca.crt

  3.3 单向认证过程

  一个完整的 HTTPS 单向认证过程如下:

 

图3

  • 客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。

  • 服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息,同时也返回服务器端的证书,即公钥证书

  • 客户端使用服务端返回的信息验证服务器的合法性,包括:
    • 证书是否过期

    • 发行服务器证书的 CA 是否可靠

    • 返回的公钥是否能正确解开返回证书中的数字签名

    • 服务器证书上的域名是否和服务器的实际域名相匹配

  • 客户端向服务端发送自己所能支持的对称加密方案,供服务器端进行选择

  • 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。

  • 服务器将选择好的加密方案通过明文方式返回给客户端

  • 客户端接收到服务端返回的加密方式后,使用该加密方式生成产生随机码,用作通信过程中对称加密的密钥,使用服务端返回的公钥进行加密,将加密后的随机码发送至服务器

  • 服务器收到客户端返回的加密信息后,使用自己的私钥进行解密,获取对称加密密钥。

  接下来客户端和服务器将会使用加密通讯。

  Wireshark 分析

  环境:Server:192.168.111.100 Client:192.168.111.101

  我们只关注 TLSv1.1 的数据包:

 

图4

  • 数据包1 (No. 25) Client Hello 包,即 SSL/TLS 单向认证流程的

  • 数据包2 (No. 27) Server Hello 包,包含服务器证书等。即 SSL/TLS 单向认证流程的

  • 数据包3 (No. 28) 服务器证书验证完成,同时发送 client key exchange+change cipher spec + encrypted handshake message. 即 SSL/TLS 单向认证流程的

  • 数据包4 (No. 29) 秘钥协商,change cipher spec + encrypted hanshake message. 即 SSL/TLS 单向认证流程的

  • 数据包5 (No. 30) 握手完成。开始上层数据传输。SSL/TLS 单向认证流程的

  3.4 双向认证

  双向认证和单向认证原理基本差不多,只是除了客户端需要认证服务端以外,增加了服务端对客户端的认证,具体过程如下:

 

图5

  • 客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。

  • 服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息,同时也返回服务器端的证书,即公钥证书

  • 客户端使用服务端返回的信息验证服务器的合法性,包括:
    • 证书是否过期

    • 发行服务器证书的 CA 是否可靠

    • 返回的公钥是否能正确解开返回证书中的数字签名

    • 服务器证书上的域名是否和服务器的实际域名相匹配

  • 服务端要求客户端发送客户端的证书,客户端会将自己的证书发送至服务端

  • 验证客户端的证书,通过验证后,会获得客户端的公钥

  • 客户端向服务端发送自己所能支持的对称加密方案,供服务器端进行选择

  • 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式

  • 将加密方案通过使用之前获取到的公钥进行加密,返回给客户端

  • 客户端收到服务端返回的加密方案密文后,使用自己的私钥进行解密,获取具体加密方式,而后,产生该加密方式的随机码,用作加密过程中的密钥,使用之前从服务端证书中获取到的公钥进行加密后,发送给服务端

  • 服务端收到客户端发送的消息后,使用自己的私钥进行解密,获取对称加密的密钥,在接下来的会话中,服务器和客户端将会使用该密码进行对称加密,保证通信过程中信息的安全。

  Wireshark 分析

  环境:Server:192.168.111.100 Client:192.168.111.101

  只关注 TLSv1.1 的数据包:

 

图6

  • 数据包1 (No. 55) Client Hello 包,即 SSL/TLS 单向认证流程的

  • 数据包2 (No. 57) Server Hello 包,包含服务器证书等。即 SSL/TLS 单向认证流程的

  • 数据包3 (No. 60) 服务器证书验证完成,同时发送客户端的证书 client.crt , 同时包含 client key exchange+change cipher spec + encrypted handshake message. 即 SSL/TLS 单向认证流程的

  • 数据包4 (No. 61) 服务器验证客户端证书的合法性。通过后进行秘钥协商,change cipher spec + encrypted hanshake message. 即 SSL/TLS 单向认证流程的

  • 重传包 (No. 62) 由于网络原因,TCP 重传第 No. 60 包。

  • 数据包5 (No. 64) 握手完成。开始上层数据传输。SSL/TLS 单向认证流程的

 

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。