brunch

매거진 WebRTC
라이킷 12 댓글 공유

You can make anything
by writing

C.S.Lewis

프로젝트 리스트 바로가기
계정을 잊어버리셨나요?
by 에디의 기술블로그 Dec 10. 2021

[번역]A Study of WebRTC Security

해당 글은 아래 링크를 번역하였습니다. 번역이 매끄럽지 않으니, 이해가 되지 않는 내용은 원서를 참고해주시길 바랍니다.

https://webrtc-security.github.io/

A Study of WebRTC Security · A Study of WebRTC Security

webrtc-security.github.io

 


최근 필자는 회사에서 WebRTC 업무를 진행 중이다. WebRTC관련 레퍼런스를 찾아서 읽어보고 있지만, 국내 문서가 별로 없어서 WebRTC를 이해하기에 어려움이 많다. 해당 글은 WebRTC 보안 관련 영문 글을 번역한 글이다. 틈틈이 주말에 번역해서 회사에 공유하였는데, 필자의 기술 블로그에도 글을 남겨놓겠다. 조금이라도 도움이 되기를 바란다. 참고로, 네이버 파파고, 카카오 i 번역 도구의 도움을 받았고, 일부 번역이 매끄럽지 않다.


이해가 되지 않는 내용은, 원서를 직접 읽어보길 바란다.



Abstract

WebRTC(Web Real-Time Communication)는 별도의 플러그인 설치 없이 브라우저에서 실시간 통신을 가능하게 하는 웹 애플리케이션 최신 기술이다. 하지만, 오픈소스인 WebRTC는 잠재적으로 보안 관련 우려를 야기할 수 있다. 해당 글에서는 WebRTC의 보안에 대해서 자세히 논의한다.


1. Introduction

WebRTC는 플러그인 설치 없이 실시간으로 미디어를 전송할 수 있는 오픈소스 웹 기반 기술이다. WebRTC를 지원하는 브라우저를 사용하면 사용자는 웹페이지에서 다른 사람에게 전화(또는 영상통화)를 걸 수 있다.


이 기술의 주요 사용 사례는 다음과 같다.


- 실시간 오디오/비디오 통화

- 온라인 회의

- 직접 데이터 전송


대부분의 실시간 시스템(예:SIP)과 달리, WebRTC 통신은 자바스크립트 API를 사용해서 일부 웹서버에 의해 직접 제어된다. 사용자는 별도의 플러그인을 설치할 필요가 없으며, 웹브라우저에 의해서 오디오와 영상 통신이 가능하다. 이런 사실은 매우 흥미롭다. 그러나 이것은 자연스럽게 기술의 보안 우려를 불러일으키고, 최종 사용자와 중개 통신사 또는 제삼자 모두에게 신뢰할 수 있는 통신을 제공할 수 있는지에 대한 우려를 제기한다. 이 문서에서는 이러한 보안 주제를 다루고, WebRTC가 제공하는 보안 관련 기능을 살펴보겠다. (단, 문서의 목적상 기본 애플리케이션은 범위를 벗어난 것으로 간주하겠다.)


2. Overview of WebRTC Architecture

WebRTC는 Peer-to-peer(P2P) 토폴로지를 사용하여 각 피어 간에 미디어(오디오 및 영상)의 직접 통신을 가능하게 한다. WebRTC를 기본으로 제공하는 브라우저, 예를 들어서 크롬 브라우저를 사용한다면, 별도의 소프트웨어를 사용할 필요가 전혀 없다. 피어 간의 실제 통신은 "시그널링"이라고 하는 메타데이터의 교환을 먼저 수행해야 한다. "시그널링"은 서로 알지 못하는 당사 간 간의 연결을 위한 초기화 과정이다.


단, 시그널링 프로세스는 WebRTC 스펙에 명확하게 명시되어 있지 않다. 그래서, 개발자들은 자신만의 프로토콜을 선택해서 구현해야 한다. WebRTC 애플리케이션은 서비스 사례 또는 시나리오에 맞게, "시그널링" 프로세스를 적절하게 적용할 수 있다.


How does WebRTC communication work?

WebRTC는 웹애플리케이션 실시간 통신을 위해서 아래와 같은 3개의 API에 의존한다.

- getUserMedia

- RTCPeerConnection

- RTCDataChannel


이 글에서는, 해당 API에 대해서 아주 간략하게만 설명한다. 각 프로토콜과 기술 구현 및 세부 사항은 온라인에서 쉽게 찾을 수 있다.


getUserMedia

오랫전부터 PC에서 오디오 또는 비디오를 캡쳐하기 위해서는 Flash 또는 Silverlight 같은 브라우저 플러그인을 사용해야 했다. 그러나, HTML5의 시대에서는 플러그인 설치 없이 카메라 또는 마이크를 사용할 수 있는 자바스크립트 API를 제공한다. HTML5의 스펙 중 "getUserMedia"는 브라우저가 사용자의 카메라와 마이크에 액세스 할 수 있도록 하는 API이다. (WebRTC에서 사용되지만 해당 API는 HTML5 기본 스펙이다.)


RTCPeerConnection

"RTCPeerConnection"는 WebRTC 스펙의 일부로 특별히 제공되는 API이다. "RTCPeerConnection"는 WebRTC 연결을 나타내며 두 피어 간의 효율적인 데이터 스트리밍을 처리하기 위해서 사용된다.


호출자가 원격의 상대방과 연결을 시작하려고 할 때 브라우저는 "RTCPeerConnection"객체를 인스턴스화하는 것으로 시작한다. 이때, 피어간 통신을 위해서 호출자가 직접 생성한 "SDP Description"를 포함한다. 수신자 역시, 수신자가 직접 생성한 "SDP Description"으로 응답한다. "SDP Description"은 NAT 횡단을 위한 전체 ICE Workflow의 일부로 사용된다.


궁극적으로 "RTCPeerConnection"는 각 피어 간 연결의 전체 라이프사이클 관리하는데, 모든 연결 설정 및 상태를 관리하기 위한 API를 사용하기 쉽게 인터페이스 내에 캡슐화해서 제공된다. 


RTCPeerConnection 두 가지 특징은 아래와 같다.


- 브라우저간 직접 P2P 통신

- UPD 통신


위와 같은 특징은, TCP 통신처럼 패킷 도착에 대한 보장은 없지만 통신 오버헤드를 많이 감소시킨다. 즉, 일부 데이터 손실을 허용하지만, 실시간 통신에 집중할 수 있게 된다.


References: [1] [2]


RTCDataChannel

"RTCDataChannel"는 WebRTC 스펙으로 특별히 제공되는 두 번째 중요한 API이다. 피어간 데이터 교환 시 주요 통신 채널을 나타낸다. 즉, 상대방에게 데이터를 직접 전송하는 데 사용된다.


통신 채널에 대한 다른 대안(WebSocket, Server Sent Events) 이 존재하지만, 이러한 대안들은 대부분 서버와의 통신을 위해 설계되었다. "RTCDataChannel"는 웹소켓과 유사하지만, 사용자 지정 가능한 통신 속성을 제공하면서 P2P 형식을 사용한다는 차이점이 있다.


2.1. Underlying Technologies

위에서 설명한 3개의 API는 WebRTC의 개발자 측면이지만, 이러한 프로토콜(RTCPeerConnection, RTCDataChannel API)을 제공하기 위해서는 수많은 기반 기술이 존재한다.


ICE, STUN 및 TURN 은 UDP 통신에서 피어 간 연결을 설정하고 유지하기 위해서 필요하다. 암호화는 WebRTC의 필수 기능이기 때문에 피어 간 통신에서 모든 데이터를 보호하기 위해서 DTLS가 사용된다. 또한, SCTP, SRTP는 서로 다른 스트림을 다중화하고, 흐름 제어를 제공하며, 신뢰할 수 있는 전송 및 부가 서비스를 UDP 위에 제공하는 데 사용되는 애플리케이션 프로토콜이다.


