TLS

Chrome, Edge (EdgeHTML), Internet Explorer, Opera, 그리고 Firefox에서 나무위키에 TLS로 연결한 모습.

네트워크에서의 정보의 무결성을 보장하기 위한 전자서명 및 암호화 프로토콜. 넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에 기반한 기술로, 국제 인터넷 표준화 기구에서 표준으로 인정받은 프로토콜이다. TCP 443 포트를 사용한다. 표준에 명시된 정식 명칭은 TLS지만 아직도 SSL이라는 용어가 많이 사용되고 있다.

TLS 테스트 사이트

1.1. 작동 방법

인터넷을 사용한 통신에서 보안을 확보하려면 두 통신 당사자가 서로가 신뢰할 수 있는 자임을 확인할 수 있어야 하며, 서로간의 통신 내용이 제3자에 의해 도청되는 것을 방지해야 한다. 따라서 서로 자신을 신뢰할 수 있음을 알리기 위해 전자 서명이 포함된 인증서를 사용하며, 도청을 방지하기 위해 통신 내용을 암호화한다. 이러한 통신 규약을 묶어 정리한 것이 바로 TLS. 주요 웹브라우저 주소창에 자물쇠 아이콘이 뜨는 것으로 TLS의 적용 여부를 확인할 수 있다.

예를 들어 인터넷 뱅킹을 하기 위해 은행의 사이트에 방문했을 때, 고객은 그 사이트가 정말 은행의 사이트가 맞는지 아니면 해커가 만든 가짜 피싱 사이트인지 확인할 수 있어야 하며, 은행 역시 자신의 서비스에 접속한 자가 해당 고객이 맞는지 아니면 고객의 컴퓨터와 서버 사이에서 내용을 가로채고자 하는 해커인지 확인할 수 있어야 한다. 그리고 은행과 고객 간의 통신 내용이 다른 해커에게 도청되지 않도록 내용을 숨겨야 한다. 이럴 때 바로 은행과 고객 간에 TLS를 사용한 연결을 맺어 안전하게 통신할 수 있다.

구체적으로 서로의 신원을 확인하고 통신 암호화에 사용할 세션 키를 공유하기 위해 핸드셰이크(handshake) 과정을 거치며, 다음과 같다.

먼저 클라이언트에서 서버에 ClientHello 메시지를 보낸다. 여기에는 클라이언트에서 사용 가능한 TLS 버전, 서버 도메인, 세션 식별자, 암호 설정 등의 정보가 포함된다.
클라이언트의 메시지를 받은 서버는 ServerHello 메시지를 클라이언트에게 보낸다. 여기에는 ClientHello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS 버전, 세션 식별자, 암호 설정 등의 정보가 포함된다.
서버가 클라이언트에 Certificate 메시지를 보낸다. 여기에는 서버의 인증서가 들어간다. 이 인증서는 별도의 인증 기관에서 발급받은 것이며, 서버가 신뢰할 수 있는 자임을 인증한다. 전송이 끝나면 ServerHelloDone 메시지를 보내 끝났음을 알린다.
클라이언트는 서버에서 받은 인증서를 검증한다. 인증서의 유효 기간이 만료되지 않았는지, 그 인증서가 해당 서버에게 발급된 인증서가 맞는지 등을 확인한다. 인증서를 신뢰할 수 있다고 판단하였다면 다음 단계로 넘어간다.
클라이언트는 임의의 pre-master secret[1]을 생성한 뒤, 서버가 보낸 인증서에 포함된 공개 키를 사용해 암호화한다. 이렇게 암호화된 pre-master secret을 ClientKeyExchange 메시지에 포함시켜 서버에 전송한다.[2]
서버는 전송받은 정보를 복호화하여 pre-master secret을 알아낸 뒤, 이 정보를 사용해 master secret을 생성한다. 그 뒤 master secret에서 세션 키를 생성해내며, 이 세션 키는 앞으로 서버와 클라이언트 간의 통신을 암호화하는 데 사용될 것이다. 물론 클라이언트 역시 자신이 만들어낸 pre-master secret을 알고 있으므로, 같은 과정을 거쳐 세션 키를 스스로 만들 수 있다.
이제 서버와 클라이언트는 각자 동일한 세션 키를 가지고 있으며, 이 키를 사용해 대칭키 암호를 사용하는 통신을 할 수 있다. 따라서 우선 서로에게 ChangeCipherSpec 메시지를 보내 앞으로의 모든 통신 내용은 세션 키를 사용해 암호화해 보낼 것을 알려준 뒤, Finished 메시지를 보내 각자의 핸드셰이킹 과정이 끝났음을 알린다.
이제 서버와 클라이언트 간에 보안 통신이 구성된다.

경우에 따라 클라이언트에서 서버의 인증서를 요구하는 것뿐만 아니라 서버에서 클라이언트의 인증서를 요구하기도 한다.

쉽게 요약해서, 먼저 서로가 어떤 TLS 버전을 사용 가능한지를 확인하고, 인증서를 사용해 서로를 믿을 수 있는지 확인한 뒤, 서로간의 통신에 쓸 암호를 교환하는 것이다. 그 다음부터는 서로 교환한 암호를 사용해 제3자가 도청할 수 없는 암호화된 통신을 하면 된다.

이런 과정을 거쳐 가며 굳이 세션 자체에서 대칭키 암호를 쓰는 이유는, 비대칭키 암호화는 하드웨어 자원을 엄청나게 먹기 때문이다. 보안 수준 대비 준수한 속도를 내려면 대칭키를 쓸 수밖에 없다. 대칭 키 암호화 방식으로 과거에는 DES, RC4나 심지어 SEED가 사용되는 경우도 있었으나, 현 시점에는 보안상 문제로 거의 퇴출되었으며 AES가 주류가 되었다.

대부분의 최신 CPU는 (모바일, PC, 서버를 막론하고) 암호화 연산의 하드웨어 가속을 지원하기 때문에, TLS를 적용하더라도 성능에 큰 영향을 받지 않는다. 하지만 암호화 하드웨어 가속 명령어가 탑재되지 않은 구형이나 저가형 프로세서에서는 간혹 성능 하락이 체감될 정도로 느려지는 경우도 있다. 때문에 이런 구형 기기에서도 효율적으로 암호화를 처리할 수 있도록 새로운 알고리즘 ChaCha20-Poly1305가 도입되었으며, 이는 TLS v1.2부터 지원한다.

