TLS
TLS(티엘에스)란 "Transport Layer Security"의 약자로서, 네트워크를 통한 데이터 통신에서 전송 정보를 보호하기 위해 사용하는 보안 유지 프로토콜이다. 전송계층보안이라고 한다. 기존의 SSL 3.0 버전을 기초로 TLS를 만들었다.
개요
웹브라우저, 이메일, 메신저, 인터넷전화와 VoIP 등 네트워크를 통해 정보를 전송하는 경우, 정보를 보내는 측과 받는 측이 통신하여 어떤 암호화 알고리즘을 사용할 것인지를 정하고 공개키 기반의 암호키를 교환한 후에 실제 데이터를 암호화하여 전송하는 방식이다. 중간에 제3 자가 전송 내용을 가로채더라도 암호를 풀지 못해 정보를 안전하게 보호할 수 있다. TLS는 응용 프로그램이 네트워크상에서 안전하게 통신하기 위해 사용되는 프로토콜로, 이메일, 웹 브라우징, 메세징, 그리고 다른 프로토콜들의 감청을 통한 정보의 변형을 방지한다.[1] 보안 소켓 계층(Secure Sockets Layer, SSL)과 TLS는 모두 웹 서버와 사용자의 웹 브라우저 간 통신을 암호화하는 데 사용되는 프로토콜이다. 공개키와 개인키를 교환하여 보안 세션을 생성하여 통신을 암호화하는 방식을 사용한다. TLS는 맥(MAC) 함수 생성을 위해 다른 암호화 알고리즘을 사용하고, 이전 버전의 보안 소켓 계층(SSL)보다 많은 경고 코드를 포함하고 있다. 보안 소켓 계층(SSL)은 인터넷을 통해 전달되는 정보 보안의 안전한 거래를 허용하기 위해 넷스케이프(Netscape)사에서 개발한 인터넷 통신 규약 프로토콜이다. TLS는 SSL 3.0을 기초로 하여 국제 인터넷 표준화 기구(IETF)가 만든 프로토콜로, SSL 3.0을 보다 안전하게 하고, 프로토콜의 스펙을 더 정확하고 안정성을 높이는 목적으로 고안되었다.[2]
특징
보안 소켓 계층(SSL)과 TLS는 모두 네트워크 우선 보안을 제공하는 암호화 프로토콜을 소규모 클라이언트, 서버 프로토콜이다. 대부분의 다른 보안 프로토콜은 운영체제 등에 밀접하게 관련되어있지만, 응용 프로그램에서 자체적으로 구현이 가능하다. 응용 계층과 전송 계층 사이에 위치하나, 전송계층과 더 밀접하게 동작하고, 소켓 지향적인 프로토콜이다. 서버와 클라이언트가 TLS로 통신을 할 때, 어떠한 제3 자도 메시지를 변형시키거나 감청할 수 없도록 한다. 모든 브라우저는 TLS를 지원하고, 안전한 연결을 하기 위해서 유효한 디지털 인증서를 제공하는 것을 요구한다.[1] 상대 사이트에 대한 신뢰성을 인증하고, 다양한 암호화 알고리즘을 이용하여 메시지를 암호화한다. 또한, 송수신 메시지에 대한 체크섬(checksum) 기능이 있고, 변조를 방지한다. 지원 프로토콜로는 HTTPS, 텔넷(Telnet), POP3S, SFTP가 있다.[3] TLS는 공개키 인증서를 이용하여 서버와 클라이언트의 상호 인증을 한다. 즉, 클라이언트와 서버 두 응용 간에 상대방에 대해 인증을 한다. 메시지 인증 코드 HMAC에 의한 메시지 무결성을 제공한다. 또한, 메시지를 압축한다. 디폴트는 널(Null)로, 무압축이다. 압축 알고리즘은 미리 정해져 있지 않고, 협상으로 지정이 가능하다. 암호화용 세션 키를 생성하기 위한 키를 교환한다. 생성된 공유 비밀키에 의해 암호화된 종단 간의 안전한 연결 통로를 제공한다.[4]
구성
5가지의 프로토콜로 구성되어 있다. Handshake 프로토콜, Change Cipher Spec 프로토콜, Alert 프로토콜, Record 프로토콜, Application Data로, Handshake 프로토콜은 양쪽 간에 연결을 설정할 때 보안 협상을 위한 프로토콜이다. 서버와 클라이언트 간의 상호 인증을 수행하고, 사용할 키 교환 방식, 대칭키 암호방식, HMAC 방식, 압축 방식 등의 보안 속성을 협상한다. Chane Cipher Spec 프로토콜은 보안 파라미터를 변경하거나 적용할 때 사용한다. 하나의 메시지로 되어 있으며, 값 1을 갖는 한 바이트로 구성된다. Handshake 프로토콜에 의해 협상된 압축, 맥(MAC), 암호화 방식 등이 적용됨을 상대방에게 알려준다. Alert 프로토콜은 오류를 전송할 때 사용되는 프로토콜이다. 경고 메시지는 압축되고, 암호화된다. 프로토콜에 있는 각 메시지는 2바이트로 되어 있다. Record 프로토콜은 협상된 보안 파라미터를 이용하여 암호화, 복호화, 무결성 검증 등을 수행하는 프로토콜이다. 메시지를 전송하고, 데이터를 블록으로 나눈다. 때에 따라 데이터를 압축하고, 맥(MAC)을 제공해 암호화하고 그 결과를 전송한다. 그리고 Application Data는 실제 데이터가 전송될 때 사용되는 프로토콜이다.[5][6]
동작 방식
핸드쉐이크
TLS의 통신 과정은 핸드쉐이크가 이루어진다. 먼저 클라이언트가 요청하면 TCP 레벨에서 연결이 맺어진 이후 TLS 핸드쉐이킹을 수행한다. ClientHello 메시지에는 클라이언트에서 가능한 TLS 버전, 세션 식별자, 암호 설정 등의 정보를 포함하는데, 이 메시지를 보낸다. 다음으로, 서버에서 암호화를 위한 인증서의 공개키를 내려주면 클라이언트는 이 공개키가 신뢰할 수 있는 인증서의 키인지 확인한다. 이후 서버는 ServerHello 메시지를 클라이언트에게 보낸다. 이 메시지에는 ClientHello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS 버전, 세션 식별자, 암호 설정 등의 정보가 포함된다. 또한, Certificate 메시지를 보낸다. 이 메시지에는 서버의 인증서가 들어있다. 이 인증서는 인증 기관에서 발급받은 것이고, 서버가 신뢰할 수 있는 자임을 인증한다. 전송이 끝나면 ServerHelloDone 메시지를 보내서 끝난 것을 알린다. 클라이언트 측에서 해당 공개키를 신뢰한다면, 이 클라이언트는 세션키를 생성하여, 서버로부터 받은 공개키로 암호화하여 서버로 전달한다. 클라이언트는 서버에서 받은 인증서를 검증하여 유효기간이 만료되지 않았는지, 신뢰할 수 있는 인증 기관에서 발급되었는지, 인증서가 해당 서버에게 발급된 인증서가 맞는지 등을 확인하여 서버를 신뢰할 수 있다고 판단하면 다음 단계로 넘어간다. 클라이언트는 임의의 pre-master secret을 생성한 뒤, 서버가 보낸 인증서에 포함된 공개키를 사용해 암호화한다. 이렇게 암호화된 pre-master-secret을 ClientKeyExchange 메시지에 포함하여 서버에 전송한다. 해당 서버는 서버에 있는 개인키를 통해 복호화를 하여 클라이언트의 세션키를 확보하고, 클라이언트가 준 cipherspec에서 서버가 허용하는 cipherspec을 클라이언트에게 전달한다. 서버는 전송받은 정보를 복호화하여 pre-master-secret을 알아내고, 이 정보를 사용하여 master secret을 생성한다. master secret에서 세션키를 생성하는데, 이 세션키는 앞으로 서버와 클라이언트 간의 통신을 암호화하는 데 사용한다. 클라이언트 역시 자신이 만들어낸 pre-master secret을 알고 있으므로, 같은 과정을 거쳐 세션키를 스스로 만들 수 있다. 서버와 클라이언트는 동일한 세션키를 가지게 되어 이 세션키를 가지고 상호 암호화, 복호화를 수행한다. 서버와 클라이언트는 각자 동일한 세션키를 갖고 있고, 이를 사용하여 대칭 키 암호를 사용하는 통신을 할 수 있다. 따라서 우선 서로에게 ChangeCipherSpec 메시지를 보내서 앞으로의 모든 통신 내용은 세션키를 사용하여 암호화해서 보낼 것을 알려준 뒤, Finished 메시지를 보내 각자의 핸드쉐이크 과정이 끝났음을 알린다.[2]
TLS 1.3
구조적인 취약점을 없애기 위해 설계되었고, 강화된 보안성과 프라이버시, 개선된 성능을 제공한다. 핸드쉐이크 단계에서 인증서를 암호화하고, 무결성을 검증함으로써 중간자 공격으로 협상 내용을 취약하게 변경하는 다운그레이드 공격의 방어가 가능해졌고, 불필요하고 안전하지 않은 암호화 알고리즘을 제거하여 보안성이 강화되었다. 또한, TLS 1.2 이하 버전에서 핸드쉐이크 과정에서 2회의 왕복 시간(Round Trip Time, RTT)를 거쳐야 했지만, 이 과정을 단순화시켜 1회로 줄여 성능을 향상했다. 세션을 재개하면, TLS 1.2 이하에서는 1회의 왕복 시간으로 동작하지만, TLS 1.3에서는 0회의 왕복시간으로 동작하는 모드를 지원한다. 즉, 첫 TLS 핸드쉐이크를 완료한 후, 서버와 클라이언트에 공유된 암호키를 로컬에 저장하고, 세션 재개 시 키를 사용하여 첫 번째 요청에서 HTTP를 포함하여 서버로 보낸다. 일반 HTTP와 동일한 지연 시간을 갖게 된다는 장점이 있지만, 응답 공격 등 보안상의 우려가 있어 주의가 필요하다. 그리고 서버 네임 인디케이션(Server Name Indication, SNI) 정보를 암호화하는 ESNI(Encrypted SNI)에 대한 드래프트가 나와 있어 프라이버시를 강화하였다. 서버 네임 인디케이션(SNI)는 TLS 확장 표준의 하나로, 동일한 IP와 포트를 사용하는 하나의 서버에서 여러 도메인을 가진 사이트를 운영할 경우 도메인 별로 각각의 인증서를 사용할 수 있게 해주는 필드이다.[7]
악용
클라이언트와 서버 사이에서 어떤 정보가 오고 가는지 알 수가 없기 때문에, 한 번 암호화되어 덧입혀져 나가면 정보를 유출해도 기존 보안 솔루션으로는 파악할 수 없다. 즉, 복호화키는 클라이언트와 서버만 알고 있기 때문에 제 3자인 보안 솔루션은 정보가 유출되었는지 알 수가 없다. 또한, 악성코드나 랜섬웨어는 PDF, 워드, 한글파일 등으로 위장한 실행 파일을 클릭함으로써 감염되는데, 이 외에도 의심스러운 URL을 클릭하여 감염되기도 한다. 링크에 접속하는 순간, 드라이브 바이 다운로드(Drive By Download) 공격으로 악성코드나 랜섬웨어 파일을 자동으로 다운로드받게 된다. 이 파일로 인해 정보 유출과 데이터의 위변조, 디도스 공격으로 악용될 수 있다.[8]
비교
개발하는 서비스 중에서 인터넷의 연결이 필요 없는 서비스는 거의 없다. 이런 서비스는 만든 앱 혹은 웹을 통해 데이터를 받아 서버에 저장한다. 이 데이터에는 굉장히 민감한 정보인 카드 번호, 주소, 심지어 집 거실에 있는 공유기의 맥(MAC) 주소까지 포함되어 있는데 이 정보들이 데이터화되어 전송된다. 중간에 데이터가 조작되거나 변조되지 않도록 암호화하여 데이터를 보내야 한다. 이런 정보를 보내기 위해 HTTP보다는 HTTPS를 사용해야 한다. HTTPS의 안정성은 TLS 프로토콜을 통해 보장된다. HTTPS는 보안용 프로토콜에 HTTP를 얹어서 보안 된 HTTP 통신을 하는 프로토콜이고, 보안 소켓 계층(SSL)과 TLS는 보안 통신을 하기 위한 보안용 프로토콜이다.[9][10] 보안 소켓 계층(SSL)과 TLS는 본질적으로 같고, 버전이 다른 정도라고 생각하면 된다. 클라이언트가 사용할 인증서가 없으면, TLS 프로토콜의 경우는 "인증서 없음" 메시지를 보내고, 보안 소켓 계층(SSL) 프로토콜의 경우는 별도의 메시지가 필요 없다. TLS는 주로 맥(MAC)을 적용하지만 보안 소켓 계층(SSL)은 MD5와 SHA를 사용한다. HMAC을 사용하면 해시 함수를 아무거나 사용할 수 있다는 장점이 있다. TLS 키를 만들 때 HMAC 스탠다드와 PRF를 사용한다. 반면 보안 소켓 계층(SSL)은 RSA, 디피-헬먼(Diffie-Hellman), Fortezza/DMS를 사용한다. TLS에서 인증서 확인 메시지는 이미 세션에서 교환된 핸드셰이크 메시지에 들어있다. 반면에 보안 소켓 계층(SSL)은 따로 보내줘야 한다. TLS에서 Finished 메시지는 PRF를 통해 "Client Finished", "Server Finished"가 같이 생성되는데, 보안 소켓 계층(SSL)에서는 키가 생성되었던 방식과 같은 방법으로 Finished 메시지가 생성된다.[11]
각주
- ↑ 1.0 1.1 〈전송 계층 보안(TLS)〉, 《MDN Web Docs》
- ↑ 2.0 2.1 와스프로 GodNR, 〈(ETC) SSL vs TLS 차이점 및 확인방안〉, 《티스토리》, 2018-06-18
- ↑ 〈SSL(TLS)란?〉, 《티스토리》, 2017-04-13
- ↑ 〈SSL/TLS, SSL, TLS Secure Socket Layer, Transport Layer Security 안전 소켓 계층, 전송계층 보안〉, 《정보통신기술용어해설》
- ↑ 〈(네트워크/보안) TLS(SSL) 개념과 기본 동작 원리〉, 《티스토리》, 2020-06-23
- ↑ 〈TLS 프로토콜 정리〉, 《티스토리》, 2012-04-12
- ↑ 개인정보보호, 〈SSL/TLS 알아보기 – TLS 1.3과 프라이버시〉, 《네이버 블로그》, 2018-12-04
- ↑ 〈SSL/TLS 역사와 현재, 그리고 가시성 확보 필요성〉, 《소만사》, 2020-06-18
- ↑ 장구리, 〈HTTPS와 SSL/TLS의 뜻과 차이〉, 《네이버 블로그》, 2019-08-28
- ↑ 오세용 기자, 〈(마소 394호) 알아두면 쓸데없는 신비한 TLS 1.3〉, 《아이티조선》, 2018-10-25
- ↑ RoaZium, 〈https://roazium.tistory.com/66 (정보) SSL과 TLS 차이]〉, 《티스토리》, 2018-06-28
참고자료
- 〈전송 계층 보안(TLS)〉, 《MDN Web Docs》
- 와스프로 GodNR, 〈(ETC) SSL vs TLS 차이점 및 확인방안〉, 《티스토리》, 2018-06-18
- 〈SSL(TLS)란?〉, 《티스토리》, 2017-04-13
- 〈SSL/TLS, SSL, TLS Secure Socket Layer, Transport Layer Security 안전 소켓 계층, 전송계층 보안〉, 《정보통신기술용어해설》
- 〈(네트워크/보안) TLS(SSL) 개념과 기본 동작 원리〉, 《티스토리》, 2020-06-23
- 〈TLS 프로토콜 정리〉, 《티스토리》, 2012-04-12
- 개인정보보호, 〈SSL/TLS 알아보기 – TLS 1.3과 프라이버시〉, 《네이버 블로그》, 2018-12-04
- 〈SSL/TLS 역사와 현재, 그리고 가시성 확보 필요성〉, 《소만사》, 2020-06-18
- 장구리, 〈HTTPS와 SSL/TLS의 뜻과 차이〉, 《네이버 블로그》, 2019-08-28
- 오세용 기자, 〈(마소 394호) 알아두면 쓸데없는 신비한 TLS 1.3〉, 《아이티조선》, 2018-10-25
- RoaZium, 〈https://roazium.tistory.com/66 (정보) SSL과 TLS 차이]〉, 《티스토리》, 2018-06-28
같이 보기