- SDP

- ICE

- STUN

- TURN


SDP: Session Description Protocol

SDP(Session Description Protocol)는 멀티미디어 세션의 다른 시작 작업을 수행할 뿐만 아니라 세션 초대를 알리고 관리하는 표준 방법으로 사용되는 기술 프로토콜이다. SDP는 브라우저 기능과 기본 설정을 텍스트 기반 형식으로 나타내며 다음과 같은 정보를 포함할 수 있다.


- 미디어 기능(비디오, 오디오) 및 사용된 코덱

- IP 주소 및 포트 번호

- P2P 데이터 전송 프로토콜(WebRTC는 SecureRTP 사용)

- 사용 가능한 통신용 대역폭(이름, 식별자)e active 등) (단, WebRTC에서는 사용되지 않는다.)

- 기타 관련 메타데이터


최근 SDP는 Session Initiation Protocol(SIP), Real-time Transport Protocol(RTP), Real-time Streaming Protocol(RSP)로서 널리 사용된다.


References: [3]


ICE: Interactive Connectivity Establishment

시그널링 서버는 메타데이터 교환을 위한 중개 서버로서, 시그널링 프로세스는 통신을 위한 최초 과정이다. 시그널링이 완료되면 사용자(피어) 사이에 직접 P2P 연결을 설정하려고 시도하는데, 이때 "ICE 프레임워크(이하 ICE)"를 통해 수행된다.


WebRTC는 직접 P2P 연결을 시도하려고 하지만, 실제로 광범위한 NAT(Network Address Translation)의 존재로 인해 두 개의 피어가 통신하는 방식을 협상하기는 쉽지 않다. 그래서 ICE는 P2P 통신 전에, 인터넷을 통해 피어 간의 연결을 설정하는 데 사용된다.


(제한된 32비트 IPv4 주소로 인해서) 대부분의 네트워크 장치들은 인터넷 환경에서 고유한 퍼블릭 IPv4 주소를 가지고 있지 않다. NAT 환경에서 아웃바운드 요청으로 나가는 통신은, 개인 주소(사설 IP)를 퍼블릭한 공용 주소로 동적으로 변환하여 작동한다. 마찬가지로, 퍼블릭한 공용 IP로 들어오는 인바운드 요청은 내부 네트워크에서 올바른 라우팅을 보장하기 위해 개인(사설) IP로 다시 변환되어 동작한다. 결과적으로 개인(사설) IP를 공유하는 것은 피어간 연결을 초기화하기에는 충분하지 않다. ICE는 NAT를 통해 통신함으로써 피어를 연결하는 가장 좋은 경로를 찾아서, 통신 초기화에 발생하는 어려움을 극복하려고 시도한다.


ICE는 가능한 모든 방법 중 가장 효율적인 방법을 선택해서, 장치의 운영 체제와 네트워크 카드에서 얻은 호스트 주소를 사용하여 연결하려고 시도한다. 이런 방법이 실패한다면, ICE는 STUN 서버를 사용하여 외부 주소를 가져온다. 이 경우에도 실패한다면 트래픽이 TURN 릴레이 서버를 통해 라우팅으로 다시 이동한다.


후보 통신 경로는 텍스트 기반 포맷으로 렌더링 되며, 목록은 우선순위에 따라 정렬된다.(?)

옵션은 다음 중 하나의 형태를 따른다.


- 직접 P2P 통신

- STUN 사용 및 NAT 트래버설 포트 매핑 사용 (결국, 직접 P2P 통신)

- TURN을 중개자로 사용 (P2P가 아닌 릴레이 통신을 사용)


가능한 모든 후보 중에서 오버헤드가 가장 작은 경로가 선택된다.


STUN: Session Traversal Utilities for NAT

P2P 통신을 수행하기 위해서, 양쪽 모두 반드시 피어의 IP 주소와 할당된 UDP 포트에 대한 정보가 필요하다. 그러므로, WebRTC에 의한 통신이 본격적으로 시작하기 전에, 최소 정보 교환이 필요한 것이다.


STUN 서버는 각 피어가 공용(퍼블릭) IP 주소를 결정하기 위해 사용되며 연결 설정 중에 ICE 프레임워크에서 참조된다. STUN 서버는 일반적으로 공개적으로 접근할 수 있으며 WebRTC 응용 프로그램에서 자유롭게 사용할 수 있다.


TURN: Traversal Using Relays around NAT

STUN 서버에 의한 P2P 통신 설정이 실패하는 경우, TURN 서버를 사용하는 예비 옵션을 제공할 수 있다. 피어 간에 트래픽을 중계함으로써 WebRTC 통신을 구축할 수 있다. 단, 미디어 품질이 떨어지고, 통신 대기 시간이 길어질 수는 있다.


TURN 서버는 최종 사용자의 환경에 관계없이 통화 설정의 높은 성공을 보장할 수 있다. 단, 데이터가 중간 서버를 통해 전송됨에 따라 서버 대역폭이 소모되며, 서버를 통해 많은 호출이 발생하면서, 실시간으로 동시에 라우팅 될 경우 대역폭도 상당히 커질 수 있다.


TURN 서버 자체는 일반적으로 자유롭게 액세스 할 수 없으며 애플리케이션 공급자가 자체적으로 구축해야 한다. (또는 임대해서 사용해야 한다.)


3. Browser-based

Security Considerations

일반적으로(WebRTC와 별개로) 실시간 통신 애플리케이션에서 중개자와  보안을 위협하는 여러 가지 방법이 있다. 이러한 보안 위협은, 실시간 데이터 및 미디어를 전송하는 모든 애플리케이션에 적용될 수 있다.


WebRTC는 보안을 위협하지 않고 안전하게 사용할 수 있도록 강력하고 안정적인 인프라를 제공한다. (다른 RTC 앱과는 다르며, 신규 초보 개발자도 사용할 수 있다.) 이 글에서는, WebRTC가 이러한 보안 위험을 어떻게 처리하는지에 대해서 논의하겠다.


References: [5]


3.1. Browser Trust Model (번역 어려움...)

WebRTC 아키텍처는 보안 관점에서, 네트워크 자원이 신뢰 계층에 존재한다고 가정한다. 사용자 관점에서, 브라우저 또는 클라이언트는 모든 WebRTC 보안의 기본이며, Trusted Computing Base(TCB) 역할을 한다.


브라우저의 역할은 사용자에게 적절하게 보안 보호를 제공하면서 인터넷을 사용할 수 있도록 하는 것이다. WebRTC의 보안 요구사항은 브라우저에 의해서 직접 구축된다. 브라우저는 사용자가 모든 WebRTC 응용 프로그램 및 콘텐츠에 액세스 하는 포털(관문?)이다.


서버에서 제공하는 HTML과 JS는 브라우저가 다양한 작업을 실행하게 할 수 있지만 브라우저는 이러한 스크립트를 샌드박스(?)로 분리한다. 샌드박스는 스크립트를 서로, 그리고 사용자의 컴퓨터에서 분리시킨다. 일반적으로 스크립트는 동일한 도메인, 더 구체적으로는 동일한 "오리진"의 리소스와만 상호 작용할 수 있다.


브라우저는 사용자가 원하는 모든 보안 정책을 실행하며, 모든 서드파티 검증의 첫 번째 단계이다. 인증된 모든 엔티티는 브라우저에서 신원을 확인한다.


사용자가 신뢰할 수 있는 브라우저를 선택한다면, 기본적으로 모든 WebRTC 통신은 "보안"에 안전하며, WebRTC 기술의 표준 승인된 보안 아키텍처를 따를 수 있다. 그러나, 신뢰할 수 없는 브라우저를 선택한다면, WebRTC 애플리케이션과의 모든 상호 작용에 보안 위험에 노출되므로, 통신에 안전하지 않을 수 있다.


