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

개발 : 프로그래밍, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷 □■⊕, 모바일, 사물인터넷, 게임, 메타버스, 디자인
인터넷 PC통신 • 그누텔라 • 네트워크 • 다크넷 • 다크웹 • 딥웹 • 무선인터넷 • 슈퍼피어 • 스타링크 • 아르파넷 • 아이투피(I2P) • 엑스트라넷 • 오버레이 네트워크 • 오투오(O2O) • 오프라인 • 온라인 • 온오프라인 • 유선인터넷 • 인터넷 • 인트라넷 • 초고속 인터넷 • 토어(토르) • 표면웹 • 프리넷 • 피투피(P2P) • 하이브리드 피투피(P2P) • 홈네트워크
인터넷 기술 ARP • DNS • FTP • G-클라우드 • HTTP • HTTPS • IPFS • IPv4 • IPv6 • IRC • IRI • ISBN • LDAP • MOIP • OpenSSL • OSI 7 계층 • RFC • RFID • SFTP • SOAP • SSH • SSL • SSO • TCP • TCP/IP • TLS • UCI • UDP • URI • URL • URN • VoIP • 강화 내부 게이트웨이 라우팅 프로토콜 • 검색 • 검색엔진 • 게이트웨이 • 경계 경로 프로토콜 • 내부 게이트웨이 라우팅 프로토콜 • 다운로드 • 데몬 • 라우팅 정보 프로토콜 • 백엔드 • 사물인터넷 • 서버 • 서버-클라이언트 • 서브넷마스크 • 세션 • 스트리밍 • 식별자 • 아이피(IP) • 업로드 • 에듀테크 • 온프레미스 • 원격 프로시저 호출(RPC) • 유비쿼터스 • 인터넷 기술 • 자율시스템 • 정보기술 • 정보통신 • 채팅 • 챗봇 • 최단경로 우선 프로토콜(OSPF) • 쿠키 • 크롤링 • 클라이언트 • 키워드 • 텔넷 • 토폴로지 • 트래픽 • 패킷 • 포털 • 포트 • 프런트엔드 • 프로토콜 • 프록시 • 해시태그
이메일 IMAP • POP3 • SMTP • 계정메일 • 네이버 메일 • 다음 메일 • 센드메일 • 스팸 • 스팸메일 • 스팸필터링 • 아웃룩 익스프레스 • 야후 메일 • 웹메일 • 이메일 • 지메일 • 카카오 메일 • 한메일 • 핫메일
웹 KWCAG • WCAG • 서핑 • 시맨틱 웹 • 오프라인 웹 • 웹 • 웹 1.0 • 웹 2.0 • 웹 3.0 • 웹개방성 • 웹서비스 • 웹접근성 • 웹접근성 인증마크 • 웹주소 • 웹표준 • 웹호환성 • 피드
웹사이트 BBS • GNB • LNB • UI/UX • 게시판 • 관리자 사이트 • 그래픽 사용자 인터페이스(GUI) • 누리집 • 대시보드 • 드롭다운 메뉴 • 랜딩 템플릿 • 랜딩 페이지 • 리더보드 • 마이홈피 • 메뉴 • 모달창 • 미니홈피 • 방명록 • 배너 • 사용자 경험(UX) • 사용자 인터페이스(UI) • 섹션 • 왼쪽메뉴 • 웹기획 • 웹사이트 • 웹페이지 • 인터페이스 • 쪽지 • 커뮤니티 • 탑메뉴 • 탭메뉴 • 템플릿 • 팝업 • 페이지 • 페이지뷰 • 햄버거 메뉴 • 호버 • 홈페이지 • 화면
웹브라우저 넷스케이프 • 모자이크 • 브라우저 • 브레이브 브라우저 • 블록체인 브라우저 • 사파리 • 삼성인터넷 • 스윙 • 엣지 • 오시리스 • 오페라 • 웨일 • 웹브라우저 • 인터넷 익스플로러(IE) • 크롬 • 파이어폭스 • 판도브라우저
인터넷 서비스 구글 • 구글 미트 • 구글챗 • 구글 행아웃 • 깃허브 • 네아로 • 네이버 • 네이버 웹툰 • 네이버 카페 • 넷플릭스 • 다음 • 라이코스 • 레진코믹스 • 메일루 • 멜론 • 바이두 • 바이트댄스 • 비트토렌트 • 빌리빌리 • 빙 • 소리바다 • 스포티파이 • 아마존 웹서비스(AWS) • 애플 • 야후 • 야후재팬 • 얀덱스 • 에버노트 • 에어비앤비 • 왓챠 • 웹소설 • 웹툰 • 유튜브 • 인스타툰 • 인터넷 서비스 • 인터넷카페 • 잼라이브 • 줌 • 카카오 • 카카오 웹툰 • 카카오페이지 • 탑툰 • 텐센트 • 팟캐스트 • 패스 • 페이오니아 • 페이팔 • 해시넷 • 화상통화 • 화상회의
인터넷쇼핑 11번가 • 그립 • 네이버 쇼핑 • 네이버 쇼핑 라이브 • 라이브방송 • 라이브커머스 • 모바일쇼핑 • 스쉐라이브 • 스타일쉐어 • 아마존 • 알리바바 • 오픈마켓 • 옥션 • 온라인쇼핑 • 위메프 • 이베이 • 인터넷쇼핑 • 인터파크 • 전자상거래 • 지마켓 • 징동닷컴 • 카카오 쇼핑 • 카카오 쇼핑 라이브 • 커머스 • 쿠팡 • 쿠팡 라이브 • 타오바오 • 티몬
소셜 네트워크 SNS(소셜 네트워크 서비스) • 구글 블로거 • 네이버 밴드 • 네이버 블로그 • 디시인사이드 • 링크드인 • 마이크로블로그 • 맞팔 • 브런치스토리 • 블로그 • 소셜 네트워크 • 엑스 (트위터) • 웨이보 • 인스타그램 • 트루스소셜 • 티스토리 • 팔로우 • 페이스북 • 플리커 • 핀터레스트
메신저 골프메신저 • 님버즈 • 대화방 • 두레이 • 디스코드 • 딩톡 • 라인 • 라인웍스 • 마이크로소프트 팀즈 • 메신저 • 버디버디 • 스냅챗 • 스노우 • 스카이프 • 슬랙 • 아이씨큐(ICQ) • 왓츠앱 • 웹메신저 • 위챗 • 잔디 • 직톡 • 카카오워크 • 카카오톡 • 카톡방 • 큐큐(QQ) • 탱고 • 텔레그램 • 틱톡 • 페이스북 메신저 • 플로우
도메인 네임서버 • 다국어도메인 • 도메인 • 레지스트라 • 레지스트리 • 아이피 • 인터넷주소 • 인터넷키워드 • 한글인터넷주소 • 후이즈
호스팅 메일호스팅 • 서버호스팅 • 웹호스팅 • 코로케이션 • 클라우드 • 클라우드 네이티브 • 파킹 • 포워딩 • 호스팅
위키 구스위키 • 나무위키 • 노스모크 • 더위키 • 디시위키 • 리그베다위키(엔하위키) • 리브레위키 • 미디어위키 • 바다위키 • 백괴사전 • 아이티위키 • 알파위키 • 엔하계 위키 • 요다위키 • 우만위키 • 위키 • 위키낱말사전 • 위키독스 • 위키문법 • 위키문서 • 위키문헌 • 위키미디어재단 • 위키백과 • 위키스 • 위키엔진 • 위키원 • 위키원드 • 위키트리 • 위키휴가 • 제이위키 • 제타위키 • 중국위키 • 팬덤(위키아) • 한국어 위키백과 • 한국위키미디어협회 • 항공위키
인터넷 사용자 가입 • 가입자 • 강퇴 • 계정 • 관리자 • 네트워크 관리자 • 네티즌 • 누리꾼 • 대기자 • 데이터베이스 관리자 • 등록자 • 디지털 원패스 • 로그아웃 • 로그인 • 방문자 • 블로거 • 블록체인 관리자 • 비회원 • 사용자 • 사이트 관리자 • 서버관리자 • 시삽 • 시스템 관리자 • 아이디(ID) • 웹관리자 • 웹마스터 • 유튜버 • 접속자 • 차단 • 최고관리자 • 탈퇴 • 탈퇴자 • 회원 • 휴면 • 휴면계정
인터넷 단체 IANA • ICANN • W3C • 다르파 • 유럽입자물리연구소(CERN)
위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반
원본 주소 "http://wiki1.kr/index.php?title=TLS&oldid=422993"