ChatLite
ChatLite 시작

종단 간 암호화와 전송 구간 암호화의 차이

작성 · 수정

거의 모든 앱이 암호화되어 있다고 말하지만, 그 말은 서로 매우 다른 보호를 뭉뚱그립니다. 어떤 것은 카페 와이파이의 낯선 사람이 메시지를 읽지 못하게 막습니다. 서비스를 운영하는 회사가 읽지 못하게 막는 것은 훨씬 적습니다. 이 글은 전송 구간 암호화와 종단 간 암호화를 구분하고, WebRTC 통화가 어디에 해당하는지 설명하며, 어떤 메신저에게든 던질 수 있는 질문을 알려 드립니다.

암호화는 열쇠를 누가 갖느냐의 문제입니다

암호화는 읽을 수 있는 데이터를 뒤섞어서 올바른 열쇠를 가진 사람만 되돌릴 수 있게 합니다. 그래서 유용한 질문은 암호화되어 있느냐가 아니라 각 단계에서 열쇠를 누가 가지고 있느냐입니다. 열쇠가 대화의 양 끝에만 있다면 중간에서는 아무도 읽을 수 없습니다. 중간의 누군가가 열쇠를 가지고 있다면, 나와 그 사이의 통신 구간이 모두 뒤섞여 있더라도 그 쪽은 데이터를 읽을 수 있습니다.

전송 구간 암호화: 길을 보호합니다

전송 구간 암호화는 두 지점 사이를 이동하는 데이터를 보호합니다. 예를 들어 내 브라우저와 웹사이트 사이입니다. 웹에서는 전송 계층 보안, 곧 TLS이며 자물쇠 아이콘과 https가 가리키는 것입니다. MDN은 TLS가 세 가지를 제공한다고 정리합니다. 암호화는 클라이언트와 서버 사이에서 주고받는 데이터가 전송 중에 암호화되어 공격자가 읽을 수 없게 합니다. 무결성은 공격자가 전송 중인 데이터를 들키지 않고 몰래 바꿀 수 없게 합니다. 인증은 클라이언트와 서버가 각자 자신이 주장하는 대상임을 증명할 수 있게 하며, 웹에서는 보통 서버만 자신을 증명합니다.

이는 큰 이점입니다. HTTPS는 내 브라우저와 서버 사이에 끼어들어 트래픽을 읽거나 바꾸려는 중간자에 대한 방어입니다. 보호되지 않은 채 데이터를 보내는 것보다 공용 와이파이에서 앱을 쓰는 일이 덜 위험한 주된 이유입니다.

하지만 연결 반대편의 서비스로부터 내용을 보호하지는 않습니다. TLS는 서버에서 끝나고, 서비스가 처리할 수 있도록 거기서 복호화됩니다. 서비스는 그 데이터를 저장하거나 검사하거나 직원에게 보여주거나 당국에 넘길 수 있으며, 이는 서비스 자체 규칙과 법에 달려 있습니다. 전송 구간 암호화는 이 부분에 대해서는 아무것도 보장하지 않습니다. 오가는 길이 안전했다는 것만 보장합니다.

종단 간 암호화: 내용을 보호합니다

종단 간 암호화(E2EE)는 다릅니다. 전자프런티어재단(EFF)은 이를 보낸 사람이 암호화하고 최종 수신자만 복호화할 수 있는 메시지라고 정의합니다. 다른 형태의 암호화는 제3자가 수행하는 암호화에 의존할 수 있고, 이는 그 제3자가 원본 데이터를 맡길 만큼 믿을 수 있어야 한다는 뜻이라고 설명합니다. E2EE는 암호화를 방해하거나 깨뜨릴 수 있는 당사자의 수를 줄입니다.

E2EE 메신저에서는 열쇠가 대화하는 사람들의 기기에 있습니다. 서버는 뒤섞인 데이터를 나를 뿐이며, 읽고 싶어도 강제를 받아도 읽을 수 없습니다. 강력한 성질이지만 대가가 있습니다. 서버가 내용을 읽어야 하는 기능, 예를 들어 서버 쪽 검색, 스팸 필터링, 새 기기에서의 기록 복구는 어려워집니다. 모든 기기와 열쇠를 잃으면 아무도 메시지를 복구해 줄 수 없습니다.

E2EE가 모든 것을 숨기지도 않습니다. 누가 누구와 언제 얼마나 자주 대화하는지 같은 메타데이터는 서비스에 보이는 경우가 많습니다. 메시지는 받은 사람이 복사하거나 캡처할 수 있고, 잠금이 풀린 휴대폰에서 읽힐 수도 있습니다. 또 E2EE는 올바른 상대와 대화할 때만 내용을 보호하므로, 일부 메신저는 안전 코드를 비교해 보게 합니다.