즉, WebRTC는 사용자에게 제공하는 신뢰 수준은 브라우저에 대한 사용자의 신뢰에 의해 직접적으로 영향을 받게 된다.(?)


3.2. SOP: Same Origin Policy

기본적으로, 웹페이지 화면이 로드(렌더링)되기 위해서는, 웹 페이지의 모든 리소스를 서버에서 가져와야 한다. 웹 페이지 리소스를 가져오는 것은, 브라우저에 의해 화면이 새로 로드될 때 또는 특정 이벤트에 의해서 자바스크립트가 동작할 때 수행된다. 이러한 스크립트는 XMLHtpRequest API를 통해 HTTP 요청을 쉽게 호출할 수 있지만 아무 서버에 요청할 수는 없으며, 반드시 스크립트를 제공하는 동일한 서버에 요청해야 한다. 서버의 주소는 URI 체계, 호스트 이름 및 포트 번호로 구성되는데, 이러한 전반적인 제한을 "Same Origin Policy" (SOP)라고 부른다.


SOP는 스크립트가 원래 도메인에 특화된 격리된 환경에서만 실행되도록 제한해서, 다른 출처의 페이지 또는 같은 페이지 내에 삽입된 iframe에서 정보를 교환하지 못하도록 막는다. 이러한 제한으로 인해서, 동일한 오리진 서버의 웹 페이지와 스크립트는 서로의 JS 변수와 상호 작용하는 데 방해받지 않는다. 이처럼, 오리진은 웹 샌드박싱(?)의 기본 단위를 구성한다.


오리진 별로 샌드박스를 시행함으로써, 최종 사용자는 인증 정보의 악용으로부터 보호된다. 우리는 (우리의 로그인 정보를 도난당하지 않고) 소셜 네트워킹 웹사이트를 안전하게 사용할 수 있을 것으로 합리적으로 기대할 수 있다.


마찬가지로, 웹페이지 제공자의 서버는 사용자의 브라우저에 의한 공격으로부터 보호된다. 이러한 안전장치가 존재하지 않는 경우, 남용된 자원 요청을 통해 DoS 공격을 시작할 수 있다.


References: [6]


3.2.1 Bypassing SOP

SOP는 사용자와 웹 서버 보안에 매우 중요한 역할을 하지만, 특정 유형의 웹 애플리케이션을 만들기 더 어렵게 만드는 단점은 있다. 이러한 단점을 보완하기 위해서, 상호 합의된 특정한 채널에만 제공할 수 있도록 사이트 간 상호 작용을 허용하는 방법이 있다.


W3C CORS(Cross-Origin Resource Sharing)는 이 문제에 대한 방법 중 하나이다. 이것은 브라우저가 스크립트 타겟 서버에 접속하여, 주어진 유형의 트랜잭션에 참여할 의향이 있는지를 결정할 수 있게 한다. 따라서, 타겟 서버에 특정 요청을 참여하도록 허락하고, 그 외 다른 모든 요청에 대해서는 거부할 수 있는 선택을 할 수 있다. 그러므로, 교차 출처 요청(다른 도메인에서의 요청)을 안전하게 선택적으로 허용할 수 있다.


웹소켓은 비슷한 기능을 허용하지만, 분리된 HTTP 요청보다는 투명한 채널에서만 가능하다. 일단 그러한 연결이 확립되면, 스크립트는 일련의 HTTP 요청 / 응답 트랜잭션으로 프레임 화할 필요성을 가지고 원하는 대로 트래픽 및 리소스를 전송할 수 있다.


어쨌든, 두 경우 모두 초기 검증 단계에서 출처가 다른 스크립트에 의한 임의 데이터 전송을 금지한다.


4. WebRTC Security Considerations

References: [7]


4.1. Installation and Updates

전통적인 데스크탑 소프트웨어의 일반적인 문제는, 애플리케이션 자체를 신뢰할 수 없다는 것이다. 새로운 소프트웨어 또는 플러그인을 설치하는 것은, 악성 프로그램이나 원하지 않는 소프트웨어가 몰래 설치될 잠재적인 가능성이 있다. 많은 사용자들은 소프트웨어를 어디서 설치했는지, 정확히 누구로부터 다운로드하고 있는지 자세히 모른다. 악성 소프트웨어를 배포하는 사람들은, 악성 코드가 포함하도록 소프트웨어를 재포장해서 무료 웹사이트에서 배포한다.


그러나, WebRTC는 플러그인이 아니며, 구성 요소에 대한 설치 프로세스가 전혀 없다. 모든 기본 WebRTC 기술은 크롬이나 파이어폭스와 같은 신뢰할 수 있는 브라우저를 사용하는 것만으로도 충분히 가능하다. 우리가 신뢰할 수 있는 브라우저를 사용한다면, 별도의 설치 과정이 없이 WebRTC 응용 프로그램을 사용할 수 있으며, 악성 프로그램이나 바이러스에 노출되는 위험이 없다. 단, WebRTC 앱은 반드시 유효한 HTTPS 웹사이트를 통해 액세스해야 한다.


또 다른 고려사항은 소프트웨어에서 발견된 보안 결함을 패치하는 것이다. 다른 소프트웨어 기술과 마찬가지로 WebRTC는 언젠가는 미래의 버그나 취약점이 발견될 수 있다. 보안은 애플리케이션의 기능 외에 고려해야 할 매우 중요한 요소이지만, 기존 데스크톱 응용 프로그램에서 취약성이 발견되면 패치 개발에 상당한 시간이 걸릴 수 있다. 우리는 소프트웨어의 보안 업데이트를 얼마나 자주 받는가? 애플리케이션 제공자가 정기적으로 보안 업데이트를 해줄 것이라고 전적으로 믿는가?


이와는 다르게, 일반적인 브라우저는 브라우저를 통해 접근하는 정보가 중요하며, 사용자가 노출되는 위험의 빈도와 범위로 인해서 매우 빠르게 업데이트가 되어야 한다. WebRTC의 구성요소는 브라우저의 일부로 제공되므로 브라우저가 업데이트될 때마다 마찬가지로 업데이트가 된다. 브라우저의 WebRTC 구현에서 향후 취약점을 발견할 경우, 업데이트가 매우 빠르게 제공될 가능성이 높다. 신뢰할 수 있는 브라우저인, 크롬이나 파이어폭스에서는 매우 빠르게 업데이트가 된다. 이러한 자동 업데이트에 의해서, WebRTC 구성요소는 패치가 서버에 제공되면 바로 새로운 브라우저를 통해서 업데이트가 가능하다. 대부분의 현대 브라우저는 심각한 취약성이나 위협이 발견된 후 24시간 이내에 자동 업데이트한 좋은 기록을 가지고 있다.


단, 위에서 계속 설명한 듯이 WebRTC는 플러그인을 설치할 필요가 없다고 언급했지만, WebRTC를 지원하지 않는 신뢰할 수 없는 브라우저(예: Safari 및 IE)에서 사용할 수 있도록 별도의 플러그인을 제공할 수는 있다. 이러한 경우에는 주의가 필요하며, 가능하면 WebRTC를 정식으로 지원되는 신뢰할 수 있는 브라우저를 사용하는 것이 좋다.


4.2. Access to Media/Local resources

브라우저는 카메라, 마이크와 같은 개인 로컬 자원에 액세스 할 수 있으며, 사용자의 마이크와 카메라에 접근하는 웹 애플리케이션의 불가피한 문제를 야기한다. 웹 애플리케이션이 사용자의 카메라 또는 마이크에 자유롭게 액세스 할 수 있다면, 비양심적인 애플리케이션은 사용자 모르게 몰래 사용자의 카메라 또는 마이크를 사용해서, 비디오 또는 오디오를 녹음할 수 있다. 사용자는 사이트가 이러한 통신 애플리케이션을 가지고 있다는 사실조차도 깨닫지 못하는 경우가 많으며, 웹 사이트가 사용자의 신뢰를 남용하는 것은 간단한 문제일 수 있다.