2010년대 중반쯤 되면서 TLS의 비중이 높아지면서, 별별 물건이 나오고 있다. 공짜로 3개월치 인증서를 만들어주는 Let's Encrypt [3]와 Certbot,[4] TLS 환경은 지원하나 기본적으로 연결되지 않는 페이지를 TLS로 연결시켜주는[5] HTTPS Everywhere 확장 기능이 그 예.

1.1.1. 인증서와 Chain of Trust

위의 3번 단계에서 서버 (또는 클라이언트)를 확인하기 위해 X.509 규격의 전자서명용 인증서가 사용된다. 하지만 X.509 인증서 자체는 공개된 규격이고 OpenSSL 같은 유틸리티를 통해 누구나 생성할 수 있기 때문에, 그 인증서를 어떻게 믿을 수 있느냐의 문제가 발생한다.

주어진 인증서를 믿을 수 있느냐 하는 문제는 중간자 공격을 고려하였을 때 두드러지게 된다. 사실 위의 과정을 보면 인증서를 받은 순간부터 클라이언트와 서버가 주고 받는 모든 메세지들은 전부 암호화되어 있다. 따라서 공격할 의미가 별로 없는 ClientHello와 ServerHello 부분을 제외하면 중간자가 공격, 즉 메세지 탈취와 조작을 가할 수 있는 단계는 서버가 클라이언트에게 인증서(Certificate) 메세지를 보내는 단계 뿐이다. 유일하지만 이 부분이 가장 취약한 단계인데, 중간자가 인증서를 바꿔치기할 수 있기 때문이다. 즉, 중간자는 서버의 인증서를 갈무리한 다음, 메세지를 조작해 자신의 인증서를 대신 클라이언트에게 보낼 수 있다. 클라이언트가 이 인증서에 대한 검증을 하지 못한다면 (혹은 안 한다면[6]), 클라이언트는 어쩔 수 없이 이 인증서에 담긴 공개키로 pre-master key를 암호화해서 서버에 전송할 것이다. 이때 중간자는 이 메세지 또한 탈취하여 자신의 개인키로 (중간자의 공개키로 암호화된) 이 메세지를 복호화한 다음, 갈무리해 둔 서버의 인증서에 담긴 공개키로 pre-master key를 다시 암호화를 하여 서버에게 보낼 것이다. 이런 식으로 하면 서버와 클라이언트는 공격이 일어났는지도 모른 채 통신을 이어가겠지만 중간자는 이미 pre-master key를 손에 넣었기에 이후의 서버와 클라이언트 간 모든 암호화된 메세지들을 전부 복호화할 수 있을 것이다. 따라서 클라이언트는 서버의 인증서를 검증할 필요가 있다. 불행하게도 중간자가 얼마든지 메세지를 조작할 수 있는 상황에서는 하나의 채널 안에서 클라이언트와 서버 만의 통신으로 이를 성공적으로 수행하기가 쉽지 않다.

이 때문에 등장한 것이 믿을 수 있는 인증기관(Certificate Authority; CA)라는 개념이다. CA가 도메인/웹사이트의 소유자에게만 인증서를 발급해주고, 발급된 인증서를 CA가 보유한 인증서로 서명해주는 것으로, 해당 인증서의 유효성을 CA가 보증하는 것이다.

운영체제나 웹 브라우저 등은 각각 믿을 수 있는 CA의 목록을 보유하고 있다. 운영체제나 웹 브라우저가 CA의 목록을 보유하고 있다는 것은 이미 CA들의 공개키를 저장해 두고 있다는 것이다. 클라이언트가 서버의 인증서를 받으면, 해당 인증서가 믿을 수 있는 CA의 인증서로 서명된 것인지 확인한다. 여기서 모든 인증서의 서명은 서버가 사전에 CA를 통해 발급받은 것으로, 위 통신 과정에서 서버의 공개키와 함께 보내지는데 (인증서 자체가 공개키와 전자서명 등을 포함하고 있는 형식이다), 서버의 공개키와 해당 사이트의 도메인 주소와 같은 고유한 정보로 만들어진 해시값을 CA의 개인키로 암호화한 것이다. 현재 널리 쓰이는 공개키 알고리듬들의 특성 상, 개인키로 '복호화'하는 과정을 거쳐 나온 값을 공개키로 '암호화'하면 원래 값이 나오기 때문에 가능한 방식이다. 따라서 클라이언트는 이 서명을 CA의 공개키로 암호화하여CA가 구했던 해시값을 얻을 수 있다. 이제 클라이언트는 인증서의 정보들을 이용하여 CA에서 했던 것과 같은 방식으로 해시값을 만든 다음, 이 두 해시값을 비교하여 해당 인증서가 정말로 '인증'을 받은 것인지 확인할 수 있다. 물론 CA 외에 다른 누군가가 CA가 보유한 개인키로 복호화하는 것은 (유의미한 연산 시간 안에) 불가능하고, 따라서 해당 CA의 서명을 임의로 만들거나 조작할 수 없으며, 이로부터 서명의 안전성이 보장된다.[7] 또한 클라이언트는 CA의 공개키를 이미 보유하고 있으므로 위에서 지적한 중간자 공격으로 인한 공개키 조작으로부터 자유롭다.[8] 이렇게 해서 해당 인증서가 믿을 수 있는 CA의 인증서로 서명되어 있음을 확인하면 유효한 인증서로 간주해서 통과시키고, 그렇지 않으면 보안 경고를 띄우면서 접속을 막는 식으로 인증서 전달 과정에서 생길 수 있는 보안 허점을 봉쇄할 수 있다.

실제로는 CA의 인증서로 사이트의 인증서를 바로 서명해주는 것이 아니라 "최상위(Root)" CA가 "중간(Intermediate)" CA 인증서를 서명해주고, 그 중간 CA 인증서로 사이트의 인증서를 서명해 주는 식으로 동작한다. 이것을 Chain of Trust(신뢰의 사슬)이라고 한다. 만약 Root CA의 개인키가 해킹당하면 해당 Root CA가 서명한 수많은 인증서가 모두 무효화되는 사태가 발생할 것이다. 이런 사건을 최대한 막기 위해, Root CA의 개인키는 중간 CA를 서명할 때만 쓰도록 하고, 실제 사이트의 인증서는 중간 CA가 발행하게 하여 일종의 완충지대를 두는 것이다.

현재 나무위키에서 사용되는 인증서[9]를 예로 들면,

이 인증서는 중간 CA인 " Cloudflare Inc ECC CA-3"의 인증서로 서명되어 있다.
또 "Cloudflare Inc ECC CA-3" 중간 CA 인증서는 "Baltimore CyberTrust Root"의 최상위 CA 인증서로 서명되어 있다.

