音视频学习–RTSP Digest认证

最近新带的小伙伴做开发需求时候，碰到一个RTSP鉴权问题，在此也做一下记录，给他讲解明白同时，也希望对其他的小伙伴有帮助。

RTSP鉴权介绍

RTSP 是一种类似于 HTTP 的协议。它具有不同的结构和控制命令，但其格式是文本的，一旦您了解了命令的基础知识以及它们如何交互，就相当容易使用。RTSP 的规范非常简单

RTSP 可以未经身份验证（在现成设备中很常见）或经过身份验证来访问。经过身份验证的访问镜像 HTTP，因为您拥有基本和摘要身份验证，两者几乎与 HTTP 相同。要了解您的设备是经过身份验证还是未经身份验证，只需发送“描述”请求即可。

https://www.rfc-editor.org/rfc/pdfrfc/rfc2326.txt

为了从需要身份验证的 RTSP 服务器访问媒体演示，客户端还必须能够执行以下操作：

•   识别401状态码；
•   解析并包含 WWW-Authenticate 标头；
•   实施基本认证和摘要认证。为了正确处理客户端身份验证，服务器还必须能够执行以下操作：
•   资源需要认证时生成401状态码。
•   解析并包含 WWW-Authenticate 标头
•   实现基本认证和摘要认证

如果设备需要身份验证，则返回的响应将包含“401 Unauthorized”。该响应还将指示可用的身份验证机制。如果基本身份验证可用，则响应字符串将包含一个信息行，其中包含“WWW-Authenticate: Basic”。基本身份验证提供的其余信息在很大程度上与实际进行基本身份验证无关。

如果需要 Digest 身份验证，则“401 Unauthorized”响应将包含包含“WWW-Authenticate: Digest”的信息行。如果您要进行摘要认证，带有摘要规范的信息非常重要，所以不要忽略它。

《图解HTTP》一书中介绍了HTTP认证方式，有兴趣的可以补充学习一下：

DIGEST 认证

本文主要关注DIGEST 认证方式。DIGEST认证方式使用质询 / 响应的方式（challenge/response），但不会像 BASIC 认证那样直接发送明文密码。所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。

步骤 1： 请求需认证的资源时，服务器会随着状态码 401 Authorization Required，返回带 WWW-Authenticate 首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）。首部字段 WWW-Authenticate 内必须包含 realm 和 nonce这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。nonce 是一种每次随返回的 401 响应生成的任意随机字符串。该字符串通常推荐由 Base64 编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现。《图解HTTP》

步骤 2： 接收到 401 状态码的客户端，返回响应中包含 DIGEST认证首部字段 Authorization 信息。首 部  Authorization 内 须 包 含 username、realm、nonce、uri 和 response 的字段信息。其中，realm 和 nonce就是之前从服务器接收到的响应中的字段。username 是 realm 限定范围内可进行认证的用户名。uri（digest-uri）即 Request-URI 的值，但考虑到经代理转发后 Request-URI 的值可能被修改，因此事先会复制一份副本保存在 uri 内。response 也可叫做 Request-Digest，存放经过 MD5 运算后的密码字符串形成响应码。《图解HTTP》

步骤 3： 接收到包含首部字段 Authorization 请求的服务器，会确认认证信息的正确性。认证通过后则返回包含 Request-URI资源的响应。并且这时会在首部字段 Authentication-Info 写入一些认证成功的相关信息。《图解HTTP》

DIGEST 认证提供了高于 BASIC 认证的安全等级，但是和HTTPS 的客户端认证相比仍旧很弱。DIGEST 认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。

DIGEST 认证和 BASIC 认证一样，使用上不那么便捷灵活，且仍达不到多数 Web 网站对高度安全等级的追求标准。因此它的适用范围也有所受限。

DIGEST 认证实例

（1）客户端 DESCRIBE 请求到服务端

DESCRIBE rtsp://192.168.14.211:554 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.17.4 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

（2）RTSP 服务端没有通过校验

RTSP/1.0 401 Unauthorized
CSeq: 3
WWW-Authenticate: Digest realm="6cf17ea8011e",nonce="218e4b2de4178d9ffb9423e99f929e2c",stale="FALSE"

（3）客户端产生 response 信息进行反馈

DESCRIBE rtsp://192.168.14.211:554 RTSP/1.0CSeq: 4Authorization: Digest username="admin", realm="6cf17ea8011e", nonce="218e4b2de4178d9ffb9423e99f929e2c", uri="rtsp://192.168.14.211:554", response="2cb7da57314cd2b4aa3c1876474109cf"User-Agent: LibVLC/3.0.17.4 (LIVE555 Streaming Media v2016.11.28)Accept: application/sdp

（4）服务器对客户端的 response 重新进行校验

RTSP/1.0 200 OKCSeq: 4Content-Base: rtsp://192.168.14.211:554Content-Length: 507Content-Type: application/sdp

VLC代码走读

了解大概原理，我们看一下VLC代码中该部分的实现过程，live55的相关接口如下：

关于rtsp的发起和相应流程本文不做过多解读。

（1）Demux open时候，检查URL链接合法性，并调用connect进行链接，链接时候会发option命令。

（2）接收到服务端反馈的option ack之后，会进行Describe的命令发送：

（3）最初的request请求中并没有携带认证信息，按照第二部分鉴权流程此时客户端会收到401的response消息，vlc相关逻辑是在handleResponseBytes  函数中完成的。依次解析www-Authenticate中携带的digest信息，

调用handleAuthenticationFailure进行处理

（3）之后在RTSPClient端发送request，并创建Authenticator字段串，具体实现参照createAuthenticatorString函数部分。在构建之前会一次判断realm，用户名，密码等。如果非空，则进行构建。如果为空，改用Basic Authenticator认证方式。

（4）computerDigestResponse会进行相关内容构建，调用MD5接口进行加密运算，必将结果返回。

至此客户端相关代码逻辑完成走读。至于服务端的认证部分，有时间在整理。

作者：我是一枚爱跑步的程序猿，维护公众号和知乎专栏《MediaStack》，有兴趣可以关注，一起学习音视频知识，时不时分享实战经验。