WebRTC 통화는 어디에 해당하나

브라우저 통화는 WebRTC라는 기술을 씁니다. WebRTC 보안 구조(RFC 8827)는 미디어 암호화를 의무로 정합니다. 모든 미디어 채널은 SRTP로, 모든 데이터 채널은 DTLS로 보호되어야 합니다. 두 브라우저 사이에서 직접 이어지는 통화에서는 그 암호화가 두 브라우저 사이에서 협상되고, 오디오와 비디오가 중간에서 복호화되지 않은 채 한쪽에서 다른 쪽으로 가므로 그 스트림에 대해서는 종단 간 암호화처럼 동작합니다.

두 가지 단서가 있습니다. 첫째, 통화는 브라우저 사이에 연결 정보를 전달하는 시그널링 서비스가 설정하며, 표준은 사용자가 별도의 경로로 열쇠 지문을 비교하지 않으면 이 서비스가 원칙적으로 중간자 공격을 할 수 있다고 경고합니다. 사용자에게 그렇게 하라고 요구하는 앱은 드뭅니다. 둘째, 릴레이 서버를 거쳐야 하는 통화도 경로상으로는 암호화되지만 릴레이는 트래픽을 나르는 또 하나의 당사자입니다. 요컨대 두 브라우저 사이의 암호화된 WebRTC 미디어는 좋은 출발이지만, 그것만으로 서비스 전체가 안전하다고 할 수는 없으며, 서비스가 다른 방식으로 보낼 수 있는 텍스트 메시지에 대해서는 아무것도 말해 주지 않습니다.

흔한 상황 비교

어떤 메신저에게든 물어볼 질문

  1. 앱은 그룹, 파일, 통화를 포함한 모든 종류의 메시지에 기본으로 종단 간 암호화를 쓰나요? 아니면 선택 모드에서만 쓰나요?
  2. 열쇠는 누가 가지고 있나요? 서비스가 내 기기 없이 열쇠를 재설정하거나 기록을 복원할 수 있다면 열쇠 관리의 일부를 서비스가 쥐고 있는 것입니다.
  3. 서비스는 무엇을 얼마나 오래 저장하나요? 오프라인 사용자를 기다리는 메시지, 백업, 로그는 저장되는 경우가 많습니다.
  4. 코드나 적어도 설계가 문서화되고 독립적으로 검토되었나요?
  5. 서비스는 어떤 메타데이터를 수집하나요?
  6. 개인정보 처리방침이 서비스가 읽을 수 있는 것과 없는 것을 분명하게 말하나요?

은행급 보안이나 군사급 암호화 같은 모호한 표현은 경계하세요. 이런 말은 알고리즘의 강도를 말할 뿐 열쇠를 누가 가졌는지는 말하지 않습니다. 믿을 만한 서비스는 자신이 볼 수 있는 것을 평이한 말로 밝힙니다.

알맞은 도구 고르기

건강, 돈, 법률 문제처럼 회사나 해커가 읽으면 곤란한 민감한 대화에는 기본으로 종단 간 암호화를 쓰는 메신저를 쓰세요. 일상적인 연락에는 전송 구간을 암호화하고 무엇을 저장하는지 분명히 밝히는 서비스로도 충분할 수 있지만, 기밀이 아닌 내용만 주고받는다고 생각하세요. 무엇을 쓰든 기기를 잠가 두고, 업데이트하고, 전달하는 내용에 조심하세요.

ChatLite에 대해

ChatLite는 자신의 위치를 분명히 밝힙니다. 트래픽은 전송 구간에서 암호화되고, 직접 WebRTC 연결은 브라우저 사이에서 암호화되며, 일부 메시지와 파일은 서버를 거치고 서버는 중계하는 내용을 기술적으로 읽을 수 있습니다. ChatLite가 현재 애플리케이션 수준의 종단 간 암호화를 제공하지 않기 때문입니다. 무엇이 어디에 저장되는지는 데이터 처리 페이지에 정리되어 있습니다.

참고 자료

이 글을 확인하는 데 쓴 공식 문서입니다. 문서는 각 운영 주체가 관리하며 바뀔 수 있습니다. 한국어 메뉴 이름은 버전과 언어 설정에 따라 다를 수 있으니, 화면의 이름과 다르면 비슷한 항목을 찾거나 공식 문서의 영어 이름을 참고하세요.

ChatLite의 현재 동작을 기준으로 검토한 날짜: .