山东大学软件学院项目实训-创新实训-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   ||           |   +------->|           |+-----------+            +-----------+