TLS 대 종단간 암호화 완벽 비교

TLS(Transport Layer Security)는 기기와 서버 간 이동 중 데이터를 암호화한 후 도착 시 복호화합니다. 즉, 서버 운영자는 파일을 평문으로 읽을 수 있습니다. 종단간 암호화(E2EE)는 수신자만 보유한 키로 발신자 기기에서 콘텐츠를 암호화하므로 서버는 암호화되지 않은 데이터를 절대 볼 수 없습니다. 파일 전송에서 TLS는 네트워크 도청자로부터 보호하지만 제공업체 자체로부터는 보호하지 않습니다. E2EE는 둘 다 방어합니다. 브라우저의 자물쇠 아이콘은 어느 방식이 실제로 작동 중인지 알려주지 않습니다.

TLS가 실제로 보호하는 것

RFC 8446에서 표준화된 TLS 1.3은 모든 HTTPS 연결을 지원하는 프로토콜입니다. X25519 같은 곡선을 사용하는 ECDHE로 세션 키를 협상하고, X.509 인증서로 서버를 인증하며, AES-128-GCM 또는 ChaCha20-Poly1305로 HTTP 트래픽을 감싸줍니다. 커피숍 Wi-Fi 공격자나 요청을 읽으려는 ISP에 대한 탁월한 보호입니다.

TLS가 하지 않는 것은 로드 밸런서에서 종료된다는 점입니다. 일반 파일 공유 서비스에 3GB 동영상을 업로드하면, TLS는 엣지에서 복호화하고 평문 파일이 S3 버킷, 트랜스코딩 파이프라인, 아마도 ML 콘텐츠 스캔 작업을 거쳐 결국 수신자의 다운로드 스트림으로 갑니다. 서비스는 모든 단계에서 완전한 읽기 권한을 가집니다.

종단간 암호화의 시작과 끝

진정한 E2EE는 암호화 경계를 서버에서 엔드포인트로 이동합니다. 발신자의 브라우저 또는 클라이언트에서 대칭 키(일반적으로 AES-256-GCM)가 메모리 내에서 생성됩니다. 단 하나의 바이트도 기기를 떠나기 전에 파일이 청크 단위로 암호화됩니다. 암호문은 TLS를 통해 서버에 업로드되고, 서버는 불투명한 블롭을 저장합니다. 수신자는 별도 채널을 통해 복호화 키를 받습니다. 가장 일반적으로 # 기호 뒤의 URL 프래그먼트로, 브라우저는 이를 서버에 전송하지 않습니다.

이 모델에서 서버는 단순한 저장소 레이어입니다. 영장이 발부되거나, 데이터베이스 접근 권한이 있는 불량 직원이 있거나, 클라우드 제공업체가 디스크 스냅샷을 읽더라도 암호화된 바이트만 얻을 수 있습니다. 이것이 HexaTransfer가 사용하는 아키텍처입니다. AES-256-GCM을 사용하며, 전송별 키는 클라이언트 측에서 파생되고 오리진 서버로 전송되지 않습니다.

TLS 전용 대 종단간 암호화 비교

| 속성 | TLS 전용 전송 | 종단간 암호화 | |---|---|---| | 전송 중 암호화 | AES-128/256-GCM | AES-256-GCM(TLS 포함) | | 서버가 평문 확인 | 예 | 아니요 | | 키 위치 | 서버 관리 | 발신자 기기 | | 영장에 대한 보호 | 없음 | 강력함 | | 제공업체의 콘텐츠 스캔 | 가능 | 불가능 | | 키 분실 시 복구 | 제공업체가 도움 가능 | 데이터 복구 불가 | | 대표 서비스 | Google Drive, Dropbox | HexaTransfer, SwissTransfer E2EE 모드 |

키 교환의 실제 작동 방식

E2EE에서 어려운 부분은 암호화 방식이 아닙니다. AES는 25년간 안전함이 검증되었습니다. 어려운 부분은 서버가 보지 않고 발신자에서 수신자에게 키를 전달하는 것입니다. 파일 전송 서비스는 일반적으로 세 가지 패턴 중 하나를 사용합니다.

