TLS

리브레 위키에 SSL 연결됨

• Transport Layer Security/Secure Socket Layer

인터넷처럼 TCP/IP 프로토콜을 사용하는 네트워크에서 전송되는 데이터를 암호화해 신뢰성을 보장하고, 보안을 지켜내는 방법이다.

상세

TLS가 사용되는 대표적인 예는 HTTPS이다. 비대칭 암호화(공개키 암호화) 방식을 이용해 웹 브라우저가 "이 서버에서 온 것이 맞는가?"를 판단하여 초보적인 중간자 공격(MITM)을 예방할 수 있다.

HTTPS 뿐만 아니라 SSH/SFTP, FTPS, WEBDAVS 등 중간자 공격을 예방하고자 하는 곳이면 쓰인다.

넷스케이프에서 SSL(Secure Socket Layer)이란 이름으로 상용화되었으며, TLS(Transport Layer Security)라는 이름으로 표준에 채택되었으나 선점효과로 SSL 또는 TLS/SSL이라고 불린다. 참고로 SSL의 최종 버전이자 TLS의 최초 버전인 SSL3.0/TLS1.0은 지원 중단되었다.

한국에서는 조금 변형해서 쓰이고 있는 데, TLS 접속이 일반 접속보다 시스템 자원을 조금 더 많이 쓰다보니 로그인 과정에만 TLS를 적용하는 모습을 많이 볼 수 있다. 법에서 딱 그정도만 해도 무방하다고 정해져 있기 때문. 대형 포털 등은 사용자의 민원에 못 이겨서 모든 페이지에 TLS를 거는 모습을 볼 수 있다.

핸드쉐이킹

TLS 연결을 처음에 개시하는 것을 ‘핸드쉐이킹’이라고 부른다.

1. 먼저 TCP 핸드쉐이킹을 완료한다.
2. 클라이언트(웹 브라우저)가 서버에 암호화를 제의한다. 제의에는 암호화 방법 등을 제시한다.
3. 서버는 클라이언트에게 제의 수락을 통보하고, 인증서를 송신한다.
4. 클라이언트는 인증서와 서버의 정보를 대조하고, 통신간 사용할 암호를 인증서로 암호화하여 전송한다. 대부분 이 단계에서 인증서 불일치나 출처 불명의 인증서로 인한 오류가 발생해 사용자를 보호한다.
5. 서버가 클라이언트에 암호 수신을 통보한다.
6. 암호화된 환경에서 웹 브라우징(HTTP 통신)이 시작된다. (핸드쉐이킹 절차 종료)

SNI (Server Name Indication)

SNI(Server Name Indication)은 TLS 핸드세이킹 과정에서 접속하고자 하는 호스트네임(예: librewiki.net)을 제시하여 서버가 알맞은 인증서를 제시하도록 하는 프로토콜 확장이다.

TLS 핸드세이킹 과정에서 서버가 인증서를 제시하면 클라이언트는 이 인증서가 올바른 인증서인지 검사한다. 이때 하나의 IP주소에서 여러 개의 사이트를 호스팅하는 경우, SNI 확장이 없다면 서버 관리자는 최상위 인증서에 호스팅하는 모든 도메인을 포함하여야 한다. 그러나 인증서 받는 절차가 꽤 까다롭고, 매번 수수료를 요구하기 때문에 매우 번거롭다.

따라서 TLS 핸드세이킹 과정에서 평문으로 접속하고자 하는 호스트네임을 같이 보내주게 하여 호스트네임별로 알맞은 인증서를 서버가 제시할 수 있도록 하는 SNI 확장이 개발되었으며, 현재 대다수의 주요 브라우저들은 이를 지원하고 있다.

방송통신심의위원회가 SNI 확장에서 호스트네임(도메인)이 암호화되지 않는 점을 노려, 이를 이용해 Https 사이트 접속을 차단하고자 하는 노력을 하고 있다. 어려분의 세금이 이런 곳에 쓰이고 있습니다! 물론 이런 창과 방패 싸움에서 한쪽이 놀고만 있지 않으므로, 이또한 암호화하기 위한 기술표준 초안이 작성되고 있다.

인증서

EV SSL이 사용된 모습

SSL 연결에는 인증서가 쓰인다. 인증서의 권위에 따라 몇 가지로 구분된다.

