TLS

크롬, 엣지 (EdgeHTML), 인터넷 익스플로러, 오페라, 그리고 파이어폭스에서 나무위키에 TLS 연결을 한 모습.

인터넷에서의 정보를 암호화해서 송수신하는 프로토콜. 넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에 기반한 기술로, 국제 인터넷 표준화 기구에서 표준으로 인정받은 프로토콜이다. 표준에 명시된 정식 명칭은 TLS지만 아직도 SSL이라는 용어가 많이 사용되고 있다.

TLS 테스트 사이트

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

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

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

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

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

이런 과정을 거쳐 가며 굳이 세션 자체에서 대칭키 암호를 쓰는 이유는, 비대칭키 암호화는 하드웨어 자원을 엄청나게 먹기 떄문이다. 보안 수준 대비 준수한 속도를 내려면 대칭키를 쓸 수밖에 없다.

그럼에도 일반 통신에 비해선 큰 패킷을 사용하는 암호화 통신인 만큼 속도상의 손해가 필연적으로 발생한다. 플래시 또는 용량이 큰 이미지가 많거나 망 속도 수준이 영 좋지 않은 경우 TLS를 쓰면 헬게이트가 열리기도 한다. 그래서 HTTP/2를 도입해서 TLS 상에서 속도향상을 꾀하기도 한다.

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

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라는 기술도 있다. 당연하지만 보안을 강화시키기 때문에 대부분의 최신 웹 브라우저에서 지원하고 있다.

Chrome 88부터 HTTP 양식 작성 시 오류 표시, 90부터 HTTPS 자동 연결이 시도될 예정이고, 2021년 4월부터 HTTPS가 강제될 것으로 보인다.

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

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

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

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

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

Windows XP의 경우 POSReady2009 레지스트리를 적용하면 TLS 1.2까지 지원되도록 하는 업데이트를 받을 수 있다.

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 버전부터는 안전하지 않다는 경고 화면을 표시하면서 연결을 차단한다.[7] 파이어폭스와 엣지도 지원을 중단했다 (2020년 8월 1일 기준). 인터넷 익스플로러, 사파리도 마찬가지로 2020년 상반기까지 지원을 중단할 예정이다.

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

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

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

TLS 1.2도 아직까지 충분히 안전하므로 당장 업그레이드 해야 하는 것은 아니지만, 아래 SNI 필드 암호화 확장 규격까지 합치면 평문으로 전송되는 부분이 아예 없어지기 때문에 인터넷 검열 등에 대항하는 사이트들은 업데이트를 서두를 것으로 보인다.

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

SNI 필드에 대한 암호화 규격이 들어갈 예정이었으나 표준에는 포함되지 않았고, TLS 1.3 확장 기능으로써 Apple, Mozilla, Cloudflare, Fastly가 함께 Encrypted SNI(ESNI)에 관한 초안을 게시하였다. 초안 링크

구글, 네이버[8], 나무위키 등에서 지원하고 있다.

중국에서는 인터넷 검열을 위해 TLS 1.3을 차단하고 있는 것으로 알려졌다. ZDNet 기사 역시 대륙은 검열을 못 하겠으니까 https를 막아 버린다.

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

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


이러한 문제를 해결하기 위해 나온 것이 EV-SSL이다. EV-SSL은 공신력 있는 인증 기관에서 더욱 엄격한 심사 기준으로 발급한 Extended Validation 인증서를 사용하여 보안을 강화한 프로토콜이다. 주요 웹 브라우저를 사용해 Extended Validation 인증서를 쓰는 웹사이트에 접속하면 위와 같이 주소창에 특유의 녹색 표시가 생기며 EV-SSL 연결이 되었음을 알려 준다. 구글 크롬의 경우 최근에는 모든 인증서를 자물쇠 하나로 통일하고 자물쇠 클릭시 EV임을 알 수 있게 해두었다. 인증 조건이 상당히 빡빡해지며[11] 발급 비용도 도메인 인증서에 비해 몇 배 이상 비싸다.

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

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

또한 이 파일은 레지스트리 내부에 저장되어 있는데, 만약 crypt32를 지우게 될 경우 인터넷이 완전히 먹통이 되는 대참사를 겪게 된다. 또한 나무위키조차 아예 접속이 불가능한 상황으로 치닫게 되며, 설치되어 있는 게임 컨트롤 및 모든 온라인 게임이 완전이 불통이 된다. 이와 더불어 사이트를 접속 할 때마다 엑스박스 표시에 발암에 시달리는 꼴을 보게 된다. 그와 더불어 '확인되지 않은 게시자' 표시가 수시로 뜨며, 인증서 설치를 수시로 요구한다. 해결 방법은 익스플로러를 '관리자 권한'으로 실행한 뒤 신뢰할 수 있는 기관으로 등록해야 하는 번거로움이 존재한다.

이들의 인증서는 거의 대부분의 IT기업의 제품에서 유효하다.[14]

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

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

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

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

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

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

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

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

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

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

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

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