WebRTC는 사용자가 카메라나 마이크를 사용할 수 있는 명시적인 허가를 요구함으로 이 문제를 해결해서, 사용자에게 일회성 또는 영구 액세스를 요청할 수 있다. WebRTC 애플리케이션은 사용자의 카메라 또는 마이크에 임의로 액세스 하거나 어떤 장치도 작동할 수 없다. 또한 마이크 또는 카메라를 사용할 때 클라이언트 UI는 사용자에게 카메라 또는 마이크가 현재 작동 중임을 명시적으로 보여줘야 한다. 아래와 같이, 크롬에서는 사용자의 미디어에 액세스 하는 탭에 빨간색 점의 형태를 취한다.


이 보안 보호의 철학은 사용자가 전화를 걸거나 받을 때 항상 정보에 입각한 결정을 내려야 한다는 것이다. 사용자는 아래에 대해서 둘 다 이해해야 한다.  


- 미디어에 대한 액세스를 요청하는 사용자 또는 대상

- 미디어가 어디로 가는지


WebRTC 스펙에서는, UI 표시기가 가려질 때 브라우저가 카메라와 마이크를 중지해야 한다고 명시한다. (예: window overlap) 비록 이것이 이상적이지만, 반드시 보장되는 것은 아니며 사용자는 주의를 기울여야 한다. 그러나 다행히도 이 추가 기능은 사용자가 기대하는 동작은 아닐 것이다.


화면 공유는 범위의 고유의 유연성으로 인해 추가적인 보안 고려 사항을 도입한다. 사용자는 자신이 공유하고 있는 정보의 범위를 즉시 알지 못할 수 있다. 예를 들어, 사용자가 특정 화면을 단순히 공유하고 있다고 착각하고 있을 때, 실제로 전체 화면을 보여주고 있을 수도 있다. 이는 사용자가 초기 화면 공유 설정을 올바르게 설정하지 못했거나 사용자가 단순히 공유하고 있는 내용의 범위를 잊어버린 결과일 수 있다.


4.3. Media Encryption & Communication Security

실시간 통신 애플리케이션이 보안 위험에 노출되는 여러 가지 방법이 있는데, 특히 주목할만한 것은 암호화되지 않은 미디어 또는 데이터를 전송 시 중간에서 가로채는 것이다. 브라우저-브라우저 또는 브라우저-서버 통신에서 발생할 수 있으며, 제 3자가 전송된 모든 데이터를 몰래 볼 수 있다. 그러나 암호화에 의한 통신은, 도청자가 통신 내용을 파악하는 것을 불가능하게 만든다. 비밀 암호 키에 액세스 할 수 있는 당사자만 통신 스트림을 해석할 수 있다.


암호화는 WebRTC의 필수 기능으로 시그널링 메커니즘을 포함한 모든 구성 요소에 적용된다. 결과적으로 WebRTC를 통해 전송되는 모든 미디어 스트림은 표준화된 잘 알려진 암호화 프로토콜을 통해 안전하게 암호화된다. 사용되는 암호화 프로토콜은 채널 유형에 따라 다른데, 데이터 스트림은 데이터그램 전송 계층 보안(DTLS)을 사용하여 암호화되고 미디어 스트림은 SRTP(Secure Real-Time Transport Protocol)를 사용하여 암호화된다.


4.3.1. DTLS: Datagram Transport Layer Security

WebRTC는 DTLS(Datagram Transport Layer Security)를 사용하여 정보(특히 데이터 채널)를 암호화한다. RTCDataChannel을 통해 전송되는 모든 데이터는 DTLS를 사용하여 보호된다.


DTLS는 WebRTC를 지원하는 모든 브라우저에 내장된 표준화된 프로토콜이며, 웹 브라우저, 이메일 및 VoIP 플랫폼에서 정보를 암호화하기 위해 지속적으로 사용되는 프로토콜 중 하나이다. 브라우저에 내장되기 때문에, 사용자는 별도의 사전 설정이 필요하지 않다. 다른 암호화 프로토콜과 마찬가지로 도청 및 정보 조작을 방지하기 위해서 설계되었다. DTLS는 비대칭 암호화 방법, 데이터 인증 및 메시지 인증과 함께 완전한 암호화를 제공하는 프로토콜인 스트림 지향 TLS를 모델로 한다. TLS는 HTTPS와 같은 프로토콜의 목적을 위해 사용되는 웹 암호화에 대한 표준이다. TLS는 TCP의 신뢰할 수 있는 전송 메커니즘을 위해 설계되었지만 VoIP 앱(및 게임 등)은 일반적으로 UDP와 같은 신뢰할 수 없는 데이터그램 전송을 사용한다.


DTLS는 SSL의 파생물이므로 모든 데이터는 표준 SSL 기반 연결을 사용하는 것만큼 안전한 것으로 알려져 있다. 사실, WebRTC 데이터는 웹상의 모든 표준 SSL 기반 연결을 통해 보호되므로, WebRTC는 거의 모든 서버 계약(?)에서 피어 사이에 종단 간(엔드 투 엔드) 암호화를 제공한다.


4.3.1.1. DTLS over TURN

모든 WebRTC 통신의 기본 옵션은 설정 단계에서 시그널링 서버를 지원하는 두 브라우저 간의 직접 P2P 통신이다. P2P 암호화는 비교적 쉽게 예상할 수 있지만, P2P 통신 방법이 불가능한 경우에는, WebRTC는 TURN 서버를 경유하는 통신 방법을 선택하게 된다. TURN 통신 중에 미디어는 품질 저하와 지연 시간 증가를 겪을 수 있지만, P2P 통신이 불가능한 경우에도, WebRTC 애플리케이션이 작동할 수 있도록 "다른 모든 것이 실패할 경우"에 대한 마지막 방법을 제공한다. 그래서, 우리는 TURN 서버를 사용할 때 암호화된 통신을 고려해야 한다.


하지만, 통신방식에 상관없이 전송된 데이터는 종단점에서 암호화되는 것으로 알려져 있다. TURN 서버의 목적은 단순히 통신 당사자(피어) 간 WebRTC 데이터를 전달해주는 역할뿐이며, 라우팅 목적으로 WebRTC 패킷의 UDP 계층만 구문 분석한다. 서버는 패킷을 라우팅 하기 위해 응용 프로그램 데이터 계층을 디코딩하지 않으므로 DTLS 암호화에 전혀 관여하지 않는다. (관여할 수도 없다.)


결과적으로, 암호화를 통해 수행되는 보호는 TURN 서버를 통한 WebRTC 통신 중에 손상되지 않으며, TURN 서버는 피어가 주고받는 정보를 중간에서 이해하거나 수정할 수 없다.


4.3.2. SRTP: Secure Real-time Transport Protocol

기본적인 RTP에는 내장된 보안 매커니즘이 없으므로, 전송된 데이터의 비밀을 보호하지 않는다. 대신 외부 메커니즘에 의존하여 암호화를 제공한다. 사실, 암호화되지 않은 RTP의 사용은 WebRTC 스펙에 명백히 금지되어 있다.


WebRTC는 미디어 스트림 암호화를 위해서 (DTLS 대신에) SRTP를 사용하는데, SRTP는 DTLS 보다 상대적으로 가벼운 옵션이다. 사양은 호환되는 모든 WebRTC 구현이 RTP/SAVPF (RTP/SAVP 위에 구축된)를 지원하도록 요구한다. [9] 그러나 실제 SRTP 키 교환은 처음에는 DTLS-SRTP로 엔드 투 엔드를 수행하여 모든 MiTM 공격을 탐지할 수 있다.


