Transport Layer Security
1. TLS란
TLS(Transport Layer Security)은 인터넷에서의 정보를 암호화해서 송수신하는 프로토콜이다.
넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에 기반한 기술로, 국제 인터넷 표준화 기구에서 표준으로 인정받은 프로토콜이다.
표준에 명시된 정식 명칭은 TLS지만 아직도 SSL이라는 용어가 많이 사용되고 있다.
2. 작동 방법
인터넷을 사용한 통신에서 보안을 확보하려면 두 통신 당사자가 서로가 신뢰할 수 있는 자임을 확인할 수 있어야 하며, 서로간의 통신 내용이 제 3자에 의해 도청되는 것을 방지해야 한다.
따라서 서로 자신을 신뢰할 수 있음을 알리기 위해 전자 서명이 포함된 인증서를 사용하며, 도청을 방지하기 위해 통신 내용을 암호화한다.
이러한 통신 규약을 묶어 정리한 것이 바로 TLS. 주요 웹브라우저 주소창에 자물쇠 아이콘이 뜨는 것으로 TLS의 적용 여부를 확인할 수 있다.
구체적으로 서로의 신원을 확인하고 통신 암호화에 사용할 세션 키를 공유하기 위해 핸드셰이크(Handshake) 과정을 거치며, 다음과 같다.
① 먼저 클라이언트에서 서버에 ClientHello 메시지를 보낸다. 여기에는 클라이언트에서 가능한 TLS 버전, 서버 도메인, 세션 식별자, 암호 설정 등의 정보가 포함된다.
② 클라이언트의 메시지를 받은 서버는 ServerHello 메시지를 클라이언트에게 보낸다. 여기에는 ClientHello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS 버전, 세션 식별자, 암호 설정 등의 정보가 포함된다.
③ 서버가 클라이언트에 Certificate 메시지를 보낸다. 여기에는 서버의 인증서가 들어간다. 이 인증서는 별도의 인증 기관에서 발급받은 것이며, 서버가 신뢰할 수 있는 자임을 인증한다. 전송이 끝나면 ServerHelloDone 메시지를 보내 끝났음을 알린다.
④ 클라이언트는 서버에서 받은 인증서를 검증한다. 인증서의 유효 기간이 만료되지 않았는지, 그 인증서가 해당 서버에게 발급된 인증서가 맞는지 등을 확인한다. 인증서를 신뢰할 수 있다고 판단하였다면 다음 단계로 넘어간다.
⑤ 클라이언트는 임의의 pre-master secret을 생성한 뒤, 서버가 보낸 인증서에 포함된 공개 키를 사용해 암호화한다. 이렇게 암호화된 pre-master secret을 ClientKeyExchange 메시지에 포함시켜 서버에 전송한다.
⑥ 서버는 전송받은 정보를 복호화하여 pre-master secret을 알아낸 뒤, 이 정보를 사용해 master secret을 생성한다. 그 뒤 master secret에서 세션 키를 생성해내며, 이 세션 키는 앞으로 서버와 클라이언트 간의 통신을 암호화하는데 사용될 것이다. 물론 클라이언트 역시 자신이 만들어낸 pre-master secret을 알고 있으므로, 같은 과정을 거쳐 세션 키를 스스로 만들 수 있다.
⑦ 이제 서버와 클라이언트는 각자 동일한 세션 키를 가지고 있으며, 이 키를 사용해 대칭키 암호를 사용하는 통신을 할 수 있다. 따라서 우선 서로에게 ChangeCipherSpec 메시지를 보내 앞으로의 모든 통신 내용은 세션 키를 사용해 암호화해 보낼 것을 알려준 뒤, Finished 메시지를 보내 각자의 핸드셰이킹 과정이 끝났음을 알린다.
⑧ 이제 서버와 클라이언트 간에 보안 통신이 구성된다.
경우에 따라 클라이언트에서 서버의 인증서를 요구하는 것 뿐만 아니라 서버에서 클라이언트의 인증서를 요구하기도 한다.
3. HTTPS
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만큼 안전하지 않다.
HTTPS가 지원되는 사이트를 HTTP 프로토콜로 접속 시 웹 브라우저 차원에서 일정 기간 동안 보안 접속(HTTPS)으로 강제 전환시키는 HSTS라는 기술도 있다. 보안을 강화시키기 때문에 대부분의 최신 웹 브라우저에서 지원하고 있다.
4. 문제점
TLS에서 서버 및 클라이언트의 신원을 확인하는 데는 인증서가 사용되며, 인증서의 신뢰성은 인증서를 발급해 준 인증 기관에 의해 결정된다.
인증 기관이 신뢰 가능한 인증서만을 발급해 줬다면 문제가 없지만, 만약 제대로 확인되지 않은 인증서를 발급한다면 더 이상 그 인증서를 신뢰할 수가 없을 것이다.
몇몇 인증 기관에서 도메인 소유자를 확인하는 방식의 Domain Validation 인증서를 발급하기 시작하였다.
이러한 인증서는 오직 발급을 요청한 자가 그 도메인의 소유자가 맞는지만을 인증하기 때문에 사실상 발급 비용만 내면 아무나 인증서를 받을 수 있다. 심지어 해커가 피싱용 도메인 narnu.wiki을 만든 뒤, 인증 기관에 Domain Validation 인증서를 요청하면 그대로 발급된다.
도메인을 소유한 자와 인증서를 신청한 자가 동일한 사람(해커)이기 때문이다. 하지만 이 피싱 사이트에 접속한 대부분의 사용자들은 HTTPS 연결이 되었기 때문에 보안이 지켜질 것이라 생각하게 된다.
이러한 문제를 해결하기 위해 나온 것이 EV-SSL이다.
EV-SSL은 공신력 있는 인증 기관에서 더욱 엄격한 심사 기준으로 발급한 Extended Validation 인증서를 사용하여 보안을 강화한 프로토콜이다.
주요 웹 브라우저를 사용해 Extended Validation 인증서를 쓰는 웹사이트에 접속하면 위와 같이 주소창에 특유의 녹색 표시가 생기며 EV-SSL 연결이 되었음을 알려 준다.
이 외에도, TLS는 망연결에서의 보안을 책임지고 있으므로, 연결된 단말기가 해킹당한 경우라면 아무리 TLS를 써도 무용지물이다. 즉 연결망의 안전성과 노드의 안전성은 별개라는 의미이다.
또한 서버나 클라이언트나 평문 통신에 비해 부하가 크다. 암호화 과정을 거쳐야 하기 때문이다.
따라서 소규모의 웹 사이트에서는 별다른 걱정 없이 HTTPS 프로토콜을 사용하지만 대규모 웹 사이트에서는 쉽게 HTTPS 프로토콜을 적용하지 못하는 경우가 많다.
이를 이용해 프론트엔드단 웹을 대상으로 DDoS라도 시도할 경우 암호화 과정 때문에 HTTPS를 사용하지 않은 웹 사이트보다 더 빨리 서버가 죽을 수도 있다. 따라서 웹 사이트 전체에 HTTPS 프로토콜을 적용하기 위해 프론트 서버를 더 늘리거나 Cloudflare의 DDoS 방어 서비스 등을 이용하는 경우가 많다.
TLS는 TCP 프로토콜을 이용하므로 성능상의 불이익도 존재한다. 결국 UDP 기반의 보안 소켓인 DTLS가 이를 보완해야 한다.