첫째는 URL 프래그먼트 방법입니다. 링크가 https://hexatransfer.com/d/abc123#key=xyz처럼 보이며, # 뒤의 모든 것은 브라우저에 남습니다. JavaScript가 로컬에서 읽고 복호화합니다. 둘째는 비밀번호 기반 암호화로, 발신자가 암호문을 선택하고 PBKDF2(RFC 8018) 또는 Argon2id를 600,000회 이상 반복 실행하며 Signal 또는 전화로 대역 외로 비밀번호를 공유합니다. 셋째는 libsodium의 crypto_box와 같은 라이브러리를 사용하는 공개 키 교환으로, 수신자가 X25519 공개 키를 게시합니다.

TLS 단독으로 충분한 경우

모든 파일에 E2EE가 필요한 것은 아닙니다. 언론인에게 보도자료를 공유하거나, 그룹 채팅에 밈을 보내거나, 공개 마케팅 PDF를 전송하는 경우에는 TLS 전용 서비스로 충분합니다. 처음부터 민감하지 않은 데이터이고, 제공업체가 읽어도 위험이 없습니다. 미리보기, 썸네일, 브라우저 내 편집 같은 편의 기능을 최적화하는 것이고, 이러한 기능은 근본적으로 서버 측 평문 접근이 필요합니다.

계산이 달라지는 경우는 의료 이미징(HIPAA 45 CFR 164.312(a)(2)(iv)의 DICOM 파일), PCI DSS 4.0 요구사항 3.5.1의 재무 명세서, 법적 증거 자료, 인수합병 문서, 또는 GDPR 제32조(개인정보보호법 제29조 포함)의 EU 개인 데이터가 포함된 경우입니다. "제공업체가 기술적으로 이것을 읽을 수 있다"는 것은 단순한 프라이버시 미학이 아니라 준수 문제입니다.

아무도 말하지 않는 메타데이터 격차

완벽한 E2EE에서도 서버는 메타데이터를 볼 수 있습니다. 업로드 타임스탬프, 파일 크기, 발신자와 수신자의 IP 주소, 사용자 에이전트 문자열, 전송 기간이 포함됩니다. 위협 모델에 트래픽 분석이 포함된 경우(예: 취재원과 소통하는 언론인), 이 점이 중요합니다. 새벽 3시 14분에 Reuters 사무실에서 이스탄불의 Signal 번호로 업로드된 147MB 파일은 내용이 암호문이더라도 이야기를 담고 있습니다.

우수한 E2EE 서비스는 메타데이터 보유를 최소화합니다. 짧은 로그 보존 기간(7일 이하), 기본 전송에 계정이 필요 없음, 전송 페이지의 서드파티 분석 없음, 이상적으로는 양파 라우팅 또는 VPN 친화적 정책이 있는 서비스를 찾습니다. 암호화 방식보다 그 주변의 운영 위생이 더 중요합니다.

주장 검증 방법

"종단간 암호화"는 증명할 수 있을 때까지는 마케팅 문구일 뿐입니다. 진정한 E2EE와 말장난을 구분하는 세 가지 테스트가 있습니다. 첫째, DevTools를 열고 업로드 중 네트워크 탭을 확인합니다. 파일 본문이 평문 multipart/form-data로 나가면 TLS 전용입니다. 둘째, 복호화 URL에 프래그먼트(#)가 있는지 확인합니다. 프래그먼트가 없으면 클라이언트 측 키가 없습니다. 셋째, 서비스의 영장 대응 정책을 읽습니다. 파일 내용을 법 집행 기관에 제공할 수 있다면 처음부터 E2EE가 아닙니다. 영장 금지 선언을 게시하고 암호화 코드를 오픈소스화한 서비스(WebCrypto API 사용을 보여주는 GitHub 저장소)가 가장 강력한 보장을 제공합니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.