4.3.3. Establishment of a secure link

철수와 영희가, WebRTC 응용 프로그램에서 새로운 호출을 설정하는 과정을 단계별로 살펴보자. 한쪽(철수)은 다른 쪽(영희)에게 전화를 걸면 호출 절차가 시작되고, 시그널링 프로세스는 양 당사자(철수와 영희) 사이에 관련 메타데이터를 교환한다.


초기 ICE 점검이 완료되면, 두 피어가 하나 이상의 보안 채널을 설정하기 시작한다. 처음에는 ICE 프레임워크에서 설정한 모들 채널에서 DTLS 핸드셰이크가 수행된다. 데이터 채널의 경우 암호화에 간단한 DTLS가 사용되므로 이 단계만으로도 충분하다. 그러나 미디어 채널의 경우 추가 조차가 취해진다.


DTLS 핸드셰이크가 완료되면 키가 전달되어 미디어 채널용 SRTP 키에 사용된다. 이 단계에서 양 당사자는 악의적인 제삼자에게 알려지지 않은 키로 보안 데이터 및 미디어 채널 세트를 공유한다는 것을 알고 있다.


References: [10]


4.3.4. DTLS-SRTP vs SDES

미디어 트래픽 세션의 보안 매개 변수를 협상하려면 SRTP가 키 관리 프로토콜과 상호 작용해야 한다. 이 프로토콜은 설정되지 않았으며 작업에 대해 가능한 여러 옵션을 제공한다. 이러한 두 가지 옵션은 SDES와 DTLS-SRTP이다.


멀티미디어 통신에 관여하는 시그널링(SIP, HTTP) 및 미디어(RTP)는 독립적으로 보호될 수 있다는 점에 주목할 필요가 있다.


SDES

SDES는 미디어 스트림에 대한 SDP 보안 설명을 나타내며, WebRTC가 선호했던 옵션이었다.


SDES 내에서 SRTP 세션을 설정하는 데 사용되는 보안 매개 변수와 키는 SDP 속성의 형태로 일반 텍스트로 교환된다. SDP가 시그널링 평면(?)에 의해 통신되므로, 이러한 시그널링 메시지에 대한 암호화가 추가로 적용되지 않는다면, 도청하는 제삼자가 SDES 암호화 데이터의 키를 얻을 수 있다. 즉, 시그널링 평면(?)의 암호화를 위해 특별히 추가적인 암호화 프로토콜을 사용해야 한다. 이에 대한 선택 중 하나는 TLS를 사용하는 것이다.


그러나 시그널링과 미디어를 독립적으로 확보하면 미디어 사용자가 시그널링 사용자와 다르다는 상황을 초래할 수 있다. 이러한 보장을 제공하기 위해서는 암호화 바인딩이 필요하다. DTLS-SRTP는 이를 제공하는 메커니즘 중 하나이지만 SDES는 그렇지 않다.


오늘날에도, VoIP 네트워크에서 대부분의 RTP 트래픽이 보안되지 않고 있는 것은 사실이다. 실제로 암호화는 고객이 예산을 충족하기 위해 일반적으로 공급업체에 제거하도록 요청하는 가장 첫 번째 기능 중 하나이다. 보안이 설정된 경우 대부분의 배포는 방금 언급한 대로 신호 평면 보안에 크게 의존하는 SDES를 활용한다.


DTLS-SRTP

반면에 DTLS-SRTP는 시그널링 평면이 아닌 미디어 평면을 통해 키를 교환한다. 이러한 차이의 결과로 SRTP 미디어 채널이 SDES의 경우와 마찬가지로 SDP 메시지 교환을 통해 비밀 암호키를 공개할 필요가 없다.


WebRTC 스펙에서 [9] 키 관리를 위해 DTLS-SRTP를 지원해야 한다고 주장한다. 또한 기본 및 기본 방식으로 지정되며, 다른 주요 관리 체계에 대한 규정이 없다. 즉, 다른 계획들은 전혀 지원되지 않을 수도 있다.


DTLS-SRTP 및 SDES 모두에 대한 피어 광고 지원으로부터 제공 또는 호출을 수신하는 경우, 시그널링의 보안 여부에 관계없이 DTLS-SRTP를 선택해야 한다.


The Debate

일반적으로 DTLS-SRTP는 WebRTC 미디어의 암호화를 위한 필수적이고 기본 선택이어야 한다는 것이 인정된다. 의문이 드는 것은 역호환성을 제공하기 위해 SDES와 같은 다른 메커니즘을 사용해야 하는지 여부이다.


호환성 관점에서 Google의 Chrome 브라우저는 SDES와 DTLS-SRTP를 모두 지원하지만 Mozilla의 Firefox는 DTLS-SRTP만 구현한다.

References: [11][12]


4.3.5. A Weakness in SRTP

SRTP는 RTP 패킷의 페이로드만 암호화하며, 헤더에 대한 암호화는 제공하지 않는다. 그러나 헤더에는 비밀을 유지하는 것이 바람직할 수 있는 다양한 정보가 포함되어 있다.


RTP 헤더에 포함된 그러한 정보 중 하나는 포함된 미디어 데이터의 오디오 레벨이다. 효과적으로, SRTP 패킷을 볼 수 있는 사람은 누구나 사용자가 주어진 시간에 말하고 있는지 아닌지를 알 수 있다. 비록 미디어의 내용 자체가 도청하는 사람들에게는 비밀로 남아 있지만, 이것은 여전히 무서운 전망입니다. 예를 들어, 법 집행 관계자들은 사용자가 알려진 나쁜 사람과 통신하고 있는지 여부를 결정할 수 있다.


4.4. Web-Based Peer Authentication

& Identity Management

사용자는 상대 피어의 신원을 확인할 수 있는 것이 바람직하다. 즉, 사용자는 자연스럽게 자신이 대화하는 상대방에게 자신은 사기꾼이 아니라고 말할 수 있어야 한다.


시그널링 서버는 사용자의 신원을 주장하는 데 어느 정도 도움이 될 수 있지만, 시그널링 서버 자체는 신뢰할 수 없다. 그래서, 우리는 시그널링 서버와 독립적으로 상대방에 대한 인증을 수행할 수 있어야 한다. 이것은 IDP를 통해 가능하다.



Facebook Connect, BrowserID(Mozilla 제공), OAuth(Twitter 제공) 등 많은 웹 기반 ID 제공자(IdP)가 최근 웹에서 보편화되었다. 이러한 IdP의 작동원리는 단순히 ID 제공자의 권한으로 다른 서비스 또는 사용자에게 자신의 신원을 확인하는 것이다. 만약 사용자가 페이스북에 계정을 가지고 있다면, 페이스북의 IdP인 Facebook Connect를 사용하여 자신이 누구인지 다른 사람에게 증명할 수 있다. 이를 통해 사용자는 다른 서비스에 대한 인증을 "신뢰할 수 있는" 서비스로 기본 계정에 연결할 수 있다. Note that in this case the level of "trust" that an Identity Provider possesses is subjective to the end-point user or service, and is often largely tied to user base and reputation across the World Wide Web.

이 경우 아이덴티티 제공자가 소유한 "신뢰"수준은 엔드 포인트 사용자 또는 서비스에 주관적이며 종종 월드 와이드 웹의 사용자 기반 및 명성에 크게 묶여 있습니다.


각 IdP의 구현체들은 오픈 소스 표준에 기반하지 않고 회사마다 다른 독립적인 개발로 인해 다를 수 있지만, 기본적인 원칙과 기능은 본질적으로 동일하다. IdP는 시그널링 서버에 대한 인증을 제공하지 않으며, 오히려 사용자(및 프로세스를 통한 브라우저)에 대한 인증을 제공한다. 또한, WebRTC는 어떤 서비스를 사용해야 하는지에 대한 요구사항을 제시하지 않으며, 활용되는 서비스는 웹 애플리케이션의 구현을 기반으로 한다.


