山东大学软件学院项目实训-创新实训-SDUMeeting(一)
一、前言:
这个项目是山东大学视频会议项目,这个项目基于webrtc构建多人视频会议系统,我负责视频会议客户端及服务端安全防护,这个专栏记录我的个人工作。
二、主要工作
1.webrtc相关的安全问题
2.linux服务器的安全问题
3.web安全问题,包括各种针对web的攻击手段的防护,xss,sql注入,文件注入
三、项目的安全基础
整个项目是以webrtc为基础构建的,webrtc是整个项目的安全基础,webrtc本身安全性比较高,peerconontion之间是加密的,也就是两两之间是加密的,是中心化安全的,也便于管理。
下面对webrtc的安全进行了一些分析
1.SDP
在介绍webrtc的安全性之前以常见的https为例,https是http with tls,采用的是tls加密,https是通过非对称加密、数字签名和数字证书来确保数据传输的安全,这其实是SSL协议的一部分,在webrtc中也会采用类似SSL的机制来保证数据安全,这就是了DTLS。
我们先来看一下,webrtc是如何识别双方身份的。
它首先通过信令服务器交换 SDP,SDP 信息中包括了以下几个重要信息:
a=ice-ufrag:khLS
a=ice-pwd:cxLzteJaJBou3DspNaPsJhlQ
a=fingerprint:sha-256 FA:14:42:3B:C7:97:1B:E8:AE:0C2:71:03:05:05:16:8F:B9:C7:98:E9:60:43:
一个sdp实例
Syntax:identity-assertion = identity-assertion-value*(SP identity-extension)identity-assertion-value = base64identity-extension = extension-name [ "=" extension-value ]extension-name = tokenextension-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff); byte-string from [RFC4566]<ALPHA and DIGIT as defined in [RFC4566]><base64 as defined in [RFC4566]>Example:a=identity:\eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Note that long lines in the example are folded to meet the columnwidth constraints of this document; the backslash ("\") at the end ofa line, the carriage return that follows, and whitespace shall be ignored.
SDP 交换完成后,A 与 B 都获取到了对方的 ice-ufrag、ice-pwd 和 fingerprint 信息,有了这些信息后,就可验证对方是否是一个合法用户了。
其中, ice-ufrag 和 ice-pwd 是用户名和密码。当 A 与 B 建立连接时,A 每次发送数据到B,都要带着它的用户名和密码过来,此时 B 端就可以通过验证 A 带来的用户名和密码与 SDP 中的用户名和密码是否一致的,来判断 A 是否是一个合法用户了。
除此之外,fingerprint也是验证合法性的关键一步,它是存放公钥证书的指纹(或叫信息摘要),在通过 ice-ufrag 和 ice-pwd 验证用户的合法性之余,还要对它发送的证书做验证,看看证书在传输的过程中是否被窜改了。
A 与 B 在传输数据之前,需要经历如下几个步骤。
- 首先通过信令服务器交换 SDP 信息,也就是进行媒体协商。在 SDP 中记录了用户的用户名、密码和指纹,有了这些信息就可以对用户的身份进行确认了。
- 然后就是双方通过 STUN\TURN 协议获得自己的host、srflx 和 relay,交换candidate,这样双方才能建立连接。但是在语言视频直播中,客户端B一般是流媒体服务器,所以客户端A发一个STUN request ,服务端B响应一个STUN response,双方就可以建立连接了,但是发送STUN 消息的时候要带上用户名和密码。如果 STUN 消息中的用户名和密码与交换的 SDP 中的用户名和密码一致,则说明是合法用户。
- A、B建立连接后,则需要进行 DTLS 协商(协商过程下面会讲),交换公钥证书并协商密码相关的信息。同时还要通过 fingerprint 对证书进行验证,确认其没有在传输中被窜改。
- 最后,再使用协商后的密码信息和公钥对数据进行加密,开始传输音视频数据。
在本项目中sfu服务器管理sdp的交换。
2.DTLS协议
https是基于tls加密的,tls是基于tcp的,而 WebRTC 音视频数据的传输主要基于 UDP 协议,因此 WebRTC 对数据的保护无法直接使用 TLS 协议。但 TLS 协议在数据安全方面做得确实非常完善,将 TLS 协议移植到 UDP 协议上,DTLS就诞生了。
在 WebRTC 中为了更有效地保护音视频数据,所以需要使用 DTLS 协议交换公钥证书,并确认使用的密码算法,这个过程在 DTLS 协议中称为握手协议。
DTLS 的握手过程如下:
首先 DTLS 协议采用 C/S 模式进行通信,其中发起请求的一端为客户端,接收请求的为服务端。客户端向服务端发送 ClientHello 消息,服务端收到请求后,回 ServerHello 消息,并将自己的证书发送给客户端,同时请求客户端证书。客户端收到证书后,将自己的证书发给服务端,并让服务端确认加密算法。服务端确认加密算法后,发送 Finished 消息,至此握手结束。
DTLS解决的问题是交换密钥约定使用的加密算法,也就是说DTLS不解决加密、解密的问题 , 加密解密的问题是通过 SRTP/SRTCP 协议解决的。
3.SRTP/SRTCP 协议
RTP/RTCP 协议并没有对它的负载数据进行任何保护。因此,如果你通过抓包工具,如 Wireshark,将音视频数据抓取到后,通过该工具就可以直接将音视频流播放出来。
在 WebRTC 中,为了防止这类事情发生,没有直接使用 RTP/RTCP 协议,而是使用了 SRTP/SRTCP 协议 ,即安全的 RTP/RTCP 协议。
WebRTC 使用了非常有名的 libsrtp 库将原来的 RTP/RTCP 协议数据转换成 SRTP/SRTCP 协议数据。
后两个协议是webrtc封装好的,在调用peerconnection的时候建立协议连接。
项目整体的安全架构
+----------------+| || Signaling || Server || |+----------------+^ ^/ \HTTPS / \ HTTPS/ \/ \v vJS API JS API+-----------+ +-----------+| | Media | |Alice | Browser |<---------->| Browser | Bob| | (DTLS+SRTP)| |+-----------+ +-----------+^ ^--+ +--^ ^| | | |v | | v+-----------+ | | +-----------+| |<--------+ | || IdP1 | | | IdP2 || | +------->| |+-----------+ +-----------+