TLS 암호화 설명

TLS는 인터넷상의 거의 모든 연결을 보호하는 기본 암호화 프로토콜입니다. 이를 통해 다른 사람이 어깨너머로 엿보는 걱정 없이 양식을 제출하고, 계정에 로그인하고, 은행 세부 정보를 확인하고, 온라인 쇼핑을 할 수 있습니다. 여기에는 인터넷 서비스 제공업체(새 창)(ISP), 핫스팟 호스트, 공용 WiFi를 모니터링할 수 있는 해커가 포함됩니다.

TLS는 기기와 서버 사이에 암호화된 연결을 설정하여 데이터를 안전하게 전송할 수 있게 합니다. 다음을 보장합니다:

• 기밀성: 데이터가 뒤섞여 있어 연결한 웹사이트나 서버만 해당 데이터를 읽을 수 있습니다.
• 무결성: 데이터는 전송 중에 탐지되지 않고 변경될 수 없습니다.
• 인증: 실제 웹사이트나 서버와 통신하고 있으며, 사칭자가 아닙니다.

올바른 서버와 통신하고 있는지 확인하기 위해 서버는 자신이 주장하는 서버임을 검증하는 디지털 인증서를 제시합니다. 이러한 인증서는 인증 기관(CA)에서 발급합니다. 인증 기관은 도메인을 공개 키에 연결하는 인증서에 서명하는 신뢰받는 조직입니다.

그래서 사이트가 아니라 사이트를 보증한 CA를 신뢰하게 됩니다. 이 신뢰는 브라우저의 HTTPS 연결 정보에 반영되며, 전통적으로 주소 표시줄의 자물쇠 아이콘으로 표시됩니다. 아이콘을 클릭하면 연결 및 인증서에 대한 세부 정보를 볼 수 있습니다.

루트 CA는 브라우저에 내장되어 있습니다. 예를 들어 Mozilla의 루트 저장소에는 약 140~160개의 루트 인증서가 포함되어 있습니다. 이러한 루트 인증서는 대부분의 웹사이트를 검증하는 데 사용되는 중간 CA를 다시 검증합니다.

일반적으로 이 시스템은 잘 작동하지만 완벽하지는 않습니다. : 수천 개의 중간 CA가 존재해 공격 표면이 커집니다. 게다가 CA는 정부의 압력을 받거나(새 창) 범죄 조직에 해킹당해 부정한 인증서를 발급할 수 있습니다. 대표적인 사례는 2011년 공격자에 의해 침해된 네덜란드 CA인 DigiNotar(새 창)입니다. 공격자들은 수백 개의 위조 인증서를 발급했으며, 보도에 따르면 주로 이란에 있는 약 30만 명의 사용자를 대상으로 Gmail 트래픽을 가로챈 것으로 알려졌습니다.

이러한 문제를 해결하기 위해 최신 TLS 연결은 인증서 투명성(CT)을 사용합니다. 이것이 CA가 처음부터 해킹당하거나 강요당하는 것을 막지는 못하지만, 그 피해를 훨씬 쉽게 발견하고 억제할 수 있게 해줍니다.

공개적으로 신뢰받는 모든 인증서는 발급되는 순간 공개적이며 변조가 불가능한 기록에 남아야 합니다. 예를 들어 Chrome은 2018년부터 최소 두 개의 독립적인 CT 로그에 기록되지 않은 인증서는 신뢰하지 않고 있습니다.

그 결과 도메인 소유자는 DigiNotar 사건 때처럼 몇 주가 걸리지 않고 몇 시간 안에 자사 사이트의 위조 인증서를 발견할 수 있습니다. 일단 발견되면 영향을 받은 인증서는 신속하게 취소할 수 있으며, 심각한 경우 브라우저는 다음 업데이트에서 해당 CA에 대한 신뢰를 제거할 수 있습니다.

TLS는 비대칭 암호화와 대칭 암호화를 결합합니다. 비대칭(공개 키) 암호화는 연결을 설정하고, 해당 비밀을 네트워크를 통해 전송하지 않고도 브라우저와 서버가 공유 비밀에 합의할 수 있게 하는 데 사용됩니다. 이를 TLS 핸드셰이크라고 합니다.

보안 연결이 설정되면 실제 데이터는 대칭 키 암호(일반적으로 AES)를 사용하여 전송됩니다. 사용되는 정확한 암호화 알고리즘은 웹 서버와 브라우저 같은 클라이언트 간에 협상됩니다. 대부분의 브라우저에서는 자물쇠 아이콘을 클릭하거나 눌러 HTTPS 연결에 사용되는 암호화 알고리즘에 관한 보안 세부사항을 더 알아볼 수 있습니다.

기존 TLS는 연결하는 웹사이트의 이름을 숨기지 않습니다. 초기 핸드셰이크에서 웹사이트 이름(SNI)과 기타 세부사항이 이를 지켜보는 모든 사람에게 유출되기 때문입니다. 2026년 3월 IETF에서 승인된 새로운 표준이 이 문제를 해결하는 것을 목표로 합니다. 작동할 경우 암호화된 클라이언트 헬로(ECH)는 핸드셰이크 자체를 암호화하므로 ISP나 핫스팟 운영자는 사용자가 방문하는 사이트를 더 이상 볼 수 없습니다. 하지만 :

