TLS

(HTTPS에서 넘어옴)

@name@은(는) 여기로 연결됩니다. @other1@에 대해서는 @rd1@ 문서를 참조하십시오.{{틀:다른_뜻/설명문서}}

혹시 신을(를) 찾아오셨나요?

파일:Namu TLS.jpg

인터넷 익스플로러, 엣지, 모질라 파이어폭스, 크롬에서 나무위키에 TLS 연결을 한 모습. [1]

Transport Layer Security

1 개요

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

2 작동 방법

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

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


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

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

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

대신 일반 통신에 비해 크고 아름다운 패킷을 사용하는 암호화 통신인 만큼 속도상의 손해가 발생하게 된다. 플래시나 큰 이미지가 많은 사이트에서 TLS를 쓰는 것은 그야말로 헬게이트. 사실 이것을 간과할 수 없는 게, HTTPS로 연결된 페이지에서 한 개라도 구성 요소 중 HTTP로 로드하는 것이 있다면 웹 브라우저가 "네 컴퓨터의 통신이 암호화 안된 요소에 침식당하기 시작해서 위험해"라면서 보안 경고를 뿜어대기 때문이다. 최신 브라우저는 이것도 모자라서 강제로 암호화되지 않은 요소는 로딩에서 제외해버리기도 한다[2]. 웹상의 모든 요소를 암호화해야 하기 때문인지, 외국 홈페이지는 화려하게 치장하기에 열을 올리는 국내 페이지에 비해 깔끔한(나쁘게 말하면 수수한) 편이다.[3]

3 버전별 특징

3.1 SSLv1/2/3

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

3.2 TLS 1.0

1999년도에 SSL 3.0의 업그레이드 버전으로 공개되었다. SSL 3.0과 큰 차이가 있는 것은 아니나, SSL 3.0이 가지고 있는 대부분의 취약점이 해결되었다. 후에 등장하는 1.1,1.2에 비해 장점은 없으나 Internet Explorer 8이 지원하는 가장 높은 TLS 버전인 관계로 아직도 널리 사용되고 있다.

3.3 TLS 1.1

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

3.4 TLS 1.2

2008년도 8월에 공개된 TLS의 최신 버전. 취약한 SHA1 해싱 알고리즘이 SHA256으로 교체되었다.

3.5 TLS 1.3

2016년 기준으로 개발 중(Draft)인 버전이다. 다만 일부 웹 브라우저에 탑재되어 있어서 사용은 가능하다.

4 HTTPS

워닝에 대항하기 위한 마지막 수단
TLS를 사용해 암호화된 연결을 하는 HTTP를 HTTPS라고 하며, 당연히 웹사이트 주소 역시 HTTP가 아닌 HTTPS로 시작된다. 기본 포트는 443번을 쓴다.

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

5 문제점

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

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

파일:Attachment/SSL/evc.png
이러한 문제를 해결하기 위해 나온 것이 EV-SSL이다. EV-SSL은 공신력 있는 인증 기관에서 더욱 엄격한 심사 기준으로 발급한 Extended Validation 인증서를 사용하여 보안을 강화한 프로토콜이다. 주요 웹브라우저를 사용해 Extended Validation 인증서를 쓰는 웹사이트에 접속하면 위와 같이 주소창에 특유의 녹색 표시가 생기며 EV-SSL 연결이 되었음을 알려 준다. 인증 조건이 상당히 빡빡해지며 발급 비용이 십수 배는 비싸진다는 것은 당연한 수순.

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

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

6 검증된 CA(인증 기관)들

6.1 미국

  • Comodo Group : 한국SC은행, 국민은행, 그리고 지금 당신이 보는 이 사이트가 여기서 발행한 인증서를 사용한다. 클라우드플레어 무료 플랜에서 제공하는 인증서의 인증기관이다.
  • Geo Trust
  • Go Daddy : 레이싱 모델과 회사 사장이 나와서 광고하는 그 사이트다(...).
  • Thawte : VeriSign과 함께 CA의 할아버지뻘 되는 아주 오래된 회사. 창립자가 회사를 VeriSign에 팔고 자기는 우주여행(...)을 다녀왔고 우분투를 만드는 캐노니컬을 창립했다.
  • VeriSign : 세계 100대 은행 중 97개 은행이 사용할 정도로 유명한 회사이다. 한국의 오픈뱅킹도 대부분 이 회사의 인증서를 사용한다.
  • Let's Encrypt : DV 인증서를 무료로 발급해 준다! (EV는 발급을 아예 안 한다.) 단, 발급을 위해 프로그램을 설치해야 하고, 유효기간이 90일이기 때문에 갱신 자동화 스크립트를 돌릴 것을 CA에서부터 권장하고 있다. 인증서 하나에 최대 100개의 SAN을 사용할 수있다. [6]

6.2 일본

6.3 중국

  • WoSign : DV SAN 인증서를 무료로 발급해 준다. 2016.08.31 기준 10개의 도메인이 들어간 3년 짜리 SAN인증서를 무료로 발급 해주며, 수수료 없이 재발급이 가능하다. 인증서 여러 개 발급도 가능.
  • StartCom StartSSL : 이스라엘 회사였다가 중국 업체가 인수한 회사. Class 1 인증서를 무료로 준다.(입력 실수나 개인키 분실로 인한 해당 계정의 인증 취소는 수수료를 요구해 왔으나 홈페이지가 리뉴얼된 이후로 일단 한번 등록한 공동 도메인에 대해서 재발급이 가능해졌다.) 2016년에는 Let's Encrypt와 유사한 StartEncrypt라는 서비스를 출시했다. 2015년 12월 중국으로 사업을 확대하며 인증서 서버 등을 중국으로 옮긴 것으로 알려져 있었으나 사실은 WoSign에서 인수한 것임이 밝혀진다.[7]