웹 애플리케이션(호출 사이트)은 이 인증 프로세스와 무관하므로 브라우저가 인증 프로세스에 대한 입력을 안전하게 생성하고 웹 애플리케이션에 출력을 안전하게 표시하는 것이 중요하다. 이 프로세스는 웹 응용 프로그램에 의해 변조되거나 잘못 전달되어서는 안 된다.


4.5. IP Location Privacy

ICE 사용의 부작용 중 하나는 상대방이 당신의 IP 주소를 학습할 수 있다는 것이다. IP주소는 글로벌 기관에 공개적으로 등록되면, 특정 피어의 위치와 같은 세부 정보가 공개할 수 있다. 이것은 자연스럽게 피하고 싶어 하는 동료에게 부정적인 영향을 미칠 수 있다.


WebRTC는 이러한 정보를 배우고자 하는 악의적인 웹 사이트로부터 사용자를 보호하기 위한 목적으로 설계되지 않았다. 일반적으로 이러한 사이트는 HTTP 트랜잭션에서 최소한 사용자의 서버 반사 주소를 학습한다. 서버에서 IP 주소를 숨기려면 클라이언트의 명시적 개인 정보 보호 메커니즘이 필요하며, 이 문서의 범위를 벗어난다.


그러나 WebRTC는 웹 애플리케이션이 사용자와 협력하여 사용자의 IP 주소를 통화의 다른 쪽에서 숨길 수 있도록 하는 수많은 메커니즘을 제공한다. 이 메커니즘들은 차례로 자세히 설명될 것이다.


사용자가 전화를 받기로 결정할 때까지 JS가 ICE 협상을 억제할 수 있는 메커니즘을 제공하는 WebRTC 구현이 필요하다. 이 조항은 최종 사용자가 통화에 응답하지 않기로 선택한 경우 피어가 자신의 IP 주소를 학습하지 못하도록 하는 데 도움이 됩니다. 이것은 사용자가 온라인 상태인지 아닌지를 동료들에게 숨기는 부작용이 있다.


두 번째 조항은 어떤 구현체라도 호출 앱의 자바스크립트가 TURN 후보들만 사용됨을 나타내는 메커니즘을 제공한다는 것이다. 이렇게 하면 피어가 자신의 IP 주소를 전혀 학습하지 못하게 할 수 있습니다.


게다가, 호출 앱은 기존 통화를 재구성하여 비턴 후보를 추가하는 메커니즘이 있다. 기존 조항과 함께 착신 통보 시 ICE 협상을 즉시 시작할 수 있어 지연을 줄일 수 있을 뿐 아니라 사용자의 IP주소가 응답을 결정할 때까지 공개되지 않도록 했다. 이를 통해 사용자는 통화하는 동안 자신의 IP 주소를 완전히 숨길 수 있습니다.


References: [13]



4.6. Signalling Layer

시그널링 프로토콜은 WebRTC 기술 스펙에 정의가 되어 있지 않다. 그래서, 시그널링 레이어의 암호화 과정은 명백하게 선택된 시그널링 프로토콜에 의존한다. 시그널링 프로세스의 개방적인 특성 때문에, 이 문서에서는 가장 일반적인 프로토콜인 SIP (Session Initiation Protocol)에 초점을 맞추고 간략하게 설명하겠다.


SIP는 전화 통화의 VoIP 통신에 사용되는 많이 사용되는 표준이다. 그러나 SIP는 HTTP와 SMTP의 파생된 기술로, 둘 다 정기적으로 이용되는 프로토콜이다. 일반 텍스트 메시지를 사용하여 정보를 교환하므로, 어떤 악의적인 당사자가 네트워크를 도청하여 SIP 메시지를 중간에서 가로챌 수 있다. 공격자가 사용자의 중요한 정보를 읽을 수 있는 경우 이 정보를 사용하여 사용자를 해킹할 수 있다. 그리고 공격자가 운영자의 네트워크에 접근할 수 있다면, WebRTC 통신 내용을 해독할 수도 있다. [14]


SIP는 일반 텍스트로 전송되므로, 결정된 공격자가 SIP 메시지를 가로채는 것은 매우 간단하다. 다음에 일어날 일은 공격자의 상상력에 맡겨지지만, 메시지 본문이나 헤더의 내용이 변조된다는 점에서 만일의 사태를 상상하는 것은 어렵지 않다. 공격자가 INVITE 메시지를 가로채면 자신의 IP 주소를 반영하기 위해 FROM 헤더를 변경할 수 있다.


References: [10] [15]


4.6.1. SIP Vulnerabilities

SIP는 멀티미디어 통신 세션을 제어하고, 신호를 보내기 위한 통신 프로토콜이며 전화 통화를 설정하기 위한 목적으로 VoIP 기술에 자주 사용된다. 이와 유사하게 WebRTC 서비스에서도 시그널링 목적으로 여러 옵션 중 하나로 사용할 수 있다. 그러나 SIP 메시지는 종종 일반 텍스트로 전송된다. 이는 자연스럽게 다수의 잠재적 공격 대상이 되기 때문에, 우리는 이 부분에 대해 더 자세히 검토할 것이다.


SIP Flow

통화를 설정하는 과정에서 사용자의 브라우저(또는 사용자 에이전트)는 중앙 등록부에 등록된다. 이러한 등록은 전통적인 VoIP에서 필요한 과정으로, 원격 당사자를 찾고 연락할 수 있는 수단을 제공하기 위해서이다.


상대방(Bob)이 통화를 시작하고 싶을 때, 그는 중앙 프록시 서버(시그널링 서버)를 통해 INVITE 메시지를 보낸다. 시그널링 서버는 이러한 메시지를 릴레이하고 다른 사용자를 찾을 수 있는 수단을 제공한다. 서버는 이 조회 프로세스 중에 DNS 사용과 같은 여러 가지 방법으로 최종 사용자를 찾으려고 시도할 수 있다.


Registration Hijacking

시그널링 서버에 브라우저를 등록하는 과정은, 사용자의 연락처를 알리는 데 사용되며 사용자의 장치가 통화를 수락한다는 의미이다. 그러나 과정은 악의적인 누군가가 하이재킹 공격을 수행할 수 있는 가능성을 제공한다.


등록 메시지 교환 시 사용자의 IP 주소가 포함된 "Contact:" 필드가 포함된다. 시그널링 서버가 수신된 통화를 처리할 때마다 사용자 이름(또는 전화번호)이 등록된 IP 주소와 매칭 되고, 이에 따라 INVITE가 전달된다. 이러한 등록은 주기적으로 업데이트되어 기록이 최신 상태로 유지되도록 한다.


SIP 메시지는 항상 일반 텍스트로 전송되므로 공격자가 이러한 등록 메시지의 내용을 가로채서 해킹하는 일이 가능하다. 가로채기 후에 적절한 도구(SiVus Message generator 등)를 사용하여 유사한 SIP 정보를 생성할 수 있으며, 사용자의 실제 IP 주소가 공격자의 IP 주소로 대체된다. 그런 다음 공격자는 실제 사용자를 비활성화하고 이 정보를 주기적으로 보내 수신되는 모든 통화를 자신에게 돌리기만 하면 된다.


공격자가 합법적인 사용자를 비활성화하기 위해 사용할 수 있는 방법은 여러 가지가 있다


- 사용자 장치에 대한 DoS 공격 수행

- 사용자 등록 취소(여기에서는 다루지 않는 또 다른 공격)

- 적법한 사용자의 등록 요청을 무시하기 위해 공격자가 더 짧은 시간(예: 15초마다)에 반복적으로 REGISTER 요청을 보내는 등록 경쟁 조건을 생성


이것은 모두 WebRTC 시그널링 서비스에 대한 진정한 위험이다.