"Baltimore CyberTrust Root" 최상위 CA 인증서는 마이크로소프트, Apple, 모질라 재단 등 주요 운영체제와 브라우저 개발사에서 모두 신뢰하는 최상위 인증서이므로, 인증서 검증을 문제없이 통과하게 된다.

이런 인증서 발급 시스템을 구축하고 유지보수하는 데에는 비용이 많이 발생하므로, 전통적인 CA들은 인증서를 발급할 때마다 발급 비용을 받아 왔다. 돈을 내야 인증서를 받을 수 있다는 점이 TLS 보급의 가장 큰 걸림돌로 다가오자, 2014년 전자 프런티어 재단, 모질라 재단, 미시간 대학교, 아카마이 테크놀로지스, 시스코가 함께 무료로 90일간 유효한 인증서를 발급해주는 CA인 Let's Encrypt를 설립하였다. Let's Encrypt의 등장 이후 웹에서의 TLS 보급률은 급격히 상승하였으며, 2023년 현재는 Let's Encrypt 외에도 ZeroSSL, Buypass Go 등 무료로 DV 인증서를 발급해주는 CA들이 차례로 등장해 있다. 그 외의 CA 목록은 아래의 인증 기관 목록 문단을 참조.

1.1.1.1. 인증서의 종류

TLS에 사용하는 인증서는 일반적으로 다음의 종류가 있다. 아래로 내려갈수록 검증에 필요한 서류작업이 많아지며 가격도 비싸진다.

도메인의 소유권만을 검증하는 DV(Domain Validation; 도메인 검증) 인증서
인증서 발급 대상의 실체까지 검증하는 OV(Organisation Validation; 조직 검증) 인증서
인증서 발급 대상 조직 심사, 검증, 도메인 승인을 모두 거치는 EV(Extended Validation; 확장 검증) 인증서

DV 인증서는 Let's Encrypt같은 무료 인증서의 등장 전에도 1년에 몇만 원 정도로 비교적 저렴했으나, EV는 1년 발급비용만 수십~수백만원을 호가한다.

기술적인 측면에서 보면, TLS에 사용되는 인증서의 종류에 따른 보안성 차이는 사실상 없다. 인증기관의 세일즈맨들은 '도메인 소유자 이메일 인증만 거치면 발급되는 DV는 별로 안전하지 않다'고 주장하지만 이는 어디까지나 (단가가 더 비싼) OV나 EV 인증서를 팔기 위한 것에 가깝다. 어차피 브라우저/클라이언트들은 정해진 단계의 검증[10]만 통과되면 DV, EV, OV 가리지 않고 적절한 TLS 인증서로 인정하고 보안 연결을 수립한다.

기술적인 측면에서는 EV 인증서 역시 그냥 X.509 인증서이며, 그냥 OID 필드가 몇 개 추가로 붙어 있는 것에 불과하다. 애초에 목적 자체가 사용자가 피싱에 속아넘어가는 것을 막기 위해 개발된 것이기에, 통신보안이라는 측면에서 보면 EV 인증서를 써도 일반 DV 인증서를 사용했을 때에 비해 보안성이 개선되는 것은 아니다.

과거에는 주요 웹 브라우저를 사용해 Extended Validation 인증서를 쓰는 웹사이트에 접속하면 위와 같이 주소창에 특유의 녹색 표시가 생기며 EV-SSL 연결이 되었음을 표시했다. 하지만 실제로 EV-SSL이 도입되고 나서 실험을 해 보니, 대부분의 사용자들이 EV-SSL 표시가 무슨 뜻인지 몰라서 EV-SSL의 유무로 피싱 사이트를 식별하지 못한다는 사실이 밝혀졌다. 이 때문에 결국 2018년 Safari를 시작으로 2019년 크롬, 파이어폭스 등 주요 브라우저에서 EV-SSL 연결 표시를 삭제하면서[11] 인기가 급격하게 식어 버렸다.

1.2. HTTPS

관련 문서: 2019년 인터넷 검열 사건
TLS를 사용해 암호화된 연결을 하는 HTTP를 HTTPS(HTTP Secure)라고 하며, 당연히 웹사이트 주소 역시 http://가 아닌 https://로 시작된다. 기본 포트는 80번이 아닌 443번을 쓴다.

흔히 TLS와 HTTPS를 혼동하는 경우가 많은데, 둘은 유사하긴 하지만 엄연히 다른 개념임을 알아두자. TLS는 다양한 종류의 보안 통신을 하기 위한 프로토콜이며, HTTPS는 TLS 위에 HTTP 프로토콜을 얹어 보안된 HTTP 통신을 하는 프로토콜이다. 다시 말해 TLS는 HTTP뿐만이 아니라 FTP, SMTP와 같은 여타 프로토콜에도 적용할 수 있으며, HTTPS는 TLS와 HTTP가 조합된 프로토콜만을 가리킨다.

HTTP는 HTTPS와 달리 암호화되지 않았으며, 중간자 공격 또는 도청의 가능성이 높으므로 HTTPS만큼 안전하지 않다.

웹 브라우저 중 하나인 크롬은 사이트의 보안에 따라 주소창에 아이콘을 표시한다. 지금은 일부 변경되었다.

안드로이드 9를 타깃으로 하는 앱을 만들 때에는 기본값으로 HTTPS 통신만 허용하고 HTTP 통신을 할 경우에는 예외가 발생한다. 개발중인 앱이 HTTP 통신을 하려면 Android Studio에서 별도의 플래그를 추가해야 한다.

HTTPS가 지원되는 사이트를 HTTP 프로토콜로 접속 시 웹 브라우저 차원에서 일정 기간 동안 보안 접속(HTTPS)으로 강제 전환시키는 HSTS라는 기술도 있다. 당연하지만 보안을 강화시키기 때문에 대부분의 최신 웹 브라우저에서 지원하고 있다.

HTTPS 기술 자체는 오래 되었으나 적용범위는 한참 지지부진했었다. 보통 금융쪽 웹사이트나 전체 페이지를 암호화했고 일반적인 사이트는 로그인 과정등에 부분적으로 적용했었는데, 보다못한 구글이 Chrome과 안드로이드를 통해 HTTP 사이트에 대해 안전하지 않다고 경고를 띄워버리는 강수를 뒀다.[12] 당연히 사용자 입장에서 안전하지 않다고 뜨니 난리가 날 수밖에 없었고 지금은 대부분의 웹사이트에서 HTTPS를 지원하고 있다.

현재는 크롬에서 열리는 페이지 중 99%가 HTTPS를 사용한다.