• DV (Domain Validation) : "이 도메인에 맞는 웹서버임을 인증"하는 인증서이다. 중간자 공격 방지에는 충분하지만, 도메인 소유만 인증되면 발급되기 때문에 인증서는 암호화에만 사용되고 사이트의 인증에는 사용되지 못한다고 봐야한다.
• OV (Orgazination Validation) : "이 기관의 웹 사이트가 맞습니다"라는 인증서. 이걸 받으려면 정부가 보증하는 신분증명 등의 실제 소유자라는 인증이 필요하다.
• EV (Extended Validation) : OV의 강화판. 인증 기관에서도 철저하게 관리하며 이걸 받은 사이트에 접속하면 웹 브라우저가 파비콘 자리에 소유자 이름을 띄워줘 확실한 표식을 제공했었다.

혼자 사용하는 개인용 사이트 정도면 자체 서명 인증서를 사용해도 무방하나, 다른 사람들이 들어올 때는 인증서 경고가 나오기 때문에 보통은 공신력 있는 인증기관(CA)의 서명을 받은 인증서를 사용한다. CA의 1차 인증서는 브라우저에 내장되어 제공되기 때문에 누군가 의도적으로 신뢰되지 않는 CA를 설치하지 않는 이상 수상한 인증서들은 거진 걸러진다.

인증기관이 허위 인증서를 발급하는 등 신뢰해주기 어렵다고 판단되면 웹 브라우저 개발주체들은 해당 인증기관의 Root CA 서명을 제거하여 인증서의 신뢰 판별을 중단하고, 신뢰를 잃은 인증기관의 인증서는 '안전하지 않음' 상태가 되거나 웹 브라우저에서 연결을 거부한다. 특히 모질라 파이어폭스가 까다롭다.

인증기관의 서명이 탑재되지 않은 대표적인 사례는 다음과 같다.

• 한국인터넷진흥원(KISA) · 행정전자서명인증관리센터(GCMA)

  인증서 관리를 제대로 하지 않아 모질라 파이어폭스에 자신들의 CA 서명을 탑재해달라고 요청했다 기각당했다. 또한 행정, 교육 등의 목적으로 타 부처가 GCMA를 끼고 별도로 인증서를 만드는 데, GPKI가 제3자 인증을 받지 못해서 하위 인증서도 신뢰를 받지 못한다. 2018년에는 지방교육청에서 임의로 만들면서 행정 편의만 생각하다가 국제망신을 당하기도 했다.

• DigiNotar

  2011년, 이란의 인터넷 검열 사태에 자사 인증서가 악용(허위발급)된 사실이 발견되면서 신뢰를 잃어, 곧장 파산했다.

• StartCom

  중국 회사에 인수된 이후 허위 인증서 발급이 발각되어 구글 크롬과 모질라 파이어폭스에서 CA 서명이 빠졌다. DV는 무료로 발급하기 때문에 많은 수가 발급되어 있다.

• 시만텍(Symantac)

  2016년 ~ 2017년간 허위 인증서 발급이 탄로나 신뢰 상실 위기에 놓였다. 구글과 시만텍 간의 진실게임이 지속되고 있으며, 시만텍은 대한민국 등록대행 파트너인 한국전자인증이 무단 발급한 127개만 인정했으나, 구글은 3만개가 넘는 인증서가 허위 발급되었다고 주장했다. 구글 크롬이 시만텍의 CA 자격을 격하함에 따라 시만텍은 사업을 포기하고 타사에 매각했다.

무료 SSL 적용

날이 갈수록 SSL의 필요성이 증대됨에 따라, 개인 VPS나 홈 서버에 SSL을 적용하는 사람들이 있다. 도메인 소유만 확인하는 DV의 발급이 까다롭지 않고 저렴한 것도 있지만, 무료로 DV를 발급해주는 프로그램이 있기 때문이다. Let's Encrypt이 대표적이다.

• Let's Encrypt

  자체적인 Root CA를 가지고 있는 프로젝트이지만, 웹 브라우저 호환성을 위해 IdenTrust의 협조를 받고 있다. 이 프로젝트의 특징은 리눅스/유닉스 서버에서 직접 인증 절차를 거쳐야 한다는 점과, 유효기간이 90일에 불과하다는 점이다.

• StartSSL

  위에서 부정발급 사례로 소개되었던 StartCom의 프로그램이므로 이쪽 사용을 권장하진 않는다. 다만 Let's Encrypt보다 발급절차가 쉽고 인증 기간이 1년에서 최대 3년으로 길게 나오기 때문에 Let's Encrypt를 적용하기 정말 어려운 상황이라면 사용하는 수단 정도로 생각하면 좋다.