• ECH는 여러 웹사이트가 동일한 IP 주소(새 창)를 공유할 때만 작동합니다. 콘텐츠 전송 네트워크(새 창)(CDN) 뒤에 있는 사이트들처럼 말입니다.
• 사이트에 자체 전용 IP가 있으면 대상은 계속 표시됩니다.
• ECH는 브라우저가 암호화된 DNS(DoH)를 사용하여 ECH 구성 키를 가져오는 것에 의존합니다. 이것이 실패하면 연결은 자동으로 평문 SNI로 대체됩니다.
• ECH는 아직 배포 중이며 Firefox와 Chrome에서 지원됩니다. 그러나 현재 상위 100만 개 웹사이트 중 약 9~10%만이 ECH를 지원하며, 이 중 거의 모두가 Cloudflare를 사용합니다.
• CDN 및 DoH 제공업체는 여전히 네트워크 연결의 최종 목적지를 확인할 수 있습니다.

TLS와 종단 간 암호화는 모두 암호화를 사용하여 데이터를 보호하지만, 누가 이를 복호화할 수 있는지에서 차이가 있습니다 :

• TLS는 기기와 서버 간의 연결을 암호화합니다. 데이터가 해당 서버에 도착하면 그곳에서 복호화됩니다. 서버를 운영하는 사람은 누구든 이를 읽을 수 있습니다.
• 종단 간 암호화(E2EE)는 기기와 다른 기기 간의 연결을 암호화합니다. 데이터가 이동하는 동안 서버를 거치더라도 의도된 수신인만 이를 복호화할 수 있습니다.

Gmail 을 통해 전송된 메시지는 전송 중에 TLS로 보호되지만, Google 서버에 도착하면 복호화되어 Google이 이를 읽을 수 있습니다. Signal 메시지나 Proton Mail 사용자 간에 주고받는 이메일처럼 E2EE를 사용하여 전송된 메시지는 의도된 수신인만 읽을 수 있습니다.

TLS와 VPN은 모두 전송 중인 데이터를 보호하지만, 목적은 크게 다릅니다 :

• VPN은 방문하는 웹사이트를 숨깁니다. TLS는 대개 그렇지 않습니다.
• VPN은 DNS 쿼리(새 창)를 숨깁니다. TLS는 DoH가 없으면 그렇지 않습니다.
• VPN은 방문하는 웹사이트가 실제 IP 주소(새 창)를 알 수 없도록 합니다. TLS는 그렇지 않습니다.
• 신뢰할 수 있는 VPN(새 창)은 검색 기록에 대한 로그를 남기지 않습니다(새 창). TLS는 ISP와 나아가 정부가(새 창) 사용자의 활동을 염탐하고 로그를 저장할 수 있게 합니다.
• TLS는 연결을 개별적으로, 한 번에 하나의 앱 또는 프로세스씩 보호합니다. 반면 VPN은 분할 터널링(새 창)을 사용하지 않는 한 기기의 모든 연결을 VPN 터널을 통해 라우팅하므로, VPN에 연결되어 있을 때 관찰자가 브라우저 및 앱 사용을 통해 행동 패턴을 추론하기가 더 어려워집니다.

TLS와 VPN은 서로를 보완하여 여러 계층의 보호를 제공합니다.

TLS 덕분에 네트워크 경로상의 모든 낯선 사람이 사용자의 행동을 지켜보는 일 없이 온라인에서 은행 업무를 보고, 쇼핑하고, 계정에 로그인할 수 있습니다. TLS가 없다면 HTTPS도 존재하지 않을 것이며, 오늘날 웹 사용에 관해 당연하게 여기는 대부분의 것들도 존재하지 않을 것입니다.

하지만 TLS는 모든 것을 숨기도록 설계된 적이 없습니다. 연결의 콘텐츠를 보호할 뿐, 연결이 이루어졌다는 사실 자체를 보호하지는 않습니다. ISP, WiFi 핫스팟 운영자 또는 네트워크를 지켜보는 다른 누구든 사용자가 방문하는 사이트는 여전히 볼 수 있습니다. 사용자가 무엇을 하는지는 볼 수 없더라도 말입니다. E2EE와 달리 TLS는 연결 중인 서비스가 사용자의 데이터에 접근하는 것을 막지 못합니다.

따라서 TLS, E2EE, VPN은 상호 보완적입니다 : TLS는 기본 보안을 제공하고, E2EE는 의도된 수신인만 데이터에 접근할 수 있도록 보장하며, 신뢰할 수 있는 VPN은 높은 수준의 온라인 개인정보 보호를 제공합니다.

TLS는 Proton 앱을 사용할 때마다 뒤에서 작동하는 프로토콜입니다. 단, 현재 주로 WireGuard(새 창)를 사용하는 Proton VPN 앱은 예외입니다. HTTPS가 연결을 보호하기 위해 의존하는 프로토콜이며, 서버 간 메일 전달처럼 직접 볼 수 없는 곳에서도 트래픽을 보호합니다. 하지만 TLS는 데이터가 이동하는 동안에만 보호합니다. 진정으로 비공개적인 콘텐츠에는 종단 간 암호화 및 제로 액세스 암호화와 같은 더 강력한 보호가 필요합니다.