DNS 서버와 통신하는 데이터를 암호화 하는 것에도 TLS와 HTTPS가 모두 사용된다. 암호화가 되지 않은 통신을 제 3자가 가로챈다면 DNS 기록을 볼 수 있으므로 사실상 인터넷 검색 기록을 실시간으로 털리는 것과 다름 없다. DNS에서는 TLS와 HTTPS가 다른 방식으로 운용되기 때문에, https://로 시작하는 주소 이외에 tls:// 같은 주소도 있다. 사실 둘다 같은 방식인데 dns 서버의 주소만 다른 경우긴 하다.

1.2.1. HTTPS Mixed 모드

HTTPS로 연결된 페이지에서 한 개라도 구성 요소 중 HTTP로 로드하는 것이 있다면 웹 브라우저에서 보안 경고를 띄우거나[13] 아예 무시해버린다. 암호화 페이지를 거의 다뤄보지 않은 초보 웹 관리자가 여기서 실수하는 경우도 많다. 웹상의 모든 요소를 암호화해야 하기 때문인지, 외국 홈페이지는 국내 페이지에 비해 디자인이 단순한 경우가 많다.

예외적으로 이미지(img), 비디오(video), 오디오(audio)는 HTTP로 로드할 수 있게 되어 있으나, 이 경우 Mixed HTTPS로 취급하여 주소 표시줄에 자물쇠 표시가 사라진다. 그러다가 크롬 80 버전에서 비디오와 오디오에 한해서 HTTP로 로드할 수 없게 바뀌었고, 86 버전에서는[14] 이미지 역시 HTTP로 로드할 수 없게 바뀌었다. 만약 HTTP로 링크가 걸려있으면 HTTPS로 재작성해서 로드하는데, 링크가 HTTPS를 지원하지 않으면 이때는 아예 표시가 안 된다.

1.3. 버전별 특징

1.3.1. SSL v1/2/3

넷스케이프에서 개발한 버전으로 1.0 버전은 만들어졌으나 치명적인 보안 결함 때문에 공개된 적은 없다. 2.0 버전은 1995년도에 공개되었으나 보안 취약점이 발견되어 다음 해인 1996년에 3.0 버전으로 대체되었다. 2016년 현재는 볼 일이 없는 프로토콜인데, 2.0 버전은 2011년에 사용이 금지되었으며, 3.0 버전도 2015년에 사용이 금지되었다. 두 버전 모두 POODLE, DROWN 등의 취약점이 발견되어 암호화 프로토콜로서의 기능을 잃은 상태이기 때문이다.

1.3.2. TLS 1.0

1999년도에 SSL 3.0의 업그레이드 버전으로 공개되었다. SSL 3.0과 큰 차이가 있는 것은 아니나, SSL 3.0이 가지고 있는 대부분의 취약점이 해결되었다.

Windows XP와 Windows Server 2003, Windows Vista에서 지원하는 마지막 버전이다. Windows XP와 Windows Server 2003에서는 3 DES 알고리즘만 지원하였으나, Windows Vista에서 AES 알고리즘을 지원하도록 변경되었다.

1.3.3. TLS 1.1

2006년 4월에 공개되었다. 암호 블록 체인 공격에 대한 방어와 IANA 등록 파라메터의 지원이 추가되었다.

IETF는 TLS 1.0과 1.1이 너무 오래됨에 따라 국제 인터넷 표준화 기구(IETF)의 TLS 표준에서 구버전에 대한 호환을 고려한 부분을 파기하는 안을 심사중에 있고 #, 브라우저 벤더들은 2020년까지 TLS 1.0과 1.1의 지원을 중단하기로 하였다. Chrome은 72 버전부터 TLS 1.0, 1.1에 대해 개발자 도구에서 경고를 표시하며, 2020년 7월에 배포된 84 버전부터는 안전하지 않다는 경고 화면을 표시하면서 연결을 차단한다.[15] 파이어폭스와 엣지도 지원을 중단했다 (2020년 8월 1일 기준). Internet Explorer, 사파리도 마찬가지로 2020년 상반기까지 지원을 중단할 예정이다.

1.3.4. TLS 1.2

2008년도 8월에 공개된 TLS의 최신 버전. 취약한 SHA1 해싱 알고리즘을 사용하지 않고 SHA2를 사용하도록 변경되었다. 2020년 현재 대부분의 사이트에서 지원하고 있다.

Windows XP의 경우 TLS 1.0까지만 지원하나 POSReady2009 버전은 TLS 1.2까지 지원하는데, 이를 이용해 TLS 1.2까지 사용하도록 설정할 수 있다.

1.3.5. TLS 1.3

2018년 8월 10일 RFC 8446으로 게시되었다.

서버에서 인증서를 암호화하여 전달하도록 개선되었고, 최초 연결시에 암호화 통신을 개시하는 절차를 간소화하여 성능을 향상하였다. 그 밖에 오래된 암호화 기술 등을 폐기하였다.

성능 면에서는, HTTP/2의 보급으로 인하여 예전처럼 웹 페이지를 열 때마다 새로 연결을 맺지 않고 한 연결을 맺고 그것을 계속 쓰기 때문에, 최초 연결에서 절차가 간소화된다 하더라도 체감 성능에서 큰 차이는 나지 않는다.

SNI 필드에 대한 암호화 규격이 들어갈 예정이었으나 표준에는 포함되지 않았고, TLS 1.3 확장 기능으로써 Apple, Mozilla, Cloudflare, Fastly가 함께 Encrypted SNI(ESNI)에 관한 초안을 게시하였다. 초안 링크 현재는 ESNI를 업그레이드하여 Encrypted Client Hello (ECH)라는 이름으로 표준화 단계를 밟고 있다.

TLS 1.2도 아직까지는 안전한 편이므로 당장 업그레이드 해야 하는 것은 아니지만, 위의 SNI 필드 암호화 확장 규격까지 합치면 평문으로 전송되는 부분이 아예 없어지기 때문에 인터넷 보안과 검열 등에 신경써야 하는 사이트들은 업데이트가 필요하다. HTTP/3를 지원하기 위해서는 필수 프로토콜이다. 현재 대부분의 웹사이트들이 이 프로토콜을 지원하고 있다.

중국에서는 인터넷 검열을 위해 TLS 1.3을 차단하고 있는 것으로 알려졌다. ZDNet 기사

1.4. 문제점

TLS에서 서버 및 클라이언트의 신원을 확인하는 데는 인증서가 사용되며, 인증서의 신뢰성은 인증서를 발급해 준 인증 기관에 의해 결정된다. 인증 기관이 신뢰 가능한 인증서만을 발급해 줬다면 문제가 없지만, 만약 제대로 확인되지 않은 인증서를 발급한다면 더 이상 그 인증서를 신뢰할 수가 없을 것이다.

몇몇 인증 기관에서 도메인 소유자를 확인하는 방식의 Domain Validation, 즉 DV 인증서를 발급하기 시작하였다. 이러한 인증서는 오직 발급을 요청한 자가 그 도메인의 소유자가 맞는지만을 인증하기 때문에 사실상 발급 비용만 내면 아무나 인증서를 받을 수 있다. 심지어 해커가 피싱용 도메인 narnu.wiki[16]을 만든 뒤, 인증 기관에 Domain Validation 인증서를 요청하면 그대로 발급된다. 도메인을 소유한 자와 인증서를 신청한 자가 동일한 사람(=해커)이기 때문. 하지만 이 피싱 사이트에 접속한 대부분의 사용자들은 HTTPS 연결이 되었기 때문에 보안이 지켜질 것이라 생각하게 된다.[17]

이러한 문제를 해결하기 위해 나온 것이 EV-SSL이다. EV-SSL은 공신력 있는 인증 기관에서 더욱 엄격한 심사 기준으로 발급한 Extended Validation 인증서를 사용하여 보안을 강화한 프로토콜이다. 주요 웹 브라우저를 사용해 Extended Validation 인증서를 쓰는 웹사이트에 접속하면 위와 같이 주소창에 특유의 녹색 표시가 생기며 EV-SSL 연결이 되었음을 표시했다. DV 인증서에 비해 인증서 인증 조건이 상당히 빡빡하며[18] 발급 비용도 도메인 인증서에 비해 몇 배 이상 비싸다. 하지만, EV-SSL 표시 여부가 대부분의 사용자에게 피싱 보호 역할을 제공하지 못한다는 UX 연구결과가 여럿 나왔고, 결국 2018년 Safari를 시작으로 2019년 크롬, 파이어폭스 등 주요 브라우저에서 EV-SSL 연결 표시를 삭제하면서[19] 인기가 급격하게 식어 버렸다.

이 외에도, TLS는 망연결에서의 보안을 책임지고 있으므로, 연결된 단말기가 해킹당한 경우라면 아무리 TLS를 써도 무용지물이다.[20][21] 즉 연결망의 안전성과 노드의 안전성은 별개라는 의미이다.

또한 위 과정을 보면 알겠지만 서버나 클라이언트나 평문 통신에 비해 부하가 크다. 암호화 과정을 거쳐야 하기 때문. 따라서 소규모의 웹 사이트에서는 별다른 걱정 없이 HTTPS 프로토콜을 사용하지만 대규모 웹 사이트에서는 쉽게 HTTPS 프로토콜을 적용하지 못하는 경우가 많다. 이를 이용해 프론트엔드단 웹을 대상으로 DDoS라도 시도할 경우 암호화 과정 때문에 HTTPS를 사용하지 않은 웹 사이트보다 더 빨리 서버가 죽을 수도 있다. 따라서 웹 사이트 전체에 HTTPS 프로토콜을 적용하기 위해 프론트 서버를 더 늘리거나 Cloudflare의 DDoS 방어 서비스 등을 이용하는 경우가 많다.

TLS는 TCP 프로토콜을 이용하므로 성능상의 불이익도 존재한다. 결국 UDP 기반의 보안 소켓인 DTLS가 이를 보완해야 한다.

1.5. 인증 기관

1.5.1. 검증된 인증 기관

이들의 인증서는 거의 대부분의 IT기업의 제품에서 유효하다.[22] 또한 아래 항목의 대부분 회사들은 Root CA가 아닌 중간 CA인 경우가 많다. 대부분은 USERTrust나 DigiCert에서 발행한 Root 인증서를 기반으로 인증서를 발급한다.

1.5.1.1. 미국

Sectigo: 이전 이름은 Comodo CA. 종합 보안기업인 Comodo의 자회사였으나, Francisco Partners에서 Comodo사의 인증서 사업을 인수하면서 이름을 바꾸었다.[23] IBK중소기업은행이 여기서 발행한 인증서를 사용한다. ZeroSSL과 이를 기반으로 하는 SSLforfree에서도 이 인증서로 작동한다.
DigiCert: 시만텍의 인증서 사업부문을 인수하면서 급격히 성장하여 현재는 세계 3위권의 인증업체. Thawte가 Verisign에, Verisign이 Symantec에, Symantec이 DigiCert에 차례로 인증서 사업을 매각하면서, Thawte·Verisign·Symantec·Digicert 브랜드로 나오는 인증서를 모두 이 업체에서 발행하게 되었다. Valve Corporation [24], 네이버 [25], PayPal, 카카오 [26], 한국SC은행이 대표적으로 여기서 발행한 EV 인증서를 사용한다. 클라우드플레어 무료 플랜에서 이 기관의 인증서를 제공하기도 했었다.[27]

GeoTrust: 원래 Verisign의 브랜드였으나 2010년 Symantec에게 매각되었으며 2017년에 Thoma Bravo에게 매각되고 DigiCert와 합병되었다.

GoDaddy: 레이싱 모델과 회사 사장이 나와서 광고하는 그 사이트다. 도메인 등록업체로 더 유명한 업체지만 자체 루트CA까지 가지고 열심히 영업하고 있다.
Thawte: "써트" 내지는 "쏘트"라고 읽는다. VeriSign과 함께 CA의 할아버지뻘 되는 아주 오래된 회사. 창립자가 회사를 VeriSign에 팔고 자기는 우주여행을 다녀왔고 우분투를 만드는 캐노니컬을 창립했다. KB국민은행, 농협중앙회, 일부 정부 기관[28]이 여기서 발급한 인증서를 사용한다.
Let's Encrypt: 링크, Certbot 링크. DV 인증서를 무료로 발급해 준다.(EV는 발급을 아예 안 한다.) ACME 프로토콜을 이용해 인증서 발급 절차가 전자동화되어 있는 게 특징. 발급을 위해 certbot이라는 프로그램을 사용하는 것이 일반적이고, 유효기간이 90일이기 때문에 갱신 자동화 스크립트를 돌릴 것을 CA에서부터 권장하고 있다.[29] 인증서 하나에 최대 100개의 SAN을 사용할 수 있다. ( 참조) 또한 2018년 3월 14일부터 와일드카드 인증서를 발급하기 시작하여 여러 도메인을 이용하기 위해 SAN을 추가하는 불편이 크게 줄었다.
Google Trust Services: 구글에서 설립한 최상위 인증 기관으로 초기에는 GlobalSign의 인증서 2개를 인수하여 운영하다가 현재는 자사의 인증서인 GTS ROOT들도 운영하고 있다. GlobalSign의 흔적은 아직도 남아 있는데, 구글의 주요 사이트들의 인증서에서 루트를 조회하면 아직도 최상위 인증 기관으로 GlobalSign R2와 R4가 표시되어 있다. Let's Encrypt와 마찬가지로 ACME 프로토콜을 이용해 무료로 인증서를 발급받을 수 있다. 다만 구글 클라우드 프로젝트를 생성하고 IAM 역할을 생성하는 등 비교적 복잡한 절차를 거쳐야 한다.
아마존닷컴: 아마존 웹 서비스 내에서 자체적으로 인증서를 관리한다. 로드 밸런서 등 AWS의 서비스를 이용하면 무료로 인증서를 발급받을 수 있다.

1.5.1.2. 일본

GlobalSign: 가상 서버 호스팅(VPS) 서비스 제공 업체인 코노하로 이름이 알려져 있는 일본 GMO 인터넷 그룹의 자회사이다. 당초 벨기에에서 설립되었으나, 2006년 GMO 클라우드 주식회사에 인수되어 일본계 업체가 되었다. 신뢰도가 높은 반면 가격은 합리적인 편이라 가성비가 좋다고 할 수 있다. 국내에서는 한국은행, 한국철도공사 등 대형 기관 및 기업 쪽에서 주로 사용하고 있으며, 점유율이 점점 상승하고 있다. 이외에도 티케이엘리베이터등 해외 여러 업체들도 이 회사 인증서를 사용한다.
SECOM Trust Systems: 우리가 아는 그 종합경비업체 세콤의 자회사이다. 해외에서는 거의 영업하지 않기 때문에 잘 알려져 있지는 않지만, 일본 법인시장에서는 상당한 강세.
Cybertrust Japan
FujiSSL

1.5.1.3. 대한민국

네이버 클라우드 Trust Services: 2017년에 루트 CA를 구성한 후 2022년 11월에 전세계 주요 OS 및 브라우저에 탑재를 완료했다.

1.5.2. 검증이 취소된 인증 기관

1.5.2.1. 미국

Symantec(구 VeriSign): 세계 100대 은행 중 97개 은행이 사용할 정도로 유명한 회사였다. 한국의 오픈뱅킹도 대부분 이 회사의 인증서를 사용했었다.
그러나, 인증서를 부실하게 운영했다는 의혹이 불거졌고 급기야는 한국전자인증이라는 한국 대행사가 상용 인증서를 테스트용으로 부정발급해버리는 사고를 치는 바람에 결국 구글에게 딱 걸리게 됐고, Symantec 인증서의 신뢰를 철회하는 지경에 이르렀다. 이후 시만텍은 DigiCert에 사업을 매각했다.

1.5.2.2. 중국

CNNIC: 중국 정부의 공업화신식화부 산하 기관으로 .CN ccTLD 도메인의 레지스트리이자 중국의 AS 번호 및 IP주소 관리를 담당하는 곳이다. 하지만 2015년, CNNIC에서 발급한 중간인증서를 이용해 google.com 도메인의 위장 인증서가 발급되었다는 사실이 밝혀지며 주요 브라우저에서 CNNIC 루트 인증서가 퇴출되었다.
~~WoSign~~: DV SAN 인증서를 무료로 발급해 준다. 2016.08.31 기준 10개의 도메인이 들어간 3년 짜리 SAN인증서를 무료로 발급 해주며, 수수료 없이 재발급이 가능하다. 인증서 여러 개 발급도 가능. 2016년 9월 29일 무료 인증서 발급을 중단했다.
~~StartCom StartSSL~~: 이스라엘 회사였다가 중국 업체가 인수한 회사. Class 1 인증서를 무료로 준다.(입력 실수나 개인키 분실로 인한 해당 계정의 인증 취소는 수수료를 요구해 왔으나 홈페이지가 리뉴얼된 이후로 일단 한번 등록한 공동 도메인에 대해서 재발급이 가능해졌다) 2016년에는 Let's Encrypt와 유사한 StartEncrypt라는 서비스를 출시했다. 2015년 12월 중국으로 사업을 확대하며 인증서 서버 등을 중국으로 옮긴 것으로 알려져 있었으나 사실은 WoSign에서 인수한 것임이 밝혀진다.[30]

두 업체의 인증서를 사용하는 것은 권장되지 않고 사실상 불가능하다. 2016년 8월 17일 WoSign이 다름아닌 GitHub에게 허가 없이 인증서를 발급했다는 것이 밝혀져 이에 따라 모질라와 구글이 WoSign과 StartCom의 신뢰성에 대해 조사했다. 그 결과 WoSign와 StartCom 둘 다 도메인 소유권 확인을 게을리하거나 인증서 해시[31]를 재사용하는 등 발급업체로써 지켜야 할 절차를 지키지 않았다는 것이 확인되어, 이들 업체를 신뢰 인증서 업체 목록에서 제외할 것을 권장하고 있다. 만약 신뢰 인증서 업체 목록에서 제외된다면 기존 인증서들은 모두 안전하지 않은 인증서가 되어 버리는 셈이다.

이 결과로 인해 대부분의 웹 브라우저들은 이 두 업체에서 손을 떼기 시작했다.