2016년 9월 시점 두 업체의 인증서를 사용하는 것은 권장되지 않는다. 이는, 두 업체가 도메인 소유권 확인을 게을리하거나 인증서 해시[8]를 재사용하는등 발급업체로써 지켜야 할 절차를 지키지 않음에 따라 파이어폭스 개발사인 모질라와 크롬의 개발사인 구글이 이들 업체를 신뢰된 인증서 업체에서 제외할 것을 고려하고 있기 때문이다. 신뢰된 인증서 업체에서 제외되면 기존 인증서가 모두 안전하지 않은 인증서가 되어 버리는 셈.덧붙여 애플에서는 자사의 제품에 대해 9월 19일 이후 발행된 WoSign 인증서를 신뢰하지 않도록 하는 패치를 배포하겠다고 밝혔다.

7 검증 안 되어 있거나 검증이 어중간한 CA(인증 기관)들

7.1 한국

국내 웹사이트를 TLS 접속하면 보안 경고 웹페이지 뜨는 이유가 대부분(특히 관공서 접속할 경우…) 국내인증기관에서 발급하는 인증서가 제3자검증(보안감사)를 제대로 못 받았기 때문이다. 이렇게 된 사연이 길다…;;
KISA가 파이어폭스 인증서 탑재 요청 퇴짜 맞은 사연
"KISA가 왜 제3자의 검증을 받아야 하는가? 우리는 우리 스스로 검증한다."

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

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

그러나 윈도우 운영체제 기반의 크롬, 오페라, 익스플로러, 엣지 등의 웹브라우저로 접속하면 인증서 경고 및 인증서 오류 웹페이지가 문제가 없이 접속이 되는 이유는? (윈도우 버전용 파이어폭스는 빼고…)

그 이유는 마이크로소프트는 제3자 검증 받은 인증기관인지 확인하지도 않고, 인증서 심사 및 검증도 하지도 않고(하더라도 굉장히 느슨하게 한다.) 정부가 인증서 탑재 요청을 요구 하면 무조건 인증서 저장소에 탑재 해준다. 하지만 이렇게 하면 보안상 치명적인 문제가 발생한다.

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

8 NSA는 그런 거 알 바 아닙니다?

NSA는 조직 내에서 자체적인 학회를 열 정도의 인재풀과 자금력을 가지고 있어 암·복호화 및 감청에 관해 외부와 10년 이상의 격차를 가지고 있다고 알려져 있다. TLS는 벌써 2010년부터 뚫어서 죄다 훔쳐봤다고 하며, 차기 암호화 표준안에다 직접 마스터키 뒷구멍이 있는 암호표준을 넣기 위해 개입한다고 전해진다.(#1, #2) 다만 TLS에는 여러 버전과 암호화 알고리즘의 종류가 있고 2015년 10월 현재는 많은 TLS 라이브러리의 보안 취약점이 발견되어 패치되었기 때문에 지금까지 모든 TLS 연결을 들여다 볼 수 있을 가능성은 낮다. 하지만 모를 일이다 방패가 강해진 만큼 창도 강해졌을지... 애초에 창이 더 유리한 분야라서

9 관련 문서

이 문서의 내용 중 전체 또는 일부는 SSL문서에서 가져왔습니다.</div></div>

  1. ↑ 위 화면에서 인증서 발급자가 어베스트로 나오는 이유는 이 스크린샷을 찍은 유저가 어베스트의 HTTPS 감시 기능을 사용하고 있기 때문으로, 실제 나무위키의 인증서 발급사는 COMODO이니 참고 바람.
  2. ↑ 암호화 페이지를 거의 다뤄보지 않은 초보 웹 관리자가 여기서 삽질하는 경우도 많다.
  3. ↑ 다만 2010년대의 웹표준 바람으로 일부나마 국내 웹 페이지가 TLS로 갈아타고 있는 상황이고, 거기에 맞게 디자인을 최적화하고 있기는 하다.
  4. ↑ namu에서 m를 r + n으로 바꾼 것. 자세히 보지 않는 한 속기 쉽다. 커닝이 나쁜 글꼴에서 자주 볼 수 있는 현상으로, 이를 일컫는 속어로 Keming이라고 한다.
  5. ↑ 공격자가 단말기를 해킹한 상황에서, 미리 SSL통신을 이용하여 연결하다, 피해자가 SSL 접속을 시도하면 이 접속을 이용하여 공격자의 SSL통신 재접속에 이용하는 방식등이 있다.
  6. ↑ 참조
  7. ↑ 이를 감추기 위해 본사는 그대로 이스라엘에 두되 페이퍼 컴퍼니를 설립하는 방식으로 인수 사실을 숨겨왔다고 한다. 인증 서버가 중국으로 이전된 것도 인수에 따른 것이였던 것.
  8. ↑ 인증서마다 가지는 고유번호.