SIP의 구현은 메시지 내용의 무결성을 지원하지 않기 때문에 수정 및 재생 공격은 탐지되지 않으며 실행 가능한 공격이다. 공격자가 원하는 대로 메시지를 다시 캡처, 수정 및 재생할 수 있으므로 서버가 사용자 등록 인증이 필요한 경우에도 이 공격이 작동한다.


이 공격은 SIPS(TLS를 통한 SIP)를 구현하여 SIP 요청 및 응답 인증(무결성 보호 포함)을 통해 억제할 수 있다. 실제로 SIPS를 사용하고 응답을 인증하면, 도청 및 메시지 또는 사용자 사칭을 비롯한 많은 관련 공격을 억제할 수 있다.


Other possible attacks

- MiTM attack : 공격자가 초기 SIP 메시지를 가로챌 수 있는 경우 MiTM 공격을 수행할 수 있다.

- Replay attack : 캡처된 패킷이 악의적인 당사자에 의해 서버로 재생되어 서버가 원래 호출 대상에 전화를 걸 수 있다. 즉, 이것은 당사자가 이미 수신한 것과 동일한 두 번째 원치 않는 호출 요청의 형태를 취할 수 있다. 공격자는 IP 정보가 신호 패킷에 포함되지 않기 때문에 호출 당사자가 아니다..(?)

- Session hijacking : 웹 서버는 상태를 저장하지 않으며, 각 요청은 별도의 세선을 제공한다. (지속적으로 인증을 요청해야 하는 필요성을 감소시킨다.) 인증을 위한 쿠키이지만 세션 ID가 포함된 데이터 파일일 뿐이다.

- 이러한 쿠키는 웹 서버에서 초기 액세스 시 브라우저로 전송된다. 쿠키를 가로채서 복사할 경우 이미 진행 중인 세션에 대한 접근이 허용될 수 있다. 이를 완화하기 위해 대부분의 사이트는 사용자 IP 주소와 타임스탬프가 포함된 알고리즘을 사용하여 쿠키를 생성하여 고유 식별자를 만든다.


Encryption