파이어폭스는 버전 51부터, 크롬은 버전 56부터 2016년 10월 21일 이후로 발급한 StartSSL과 WoSign의 인증서를 신뢰하지 않는다.
크롬 버전 61부터 기존에 발급되었던 StartSSL과 WoSign의 인증서도 신뢰하지 않는다. 이로 인해 일부 사이트가 접속이 불가능해지면서 피해를 입게 되었다.( #)
애플에서는 자사의 제품에 대해 2016년 9월 19일 이후 발행된 WoSign 인증서를 신뢰하지 않도록 하는 패치를 배포하겠다고 밝혔다. 애플에서는 추가적으로 WoSign과 StartCom 루트 CA에서 발급한 인증서 중 2016년 12월 1일 (UTC) 이후 발급된 인증서 또한 신뢰하지 않겠다고 발표했다.( #)
윈도우 10도 2017년 9월 26일 이후로 발급된 StartSSL과 WoSign의 인증서를 신뢰하지 않는다고 발표했다.( #)
2017년 11월 16일 StartCom은 사업 중단을 발표했다.( #)

1.5.2.3. 네덜란드

Diginotar: 네덜란드에 존재하였던 CA로 2011년 7월 10일 해커에 의한 공격으로 인한 인증서 부정 발급 사고가 일어났다. 구글, 야후 등 유명 회사의 인증서가 부정 발급 되었으며 이란에서 중간자 공격을 위해 사용되었다. 2011년 7월 19일 CA는 인증서 인프라에 대한 침입을 감지하였으며 최종적으로 531개의 부정 발급 인증서가 발견되었다. 마이크로소프트, 구글, 모질라 등은 CA의 루트 인증서를 제거하는 조치를 취하였고 회사는 2011년 9월 20일 파산하였다.

1.5.2.4. 파나마

TrustCor Systems: 정보기관을 위한 스파이웨어 제작회사와 관련이 있다는 제보와, 해당 회사에서 운영하는 종단간 이메일 서비스 앱에 스파이웨어가 심어져 있었다는 사실이 밝혀져 모질라와 마이크로소프트는 2022년 12월부터, 구글은 2023년 3월부터 루트 인증서를 제거할 예정이다.

1.5.3. 일부에서만 검증된 인증 기관

1.5.3.1. 대한민국

국내 웹사이트를 TLS 접속하면 보안 경고 웹페이지 뜨는 이유가 대부분(특히 관공서에 접속할 경우) 국내 인증 기관에서 발급하는 인증서가 제3자 검증(보안 감사)를 제대로 못 받았기 때문이다.

KISA가 파이어폭스 인증서 탑재 요청 퇴짜 맞은 사연

최근에 KISA(2014년도 검증) 행정전자서명인증관리센터(2015년도) 제3자 검증(보안감사)을 받았지만, 루트 인증 기관만 제3자 검증(보안 감사)을 받았고, 하위 인증 기관은 검증을 전혀 받지 않았다. 그 전에는 제3자 검증 혹은 보안 감사 여부 또한 전혀 알수가 없다. 왜냐하면 공인인증서를 담당하는 미래부와 KISA에 제3자 검증 및 관련 내용 공개를 요구하였으나, 국가 기밀이라며 정보 공개를 거부하였다.( 정보공개청구에 관한 출처)

대부분 해외 루트 인증 기관들은 하위 인증 기관을 두지 않는다.[32] 그래서 제3자 검증을 받으면, 루트 인증 기관 및 하위 인증 업무까지 모두 받는 셈이다. 이러한 문제가 있어서 지금까지 파이어폭스에 GPKI하고, NPKI 인증서로 된 인증서가 탑재가 되지 않는다. 또한 리눅스 및 Mac, 스마트폰에서도 탑재가 되어 있지 않다.

그러나 윈도우 운영체제 기반의 크롬, 오페라, 익스플로러, 엣지 등의 웹 브라우저로 접속하면 인증서 경고 및 인증서 오류 웹페이지가 문제가 없이 접속이 되는 이유는 마이크로소프트는 제3자 검증 받은 인증 기관인지 확인하지도 않고, 인증서 심사 및 검증도 하지도 않고(하더라도 굉장히 느슨하게 한다.) 정부가 인증서 탑재 요청을 요구 하면 무조건 인증서 저장소에 탑재해준다. 하지만 이렇게 하면 보안상 치명적인 문제가 발생한다.

KISA
행정전자서명인증관리센터: 관공서 웹사이트 https 접속시 인증서 경고 및 오류가 나는 이유가 GPKI 인증서를 발급 운영하는 인증 기관이 제3자 검증을 제대로 못 받았기 때문이다.

2017년 정부측은 GPKI 인증 오류를 해결하겠다고 공언한 상태이다.

혹시나 진행 과정에 관심이 있다면 여기(버그질라)에서 볼 수 있다.

2018년 4월에 교육부 산하 교육기관에 발급한 GPKI 인증서가 *.or.kr, *.hs.kr 같은 식으로 아예 도메인 끝부분만 맞으면 전체 적용되는 말도 안 되는 방식으로 발급되었다는 것이 이성재(기업인)에 의해 공론화 되었다. 이것은 위에 설명된 도메인으로 인한 피싱 방지가 무용지물이 되는 인증서로, 별 의미가 없게 된다. 관련 기사. 이 사건을 이유로 파이어폭스 CA 저장소에 GPKI 인증서 탑재 요청도 ~~WONTFIX~~[33] 거부되었다. 해당 버그질라

현재는 자체 인증서 사용을 포기하고 순차적으로 정부 관련된 기관과 국립대 사이트의 정부발행 SSL 인증서를 검증된 업체의 SSL 인증서로 변경하고 있다.[34]

1.6. 관련 문서

HTTP/3

2. Datagram Transport Layer Security

자세한 내용은 DTLS 문서 참고하십시오.

3. Thread Local Storage

한 스레드 내에서 전역 변수나 정적 변수처럼 쓸 수 있지만, 같은 프로세스라도 다른 스레드에서는 접근이 불가능한 저장 영역이다. 이 TLS를 적극 활용하면 스레드 경합을 최대한 줄여 여러 스레드를 매우 효율적으로 사용할 수 있게 된다.

윈도우 환경에서 TLS를 활용하기 위한 방법은 두 가지로 나눌 수 있다. 정적 TLS와 동적 TLS가 바로 그것이다. 정적 TLS는 사용이 매우 단순한 대신 메모리 활용면에서 부족함을 드러내고, 동적 TLS는 사용이 복잡한 대신 정적 TLS보다 메모리 활용이 뛰어나다는 평가를 받는다.

[1] 세션 키를 생성해낼 '틀' 정도로 비유할 수 있겠다 [2] 이때 사용하는 암호화 알고리즘은 비대칭키 암호화 알고리즘으로 공개 키와 복호화 키가 따로 있으며, 공개 키로 암호화한 암호는 서버가 가지고 있는 복호화 키로만 풀 수 있다. 따라서 이때 메시지를 감청당하더라도 감청자는 복호키를 알 수 없으므로 pre-master secret을 알 수 없다. ~~클라이언트를 해킹하지만 않는다면~~ 주로 RSA가 사용되지만 타원곡선서명(ECDSA) 등을 쓰는 경우도 있다. [3] 티스토리에서는 개인 도메인을 연결하면 이걸 활용해서 TLS 연결을 만들어준다. 개인 도메인 연결하면 TLS 사용이 불가능한 걸로도 모자라 아예 개인 도메인 지원을 끊어버려는 네이버 블로그와 대조된다. [4] 간단한 방법으로 자동 연장까지 가능해서 사실상 한번 발급받으면 신경쓸 일이 없다. [5] TLS가 불가능한 페이지를 TLS로 연결할 수는 없고(타 플러그인을 통해 강제로 TLS 접속을 시도해봐도 로딩이 불가능하다.), 그 대신 '암호화 되지 않은 모든 요청 차단'이라는 옵션을 통해 TLS 미지원 사이트와의 연결을 차단하게 할 수 있다. [6] 종종 어떤 사이트들에 들어가면 신뢰할 수 없는 인증서를 사용하는 사이트라고 경고를 띄우는 것을 본 적이 있을 것이다. 이때 이 경고를 무시하고 진행하면 이 검증을 안 하는 셈이 되는 것이다. [7] 즉, 서명이 담고 있는 해시값은 (해당 CA를 믿는다는 가정 하에) 조작으로부터 자유로운 신뢰할 수 있는 값이라는 의미다. [8] 이는 운영체제 혹은 웹 브라우저를 설치할 때 제대로 된 설치 프로그램 혹은 이미지를 써야 할 수 있는 가정일 것이다. 그렇지 않다면 (예컨대, 불법 다운로드로 받은 설치 프로그램으로 설치할 경우) 누군가가 CA의 공개키들을 입맛대로 바꾸거나 가짜 CA를 추가한다든가 하는 식으로 조작된 설치 프로그램을 가지고 운영체제 혹은 웹 브라우저를 설치하는 셈이 될 수도 있을 것이며, 이런 조작된 CA 목록을 이용하여 공격자는 위에서 언급한 중간자 공격을 수행할 수 있을 것이다. 이를 방지하기 위해 사용자는 정품 매체를 쓰거나, 어딘가에서 다운로드를 받는 경우, 사이트에서 같이 제공해 주는 해시값과 다운 받은 파일의 해시값이 똑같은지 확인하는 등의 절차를 수행해야 할 것이다. [9] SHA-256 Fingerprint: AC:07:FA:65:5D:E7:A2:25:E1:C2:87:D9:3E:C5:35:A9:04:B5:80:82:F7:61:1A:FD:5D:EB:71:77:D2:61:F0:D7 [10] Chain of Trust와 도메인 일치 검증, OCSP 검증 등 [11] 그냥 일반 인증서와 동일하며 EV 여부는 자물쇠를 클릭해야 알 수 있게 변경되었다. [12] 실제로도 안전하지 않다. 암호화되지 않은 웹서핑은, 네트워크만 뚫으면 와이어샤크 등을 통해 너무나도 손쉽게 도청할 수 있다. 특히 공용 와이파이는 비밀번호가 없거나 완전히 공개되어있는데, 그 와이파이를 쓰는 모든 통신을 훔쳐볼 수 있었던 것이다. [13] Internet Explorer에서 볼 수 있는 '보안 콘텐츠만 표시됩니다'가 대표적인 예시였다. 물론 황당한 사실은 저런 Internet Explorer도 보안 때문에 지원 종료했다. [14] 일부 컴퓨터는 85 버전부터 적용되었다. [15] 다만 chrome://flags에서 Legacy TLS Deprecation을 비활성화하면 TLS 1.0 또는 TLS 1.1만을 지원하는 페이지도 정상적으로 표시된다. [16] namu에서 m를 r+n으로 바꾼 것. 자세히 보지 않는 한 속기 쉽다. 커닝이 나쁜 글꼴에서 자주 볼 수 있는 현상으로, 이를 일컫는 속어로 Keming이라고 한다. [17] 피싱 사이트(서버)와 사용자간의 오가는 데이터는 암호화되어 보안이 지켜지나, 사이트 서버에서는 암호화된 내용을 복호화하기 때문에 연결이 된 대상이 피싱 사이트라는 점에서 로그인 정보 등 사용자 데이터에 대한 정보가 피싱 서버에 그대로 노출이 될 수 있다. [18] EV 인증서를 발급받기 위해 얼마나 삽질이 필요한지 알 수 있다. D-U-N-S 번호는 기본으로 깔고 들어가며 각종 서류도 필요하다. [19] 그냥 일반 인증서와 동일하며 EV 여부는 자물쇠를 클릭해야 알 수 있게 변경되었다. [20] 공격자가 단말기를 해킹한 상황에서, 미리 TLS 통신을 이용하여 연결하다, 피해자가 TLS 접속을 시도하면 이 접속을 이용하여 공격자의 TLS 통신 재접속에 이용하는 방식등이 있다. [21] HTTP/S 연결 디버깅에 사용되는 Fiddler가 중간자 공격에 해당하는 기법을 사용한다. 먼저 프록시를 이용하여 모든 커넥션을 피들러로 돌린 후, 피들러가 생성한 인증서(즉 퍼블릭키)를 운영체제에 등록함으로써 클라이언트가 해당 퍼블릭키를 이용해서 암호화를 진행하도록 한다. 즉, 1. 피들러 프로그램이 프라이빗키를 들고있기 때문에 패킷의 확인/임의변조가 가능하고, 2. 퍼블릭키를 클라이언트의 인증서목록에 등록했기 때문에 클라이언트가 눈치채지 못하게 연결을 가로챌 수 있었다. 이중 2번의 경우 타 프로그램/OS의 수정이 필요하기 때문에 https 연결 디버깅을 위해서 피들러는 관리자권한/sudo를 요구한다. [22] 매우 보안에 민감하거나 사용자가 직접 인증서를 등록해야 하는 경우를 제외하고는 대부분의 운영체제나 브라우저 등에 미리 등록되어 있다. [23] 기사 참조 [24] Steam도 마찬가지로 동일한 EV 인증서를 사용한다. [25] 일부 한정. [26] 발급대상은 Daum 로그인 한정이다. [27] 현재는 Let's Encrypt의 인증서를 제공한다. [28] 제20대 대통령실 등. [29] 설정 자체는 매우 간단하다. 처음 발급받을 때 갱신 스크립트를 만들어주며 90일마다 certbot renew라는 커맨드만 돌리면 알아서 갱신해준다. [30] 또한 이를 감추기 위해 본사는 그대로 이스라엘에 두되 페이퍼 컴퍼니를 설립하는 방식으로 인수 사실을 숨겨왔다고 한다. 인증 서버가 중국으로 이전된 것도 인수에 따른 것이었던 것. [31] 인증서마다 가지는 고유번호. [32] Let's Encrypt는 하위 인증 기관이지만, 3자 검증 등을 루트 인증 기관 수준으로 빡세게 받는다. [33] 참고로 해당 플래그는 버그 관리 시스템에서 '해결하지 않을 예정(=수용 의사 없음)'인 케이스에 붙는 플래그이다. [34] 2021년 기준으로 암호화가 없어진 사이트 포함해서 모두 해결됨.

1. Transport Layer Security