검수요청.png검수요청.png

"TLS"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
잔글 (같이 보기)
1번째 줄: 1번째 줄:
'''TLS'''(티엘에스)란 "Transport Layer Security"의 약자로서, 네트워크를 통한 데이터 통신에서 전송 정보를 보호하기 위해 사용하는 보안 유지 [[프로토콜]]이다. '''전송계층보안'''<!--전송 계층 보안-->이라고 한다. 기존의 [[SSL]] 3.0 버전을 기초로 TLS를 만들었다.
+
'''TLS'''(티엘에스)란 "Transport Layer Security"의 약자로서, [[네트워크]]를 통한 데이터 통신에서 전송 정보를 보호하기 위해 사용하는 보안 유지 [[프로토콜]]이다. '''전송계층보안'''<!--전송 계층 보안-->이라고 한다. 기존의 [[SSL]] 3.0 버전을 기초로 TLS를 만들었다.
  
 
== 개요 ==
 
== 개요 ==
[[웹브라우저]], [[이메일]], [[메신저]], [[인터넷전화]]와 [[VoIP]] 등 네트워크를 통해 정보를 전송하는 경우, 정보를 보내는 측과 받는 측이 통신하여 어떤 암호화 알고리즘을 사용할 것인지를 정하고 공개키 기반의 암호키를 교환한 후에 실제 데이터를 암호화하여 전송하는 방식이다. 중간에 제3 자가 전송 내용을 가로채더라도 암호를 풀지 못해 정보를 안전하게 보호할 수 있다. TLS는 응용 프로그램이 네트워크상에서 안전하게 통신하기 위해 사용되는 프로토콜로, 이메일, 웹 브라우징, 메세징, 그리고 다른 프로토콜들의 감청을 통한 정보의 변형을 방지한다.<ref name="티"> 〈[https://developer.mozilla.org/ko/docs/Glossary/TLS 전송 계층 보안(TLS)]〉, 《MDN Web Docs》 </ref> SSL과 TLS는 모두 웹 서버와 사용자의 웹 브라우저 간 통신을 암호화하는 데 사용되는 프로토콜이다. 공개키와 개인키를 교환하여 보안 세션을 생성하여 통신을 암호화하는 방식을 사용한다. TLS는 맥(MAC) 함수 생성을 위해 다른 암호화 알고리즘을 사용하고, 이전 버전의 SSL보다 많은 경고 코드를 포함하고 있다. SSL(Secure Sockets Layer)은 보안 소켓 계층이라는 뜻으로, 인터넷을 통해 전달되는 정보 보안의 안전한 거래를 허용하기 위해 Netscape 사에서 개발한 인터넷 통신 규약 프로토콜이다. TLS는 SSL 3.0을 기초로 하여 IETF가 만든 프로토콜로, SSL 3.0을 보다 안전하게 하고, 프로토콜의 스펙을 더 정확하고 안정성을 높이는 목적으로 고안되었다.<ref name="에">와스프로 GodNR, 〈[https://waspro.tistory.com/161 (ETC) SSL vs TLS 차이점 및 확인방안]〉, 《티스토리》, 2018-06-18 </ref>  
+
[[웹브라우저]], [[이메일]], [[메신저]], [[인터넷전화]]와 [[VoIP]] 등 네트워크를 통해 정보를 전송하는 경우, 정보를 보내는 측과 받는 측이 통신하여 어떤 암호화 알고리즘을 사용할 것인지를 정하고 공개키 기반의 암호키를 교환한 후에 실제 데이터를 암호화하여 전송하는 방식이다. 중간에 제3 자가 전송 내용을 가로채더라도 암호를 풀지 못해 정보를 안전하게 보호할 수 있다. TLS는 응용 프로그램이 네트워크상에서 안전하게 통신하기 위해 사용되는 프로토콜로, 이메일, 웹 브라우징, 메세징, 그리고 다른 프로토콜들의 감청을 통한 정보의 변형을 방지한다.<ref name="티"> 〈[https://developer.mozilla.org/ko/docs/Glossary/TLS 전송 계층 보안(TLS)]〉, 《MDN Web Docs》 </ref> 보안 소켓 계층(Secure Sockets Layer, SSL)과 TLS는 모두 [[서버]]와 사용자의 웹 브라우저 간 통신을 암호화하는 데 사용되는 프로토콜이다. 공개키와 개인키를 교환하여 보안 세션을 생성하여 통신을 암호화하는 방식을 사용한다. TLS는 맥(MAC) 함수 생성을 위해 다른 암호화 알고리즘을 사용하고, 이전 버전의 보안 소켓 계층(SSL)보다 많은 경고 코드를 포함하고 있다. 보안 소켓 계층(SSL)은 인터넷을 통해 전달되는 정보 보안의 안전한 거래를 허용하기 위해 [[넷스케이프]](Netscape)사에서 개발한 인터넷 통신 규약 프로토콜이다. TLS는 SSL 3.0을 기초로 하여 국제 인터넷 표준화 기구(IETF)가 만든 프로토콜로, SSL 3.0을 보다 안전하게 하고, 프로토콜의 스펙을 더 정확하고 안정성을 높이는 목적으로 고안되었다.<ref name="에">와스프로 GodNR, 〈[https://waspro.tistory.com/161 (ETC) SSL vs TLS 차이점 및 확인방안]〉, 《티스토리》, 2018-06-18 </ref>  
  
 
== 특징 ==
 
== 특징 ==
SSL과 TLS는 모두 네트워크 우선 보안을 제공하는 암호화 프로토콜을 소규모 클라이언트, 서버 프로토콜이다. 서버와 클라이언트가 TLS로 통신을 할 때, 어떠한 제3 자도 메시지를 변형시키거나 감청할 수 없도록 한다. 모든 브라우저는 TLS를 지원하고, 안전한 연결을 하기 위해서 유효한 디지털 인증서를 제공하는 것을 요구한다.<ref name="티"> 〈[https://developer.mozilla.org/ko/docs/Glossary/TLS 전송 계층 보안(TLS)]〉, 《MDN Web Docs》 </ref> 상대 사이트에 대한 신뢰성을 인증하고, 다양한 함호화 알고리즘을 이용하여 메시지를 암호화한다. 또한, 송수신 메시지에 대한 체크섬 기능이 있고, 변조를 방지한다. 지원 프로토콜로는 HTTPS, 텔넷(Telnet), POP3S, SFTP가 있다.<ref> 〈[https://devdic.tistory.com/20 SSL(TLS)란?]〉, 《티스토리》, 2017-04-13 </ref> 그리고 응용 계층과 전송 계층 사이에 있다.<ref name="엘">장구리, 〈[https://m.blog.naver.com/hai0416/221623579719 HTTPS와 SSL/TLS의 뜻과 차이]〉, 《네이버 블로그》, 2019-08-28 </ref>
+
보안 소켓 계층(SSL)과 TLS는 모두 네트워크 우선 보안을 제공하는 암호화 프로토콜을 소규모 클라이언트, 서버 프로토콜이다. 대부분의 다른 보안 프로토콜은 운영체제 등에 밀접하게 관련되어있지만, 응용 프로그램에서 자체적으로 구현이 가능하다. 응용 계층과 전송 계층 사이에 위치하나, 전송계층과 더 밀접하게 동작하고, 소켓 지향적인 프로토콜이다. 서버와 클라이언트가 TLS로 통신을 할 때, 어떠한 제3 자도 메시지를 변형시키거나 감청할 수 없도록 한다. 모든 브라우저는 TLS를 지원하고, 안전한 연결을 하기 위해서 유효한 디지털 인증서를 제공하는 것을 요구한다.<ref name="티"></ref> 상대 사이트에 대한 신뢰성을 인증하고, 다양한 암호화 알고리즘을 이용하여 메시지를 암호화한다. 또한, 송수신 메시지에 대한 체크섬(checksum) 기능이 있고, 변조를 방지한다. 지원 프로토콜로는 [[HTTPS]], [[텔넷]](Telnet), [[POP3S]], [[SFTP]]가 있다.<ref> 〈[https://devdic.tistory.com/20 SSL(TLS)란?]〉, 《티스토리》, 2017-04-13 </ref> TLS는 공개키 인증서를 이용하여 서버와 클라이언트의 상호 인증을 한다. 즉, 클라이언트와 서버 두 응용 간에 상대방에 대해 인증을 한다. 메시지 인증 코드 HMAC에 의한 메시지 무결성을 제공한다. 또한, 메시지를 압축한다. 디폴트는 널(Null)로, 무압축이다. 압축 알고리즘은 미리 정해져 있지 않고, 협상으로 지정이 가능하다. 암호화용 세션 키를 생성하기 위한 키를 교환한다. 생성된 공유 비밀키에 의해 암호화된 종단 간의 안전한 연결 통로를 제공한다.<ref> 〈[http://www.ktword.co.kr/abbr_view.php?m_temp1=1957 SSL/TLS, SSL, TLS Secure Socket Layer, Transport Layer Security 안전 소켓 계층, 전송계층 보안]〉, 《정보통신기술용어해설》 </ref>
  
== 핸드쉐이크 ==
+
== 동작 방식 ==
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 메시지를 보내 각자의 핸드쉐이크 과정이 끝났음을 알린다.<ref name="에">와스프로 GodNR, 〈[https://waspro.tistory.com/161 (ETC) SSL vs TLS 차이점 및 확인방안]〉, 《티스토리》, 2018-06-18 </ref>
+
=== 핸드쉐이크 ===
 +
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 메시지를 보내 각자의 핸드쉐이크 과정이 끝났음을 알린다.<ref name="에"></ref>
 +
 
 +
=== TLS 1.3 ===
 +
구조적인 취약점을 없애기 위해 설계되었고, 강화된 보안성과 프라이버시, 개선된 성능을 제공한다. 핸드쉐이크 단계에서 인증서를 암호화하고, 무결성을 검증함으로써 중간자 공격으로 협상 내용을 취약하게 변경하는 다운그레이드 공격의 방어가 가능해졌고, 불필요하고 안전하지 않은 암호화 알고리즘을 제거하여 보안성이 강화되었다. 또한, TLS 1.2 이하 버전에서 핸드쉐이크 과정에서 2회의 왕복 시간(Round Trip Time, RTT)를 거쳐야 했지만, 이 과정을 단순화시켜 1회로 줄여 성능을 향상했다. 세션을 재개하면, TLS 1.2 이하에서는 1회의 왕복 시간으로 동작하지만, TLS 1.3에서는 0회의 왕복시간으로 동작하는 모드를 지원한다. 즉, 첫 TLS 핸드쉐이크를 완료한 후, 서버와 클라이언트에 공유된 암호키를 로컬에 저장하고, 세션 재개 시 키를 사용하여 첫 번째 요청에서 HTTP를 포함하여 서버로 보낸다. 일반 HTTP와 동일한 지연 시간을 갖게 된다는 장점이 있지만, 응답 공격 등 보안상의 우려가 있어 주의가 필요하다. 그리고 SNI(Server Name Indication) 정보를 암호화하는 ESNI(Encrypted SNI)에 대한 드래프트가 나와 있어 프라이버시를 강화하였다. SNI는 TLS 확장 표준의 하나로, 동일한 IP와 포트를 사용하는 하나의 서버에서 여러 도메인을 가진 사이트를 운영할 경우 도메인 별로 각각의 인증서를 사용할 수 있게 해주는 필드이다.<ref>개인정보보호, 〈[https://blog.naver.com/n_privacy/221412043898 SSL/TLS 알아보기 – TLS 1.3과 프라이버시]〉, 《네이버 블로그》, 2018-12-04 </ref>
  
 
== 비교 ==
 
== 비교 ==
개발하는 서비스 중에서 인터넷의 연결이 필요 없는 서비스는 거의 없다. 이런 서비스는 만든 앱 혹은 웹을 통해 데이터를 받아 서버에 저장한다. 이 데이터에는 굉장히 민감한 정보인 카드 번호, 주소, 심지어 집 거실에 있는 공유기의 맥(MAC) 주소까지 포함되어 있는데 이 정보들이 데이터화되어 전송된다. 중간에 데이터가 조작되거나 변조되지 않도록 암호화하여 데이터를 보내야 한다. 이런 정보를 보내기 위해 HTTP보다는 HTTPS를 사용해야 한다. HTTPS의 안정성은 TLS 프로토콜을 통해 보장된다. HTTPS는 보안용 프로토콜에 HTTP를 얹어서 보안 된 HTTP 통신을 하는 프로토콜이고, SSL과 TLS는 보안 통신을 하기 위한 보안용 프로토콜이다.<ref name="엘"></ref><ref>오세용 기자, 〈[http://it.chosun.com/site/data/html_dir/2018/10/25/2018102501126.html (마소 394호) 알아두면 쓸데없는 신비한 TLS 1.3]〉, 《아이티조선》, 2018-10-25 </ref> SSL과 TLS는 본질적으로 같고, 버전이 다른 정도라고 생각하면 된다. 클라이언트가 사용할 인증서가 없으면, TLS 프로토콜의 경우는 "인증서 없음" 메시지를 보내고, SSL 프로토콜의 경우는 별도의 메시지가 필요 없다. TLS는 주로 맥(MAC)을 적용하지만 SSL은 MD5와 SHA를 사용한다. H-MAC을 사용하면 해시 함수를 아무거나 사용할 수 있다는 장점이 있다. TLS 키를 만들 때 H-MAC 스탠다드와 PRF를 사용한다. 반면 SSL은 RSA Diffie-Hellman, Fortezza/DMS를 사용한다. TLS에서 인증서 확인 메시지는 이미 세션에서 교환된 핸드셰이크 메시지에 들어있다. 반면에 SSL은 따로 보내줘야 한다. TLS에서 Finished 메시지는 PRF를 통해 "Client Finished", "Server Finished"가 같이 생성되는데, SSL에서는 키가 생성되었던 방식과 같은 방법으로 Finished 메시지가 생성된다.<ref>RoaZium, 〈https://roazium.tistory.com/66 (정보) SSL과 TLS 차이]〉, 《티스토리》, 2018-06-28 </ref>
+
개발하는 서비스 중에서 인터넷의 연결이 필요 없는 서비스는 거의 없다. 이런 서비스는 만든 앱 혹은 웹을 통해 데이터를 받아 서버에 저장한다. 이 데이터에는 굉장히 민감한 정보인 카드 번호, 주소, 심지어 집 거실에 있는 공유기의 맥(MAC) 주소까지 포함되어 있는데 이 정보들이 데이터화되어 전송된다. 중간에 데이터가 조작되거나 변조되지 않도록 암호화하여 데이터를 보내야 한다. 이런 정보를 보내기 위해 [[HTTP]]보다는 HTTPS를 사용해야 한다. HTTPS의 안정성은 TLS 프로토콜을 통해 보장된다. HTTPS는 보안용 프로토콜에 HTTP를 얹어서 보안 된 HTTP 통신을 하는 프로토콜이고, 보안 소켓 계층(SSL)과 TLS는 보안 통신을 하기 위한 보안용 프로토콜이다.<ref name="엘">장구리, 〈[https://m.blog.naver.com/hai0416/221623579719 HTTPS와 SSL/TLS의 뜻과 차이]〉, 《네이버 블로그》, 2019-08-28 </ref>><ref>오세용 기자, 〈[http://it.chosun.com/site/data/html_dir/2018/10/25/2018102501126.html (마소 394호) 알아두면 쓸데없는 신비한 TLS 1.3]〉, 《아이티조선》, 2018-10-25 </ref> 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 메시지가 생성된다.<ref>RoaZium, 〈https://roazium.tistory.com/66 (정보) SSL과 TLS 차이]〉, 《티스토리》, 2018-06-28 </ref>
  
 
{{각주}}
 
{{각주}}
  
 
== 참고자료 ==
 
== 참고자료 ==
*
+
* 〈[https://developer.mozilla.org/ko/docs/Glossary/TLS 전송 계층 보안(TLS)]〉, 《MDN Web Docs》
 +
* 와스프로 GodNR, 〈[https://waspro.tistory.com/161 (ETC) SSL vs TLS 차이점 및 확인방안]〉, 《티스토리》, 2018-06-18
 +
* 〈[https://devdic.tistory.com/20 SSL(TLS)란?]〉, 《티스토리》, 2017-04-13
 +
* 〈[http://www.ktword.co.kr/abbr_view.php?m_temp1=1957 SSL/TLS, SSL, TLS Secure Socket Layer, Transport Layer Security 안전 소켓 계층, 전송계층 보안]〉, 《정보통신기술용어해설》
 +
* 장구리, 〈[https://m.blog.naver.com/hai0416/221623579719 HTTPS와 SSL/TLS의 뜻과 차이]〉, 《네이버 블로그》, 2019-08-28
 +
* 개인정보보호, 〈[https://blog.naver.com/n_privacy/221412043898 SSL/TLS 알아보기 – TLS 1.3과 프라이버시]〉, 《네이버 블로그》, 2018-12-04
 +
* 오세용 기자, 〈[http://it.chosun.com/site/data/html_dir/2018/10/25/2018102501126.html (마소 394호) 알아두면 쓸데없는 신비한 TLS 1.3]〉, 《아이티조선》, 2018-10-25
 +
* RoaZium, 〈https://roazium.tistory.com/66 (정보) SSL과 TLS 차이]〉, 《티스토리》, 2018-06-28
  
 
== 같이 보기 ==
 
== 같이 보기 ==

2021년 2월 22일 (월) 10:17 판

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]

동작 방식

핸드쉐이크

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와 동일한 지연 시간을 갖게 된다는 장점이 있지만, 응답 공격 등 보안상의 우려가 있어 주의가 필요하다. 그리고 SNI(Server Name Indication) 정보를 암호화하는 ESNI(Encrypted SNI)에 대한 드래프트가 나와 있어 프라이버시를 강화하였다. SNI는 TLS 확장 표준의 하나로, 동일한 IP와 포트를 사용하는 하나의 서버에서 여러 도메인을 가진 사이트를 운영할 경우 도메인 별로 각각의 인증서를 사용할 수 있게 해주는 필드이다.[5]

비교

개발하는 서비스 중에서 인터넷의 연결이 필요 없는 서비스는 거의 없다. 이런 서비스는 만든 앱 혹은 웹을 통해 데이터를 받아 서버에 저장한다. 이 데이터에는 굉장히 민감한 정보인 카드 번호, 주소, 심지어 집 거실에 있는 공유기의 맥(MAC) 주소까지 포함되어 있는데 이 정보들이 데이터화되어 전송된다. 중간에 데이터가 조작되거나 변조되지 않도록 암호화하여 데이터를 보내야 한다. 이런 정보를 보내기 위해 HTTP보다는 HTTPS를 사용해야 한다. HTTPS의 안정성은 TLS 프로토콜을 통해 보장된다. HTTPS는 보안용 프로토콜에 HTTP를 얹어서 보안 된 HTTP 통신을 하는 프로토콜이고, 보안 소켓 계층(SSL)과 TLS는 보안 통신을 하기 위한 보안용 프로토콜이다.[6]>[7] 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 메시지가 생성된다.[8]

각주

  1. 1.0 1.1 전송 계층 보안(TLS)〉, 《MDN Web Docs》
  2. 2.0 2.1 와스프로 GodNR, 〈(ETC) SSL vs TLS 차이점 및 확인방안〉, 《티스토리》, 2018-06-18
  3. SSL(TLS)란?〉, 《티스토리》, 2017-04-13
  4. SSL/TLS, SSL, TLS Secure Socket Layer, Transport Layer Security 안전 소켓 계층, 전송계층 보안〉, 《정보통신기술용어해설》
  5. 개인정보보호, 〈SSL/TLS 알아보기 – TLS 1.3과 프라이버시〉, 《네이버 블로그》, 2018-12-04
  6. 장구리, 〈HTTPS와 SSL/TLS의 뜻과 차이〉, 《네이버 블로그》, 2019-08-28
  7. 오세용 기자, 〈(마소 394호) 알아두면 쓸데없는 신비한 TLS 1.3〉, 《아이티조선》, 2018-10-25
  8. RoaZium, 〈https://roazium.tistory.com/66 (정보) SSL과 TLS 차이]〉, 《티스토리》, 2018-06-28

참고자료

같이 보기


  검수요청.png검수요청.png 이 TLS 문서는 인터넷에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.