시그널링이 공격자가 목표로 삼을 수 있는 유혹적인 공격 목표를 제공하는 것처럼 보일 수 있지만, 모든 것이 손실되지는 않는다. 미디어 스트림 외에도 시그널링 전달 계층도 암호화될 수 있다. 이러한 암호화된 옵션 중 하나는 OnSIP로, TLS로 암호화된 웹소켓 연결과 함께 보안 웹소켓(ws:// 대신 wss://)을 통해 SIP를 사용한다.


비록 이 문서의 범위 밖이지만, 다른 시그널링 전달 기술들도 비슷하게 TLS를 사용하여 웹소켓 또는 웹 트래픽을 암호화할 수 있다. 모든 암호화와 마찬가지로, 제삼자가 비밀 암호키를 모르면 통신의 일반 텍스트 내용을 읽을 수 없다. 이는 응용 프로그램 프로그래머가 이에 적용할 수 있도록 암호화된 신호 전달 방법을 구체적으로 구현해야 한다는 점에 유의해야 하지만 위의 공격 벡터의 위험을 제거하는데 도움이 됩니다.


References: [16]


4.7. Additional Security Topics


Viewpoint of the Telecom Network

WebRTC를 지원을 제공함으로써 통신 네트워크는 보안 위험 증가에 노출되지 않을 것으로 합리적으로 예상해야 한다. 그러나 소비자의 손에 있는 기기나 소프트웨어는 악의적인 당사자에 의해 손상될 수밖에 없다.


이러한 이유로 신뢰할 수 없는 (사용자가 사용하는) 장치로부터 수신된 모든 데이터를 검증해야 하며, 통신 네트워크는 클라이언트에 전송된 모든 데이터가 악의적인 장치에 의해 획득될 것이라고 가정해야 한다.


이 두 가지 원칙을 채택함으로써, 통신 제공 업체는 시스템을 손상시킬 수 있는 실수로부터, 소비자를 보호하기 위해 모든 합리적인 시도를 해야 한다.


Cross-site scripting (XSS)

"Cross-site scripting"은 일반적으로 웹 애플리케이션(브라우저 보안 위반을 통한 웹 브라우저 등)에서 발견되는 취약성으로, 공격자는 다른 사용자가 보는 웹 페이지에 클라이언트측 스크립트를 주입할 수 있다. 공격자가 "Cross-site scripting" 취약성을 사용하여 "same origin policy"같은 액세스 제어를 우외할 수 있다.


이러한 영향은 취약한 사이트에서 처리하는 데이터의 민감도와 사이트 소유자가 구현하는 보안 완화의 특성에 따라 사소한 문제가 될 수도 있고, 또는 심각한 보안 위험에 이르게 할 수도 있다.


WebRTC에 액세스 하는 기본 방법은 HTML5 지원 브라우저를 사용하므로, cross-site scripting 또는 cross-domain attacks, 웹소켓 사용, 아이프레임 보안 및 기타 문제로부터 민감한 데이터를 보호하는 구체적인 보안 고려사항이 있다. 클라이언트 소프트웨어는 사용자에 의해 제어되고 브라우저는 대부분의 경우 보호된 환경에서 실행되지 않기 때문에 WebRTC 클라이언트가 손상될 수 있는 추가적인 가능성이 있다. 이것은 클라이언트로 전송된 모든 데이터가 노출될 수 있다는 것을 의미한다.


References: [17]


5. Comparison with competing/similar technologies

WebRTC의 비교 보안에 대한 검토는 경쟁사의 보안을 고려하지 않고는 타당하지 않을 것이다. WebRTC의 경우, 웹 기반 통신 분야의 경쟁은 자체적인 이슈를 가지고 있다.


이 섹션에서는 경쟁 RTC 기능을 제공하는 WebRTC와 다른 플랫폼의 비교해서 장단점을 살펴볼 것이다.


우리가 살펴볼 수 있는 몇 가지 플랫폼은 다음과 같지만, 아직 처음 검토할 플랫폼은 미정이다. 널리 사용되고 있지만, 추가 설치 프로세스는 장벽이 될 수 있다.


- Flash

- Silverlight

- Jabber

- SIP


6. Secure design practices

WebRTC는 보안에 의해 만들어진다. 하지만, 맹목적으로 WebRTC 보안 기술에 의존하기보다는, 보안을 염두에 두고 의식적으로 보안 코딩하는 것이 좋다. 이 섹션에서는 보안을 강화하기 위해 따를 수 있는 코딩 방법에 대해 설명한다. 특히, 이러한 관행은 은행 기관, 의료 기관 또는 기밀 기업 정보와 같은 민감한 정보를 취급할 것으로 예상되는 조직에 적용될 수 있다.


Secure Signalling

앞서 언급했듯이, WebRTC는 시그널링 프로세스에 제약을 두지 않으며, 개발자가 자신이 선호하는 방법을 결정하도록 한다. 이를 통해 애플리케이션 요구 사항을 구현할 때 유연성이 허용되지만, 특정 시그널링 프로토콜과 관련된 위험이 있을 수 있다.


시그널링 통신 암호화와 같은 추가 보안을 제공하는 시그널링 프로토콜을 구현하는 것이 바람직하다. 기본적으로, 시그널링 프로세스는 어떤 암호화도 포함하지 않을 수 있으며, 이는 모든 교환된 신호 전달 메시지의 내용을 도청으로부터 노출될 수 있다. 따라서 보안/기밀성에 초점을 맞춘 애플리케이션은 시그널링 전달 계층이 SIPS, OpenSIP, HTTPS 또는 WSS와 같은 보안 프로토콜을 통해 구현되도록 해야 한다.


Authentication and peer monitoring

기본 WebRTC 앱은 통화를 수행하기 위해 사용자의 ID만 필요하며, 서비스 자체의 관점에서 인증이 수행되지 않는다. 사용자가 통화에 참여하기 전에 사전 등록 또는 인증을 요구하는 것이 바람직하다. 인증되지 않은 사용자는 세션이 닿지 않는 곳에 보관하여 신뢰할 수 없는 당사자에 대한 액세스를 제한해야 한다.


미디어 연결은 P2P이기 때문에 미디어 콘텐츠(오디오 및 비디오 채널)는 쌍방향으로 피어 간에 직접 전송된다. 따라서 시그널링 서버는 통신 중인 피어의 수를 유지하므로, 통화 세션에서 의심스러운 피어의 추가를 지속적으로 모니터 할 수 있다. 시그널링 서버에 실제로 존재하는 피어의 수가 WebRTC 페이지에서 상호 작용하는 피어 수보다 많다면 누군가가 비밀리에 도청하고 있으므로 강제로 세션 액세스로부터 종료해야 한다.


Permission Requests

사용자가 메시지를 읽지 않고, 의식적으로 권한 요청이나 유사한 대화 상자에 동의하는 경우가 많다. 이는 사용자가 실제로 의도하지 않은 권한을 웹 애플리케이션에 부여할 위험이 있다.


이러한 동작 자체는 쉽게 처리할 수 없지만, 한 가지 해결책은 애플리케이션이 요청하는 권한을 페이지에 명확하게 상세히 기술하는 것이다. 이러한 애플리케이션은 사용자의 개인 정보를 최우선으로 한다.


Man-In-The-Middle

악의적인 당사자가 MiTM 공격을 설정하는 데 성공하는 경우, 일반적으로 이를 발견하거나 대처할 수 있는 쉬운 설루션이 없습니다. 공격에는 경고가 없고, 통신은 정상적으로 진행되도록 허용되기 때문이다. 이런 공격을 예상하지 못했다면 눈에 띄지 않게 공격이 계속될 가능성이 높다.


그러나 의심스러운 중계가 없는지 미디어 경로를 정기적으로 모니터링함으로써 MiTM 공격에 대한 작은 조치를 취할 수 있다. 이것은 위에서 언급한 것과 같이 암호화된 시그널링 서버와 결합되어야 한다.


Screen Sharing

어느 정도의 화면 공유 기능을 제공하는 애플리케이션에는 사용자를 보호하기 위한 경고가 있어야 한다. 위에서 논의된 바와 같이, 사용자는 화면이 공유되는 정도를 인지하지 못할 수 있다. 이러한 문제는 적절한 정보를 제공하기 위해 적절하게 설계된 애플리케이션으로 대체되어야 한다.


예를 들어, 화면 일부를 스트리밍 하기 전에 사용자에게 적절하게 알려주고, 중요한 정보가 포함된 화면을 닫을 수 있게 안내해야 한다.


A Fallback

최종 예비 조치로, 우리는 활성 통화 세션이 승인되지 않은 당사자에 의해 훼손되는 상황을 상상할 수 있다. 이러한 방식으로 통화가 손상된 것으로 확인되면, WebRTC 가능 페이지를 사용하여, 통화를 차단할 수 있는 권한을 웹 애플리케이션 서버의 권한 내에 있어야 합니다.(?)


References: [18]


7. Conclusion

스마트폰과 모바일 기기의 현대 시대에 사람들은 그 어느 때보다도 더 많이, 그리고 우리가 이전에 알고 있던 것보다 훨씬 더 개인적인 방법으로 의사소통하고 있다. 특히 암호화는 주요 기업 해킹 스캔들에 대한 인식이 높아지고 정부의 통신 도청이 널리 퍼지면서 최근 몇 년 동안 큰 화두가 되었다.


그 결과 이러한 조직에 대한 사용자의 불신이 급격히 증가했으며 크게 개선된 보안 조치를 이행하는 데 있어 무기가 요구되고 있다. 최종 사용자가 원하는 것은 자신의 개인 데이터가 비밀로 유지된다는 것을 아는 것이다.


WebRTC는 보안 영역에서 대부분의 VoIP 서비스에 비해 큰 장점을 가지고 있다. 지금까지 대부분의 서비스는 보안을 선택사항으로 취급해왔는데, 이는 대부분의 최종 사용자는 암호화 없이 VoIP 통화를 사용한다는 것을 의미한다. 특히 대기업은 사용자나 처리하는 데이터의 가치를 제대로 고려하기보다는 개발 비용을 줄여서 비용을 절감하는 방식을 택하고 있다. 그러나 WebRTC는 암호화되지 않은 통신을 금지함에 따라, 사용자들은 그들의 개인 정보가 안전하고 비공개로 유지된다는 것을 확신할 수 있다.


보안을 염두에 두고 설계된 WebRTC는 모든 주요 영역에서 중요한 보안 개념을 시행하거나 권장한다. 따라서, 애플리이션을 보안을 구축할 뿐만 아니라, 개발자가 보안을 진지하게 받아들이도록 권장한다.


보안 통신에 대한 이러한 강한 집중의 결과로, WebRTC는 현재 가장 안전한 VoIP 솔루션 중 하나로 간주된다. 기본적으로 암호화를 갖는 주요 전제는 통화는 항상 비공개로 한다는 것이다. 보안 및 암호화는 더 이상 선택 기능으로 간주되지 않는다. 그리고 모든 것을 마무리하기 위해 WebRTC는 모든 사람이 무료로 사용할 수 있으므로 개발자가 다음 애플리케이션을 구축할 수 있는 유혹적이고 안정적인 프레임워크를 제공한다.


가까운 미래에 사용자에게 크게 향상된 보안을 제공하는 점점 더 많은 통신 서비를 기대할 수 있다. WebRTC는 그러한 책임을 주도하는 핵심 기술로 선두를 달리고 있다.


References: [19]


8. Bibliography

1. RTCPeerConnection API Reference.
developer.mozilla.org. Accessed on 2015-07-28.

2. Brief Introduction to RTCPeerConnection API.
High Performance Browser Networking. Accessed on 2015-07-28.

3. SDP for the WebRTC.
tools.ietf.org. Accessed on 2015-07-28.

4. After signaling: using ICE to cope with NATs and firewalls.
html5rocks.com. Accessed on 2015-07-28.

5. Getting Started with WebRTC - Security.
html5rocks.com. Accessed on 2015-07-28.

6. WebRTC Security - Same Origin Policy.
tools.ietf.org. Accessed on 2015-07-28.

7. Security Considerations for WebRTC.
tools.ietf.org. Accessed on 2015-07-28.

8. Attack of the week: Datagram TLS.
blog.cryptographyengineering.com. Accessed on 2015-07-28.

9. Web Real-Time Communication (WebRTC): Media Transport and Use of RTP.
tools.ietf.org. Accessed on 2015-07-28.

10. The Foundation of WebRTC Security.
onsip.com. Accessed on 2015-07-28.

11. WebRTC MUST implement DTLS-SRTP but… MUST NOT implement SDES?.
webrtchacks.com. Accessed on 2015-07-28.

12. IETF-87 rtcweb agenda.
tools.ietf.org. Accessed on 2015-07-28.

13. Security Considerations for WebRTC.
www.ietf.org. Accessed on 2015-07-28.

14. WebRTC and Man in the Middle Attacks.
webrtchacks.com. Accessed on 2015-07-28.

15. Security in a SIP network: Identifying network attacks.
searchunifiedcommunications.techtarget.com. Accessed on 2015-07-28.

16. Two attacks against VoIP.
symantec.com. Accessed on 2015-07-28.

17. Security for WebRTC applications.
altanaitelecom.wordpress.com. Accessed on 2015-07-28.

18. WebRTC Security.
altanaitelecom.wordpress.com. Accessed on 2015-07-28.

19. Why WebRTC is the Most Secure VoIP Solution.
bloggeek.me. Accessed on 2015-07-28.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari