위키원
"TLS"의 두 판 사이의 차이
(새 문서: '''TLS'''(티엘에스)란 "Transport Layer Security"의 약자로서, 네트워크를 통한 데이터 통신에서 전송 정보를 보호하기 위해 사용하는 보안 유지 ...) |
|||
| (사용자 2명의 중간 판 5개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''TLS'''(티엘에스)란 "Transport Layer Security"의 약자로서, | + | '''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> 보안 소켓 계층(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="티"></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> | ||
| + | |||
| + | == 구성 == | ||
| + | 5가지의 프로토콜로 구성되어 있다. 핸드쉐이크 프로토콜(Handshake Protocol), 체인지 사이퍼 스팩 프로토콜(Change Cipher Spec Protocol), 알러트 프로토콜(Alert Protocol), 레코드 프로토콜(Record Protocol), 애플리케이션 데이터(Application Data)로, 핸드쉐이크 프로토콜은 양쪽 간에 연결을 설정할 때 보안 협상을 위한 프로토콜이다. 서버와 클라이언트 간의 상호 인증을 수행하고, 사용할 키 교환 방식, 대칭키 암호방식, HMAC 방식, 압축 방식 등의 보안 속성을 협상한다. 체인지 사이퍼 스팩 프로토콜은 보안 파라미터를 변경하거나 적용할 때 사용한다. 하나의 메시지로 되어 있으며, 값 1을 갖는 한 바이트로 구성된다. 핸드쉐이크 프로토콜에 의해 협상된 압축, 맥(MAC), 암호화 방식 등이 적용됨을 상대방에게 알려준다. 알러트 프로토콜은 오류를 전송할 때 사용되는 프로토콜이다. 경고 메시지는 압축되고, 암호화된다. 프로토콜에 있는 각 메시지는 2바이트로 되어 있다. 레코드 프로토콜은 협상된 보안 파라미터를 이용하여 암호화, 복호화, 무결성 검증 등을 수행하는 프로토콜이다. 메시지를 전송하고, 데이터를 블록으로 나눈다. 때에 따라 데이터를 압축하고, 맥(MAC)을 제공해 암호화하고 그 결과를 전송한다. 그리고 애플리케이션 데이터는 실제 데이터가 전송될 때 사용되는 프로토콜이다.<ref> 〈[https://reakwon.tistory.com/106 (네트워크/보안) TLS(SSL) 개념과 기본 동작 원리]〉, 《티스토리》, 2020-06-23 </ref><ref> 〈[https://whitelka.tistory.com/103 TLS 프로토콜 정리]〉, 《티스토리》, 2012-04-12 </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와 동일한 지연 시간을 갖게 된다는 장점이 있지만, 응답 공격 등 보안상의 우려가 있어 주의가 필요하다. 그리고 [[서버 네임 인디케이션]](Server Name Indication, SNI) 정보를 암호화하는 [[ESNI]](Encrypted SNI)에 대한 드래프트가 나와 있어 프라이버시를 강화하였다. 서버 네임 인디케이션(SNI)은 TLS 확장 표준의 하나로, 동일한 IP와 포트를 사용하는 하나의 서버에서 여러 도메인을 가진 사이트를 운영할 경우 도메인 별로 각각의 인증서를 사용할 수 있게 해주는 필드이다.<ref>개인정보보호, 〈[https://blog.naver.com/n_privacy/221412043898 SSL/TLS 알아보기 – TLS 1.3과 프라이버시]〉, 《네이버 블로그》, 2018-12-04 </ref> | ||
| + | |||
| + | == 보안 목표 == | ||
| + | 예를 들어 앨리스는 자신의 친구인 밥과 통신을 하려고 한다. 이브가 앨리스에게 응답을 보내어 자신이 밥이라고 속일 수 있고, 앨리스가 보낸 메시지를 확인할 수 있다. 또한, 이브는 앨리스가 보낸 메시지를 변경 또는 위조할 수 있다. 따라서 TLS의 보안 목표는 이처럼 앨리스와 밥이 주고받는 통신을 이브가 방해할 수 없게 하는 것이다. 이 보안 위협에 대응하기 위해 앨리스의 상대방이 밥이라는 것을 인증하는 인증성(Authenticity), 앨리스와 밥이 통신을 할 수 있고, 이브는 불가능하게 하는 기밀성(Confidentiality), 앨리스가 보낸 메시지가 변경되지 않았음을 보장하는 무결성(Integrity)의 보안 목표를 세울 수 있다.<ref name="스">Buzzvil, 〈[https://www.mobiinside.co.kr/2019/02/13/buzzvil-tls/ (버즈빌의 누구나 궁금해하는 개발 이야기) 보안 프로토콜, TLS 1.3]〉, 《모비인사이드》, 2019-02-13 </ref> | ||
| + | |||
| + | == 암호 기본 요소 == | ||
| + | 암호화 모음은 여러 구성 요소로 이루어져 있다. 대표적으로 대칭키 암호화, 비대칭 키 암호화, 키 합의 프로토콜, 암호학적 해시함수, 메시지 인증 코드 등이 있다. | ||
| + | |||
| + | === 대칭키 암호화 === | ||
| + | 암호화를 하는 데 사용하는 키와 복호화를 하는 데 사용하는 키가 같은 암호화를 말한다. 수행 속도가 빠르고, 키를 아는 사람만 암호화와 복호화를 할 수 있다는 점에서 기밀성, 그리고 단둘만 키를 가지고 있다면 그 자체로도 약간의 인증성을 제공할 수 있는 장점이 있다. 하지만 멀리 떨어져 있는 두 대상이 안전하지 않은 네트워크를 사이에 두고 같은 키를 어떻게 공유할 것인가가 문제점이다. | ||
| + | |||
| + | === 비대칭 키 암호화 === | ||
| + | 암호화 단계에 사용하는 키와 복호화 단계에 사용하는 키가 다른 암호화를 말한다. 키는 한 쌍으로 구성되는데, 하나의 키로 암호화한 것은 다른 한쪽의 키로 복호화할 수 있다. 일반적으로 하나는 안전하게 보관하는 개인 키로 사용하고, 다른 하나는 공개하는 공개 키로 사용한다. 특정 공개 키에 대한 개인키의 소유를 증명할 수 있는 인증성을 보장하고, 실제 암호화에서 사용할 세션 키를 안전하지 않은 채널을 통해 교환하는 방법으로 사용할 수 있다. 공개키로 암호화한 것은 개인 키를 이용해야만 복호화가 가능하다는 점에서 단방향으로 기밀성을 보장한다. 하지만 암호화와 복호화의 비용이 크기 때문에 일반적인 암호화 통신에는 대칭키 암호화를 사용한다. | ||
| + | |||
| + | === 디지털 인증서 === | ||
| + | 상대방이 통신하고자 하는 대상을 확인하기 위해 디지털 인증서를 사용한다. 디지털 인증서는 모두가 신뢰할 수 있는 제 3자인 인증기관(Certificate Authority, CA)과 비대칭 키 암호화가 필요하다. 밥은 인증기관(CA)에 자신을 다양한 방식으로 증명하고, 자신의 공개 키가 밥의 공개 키가 맞음을 인증하는 인증서를 발급받는다. 이후 앨리스에게 인증서를 주고, 앨리스는 자신이 신뢰할 수 있는 인증기관(CA)이 발급한 인증서인지 확인하고, 맞으면 인증서에 포함된 밥의 공개 키로 데이터를 암호화해서 전달한다. 밥이 이것을 올바르게 복호화하면, 인증기관(CA)이 인증하는 밥의 공개 키에 대응하는 개인키를 가지고 있다는 것이기 때문에 이 과정을 통해 현재 통신하고 있는 상대방을 인증할 수 있다. | ||
| + | |||
| + | === 키 합의 프로토콜 === | ||
| + | 대칭키 암호화를 사용하기 위해 안전하지 않은 네트워크상에서 안전하게 키를 교환할 수 있어야 한다. 이 역할을 하는 것이 키 합의 프로토콜이다. 이 방법에는 크게 두 가지가 있다. 하나는 비대칭 키 암호화 중 대표적인 RSA를 기반으로 한 프로토콜이고, 다른 하나는 디피-헬만 키 합의 프로토콜이다. | ||
| + | |||
| + | ; RSA 키 합의 프로토콜 | ||
| + | 앨리스가 밥의 공개키를 알고 있을 때, 앨리스가 둘의 통신에 사용할 세션 키를 만들어 공개 키로 암호화한 다음 전송한다. 이를 복호화할 수 있는 개인 키를 가지고 있는 사람은 밥뿐이므로, 제 3자인 이브는 세션 키를 얻을 수 없고, 둘은 안전하게 세션 키를 교환하여 보안 채널을 만들 수 있다. 하지만 이 방식에는 새로운 보안 문제가 있다. 밥의 개인 키를 모르는 이브는 둘의 모든 통신을 기록해고, 밥의 개인 키를 알아내면 그동안 기록해 둔 것을 복호화하여 세션 키를 얻는다. 세션 키를 얻으면 둘의 대화 내용을 알아낼 수 있기 때문이다. 개인 키가 유출되고 나면, 둘의 통신이 유출되기 전에 일어났다고 해도 안전하지 않다. 이 상황을 대비하여, 현재만 안전한 것이 아니라, 미래에 개인 키가 유출되어도 안전하게 하는 보안 목표를 순방향 비밀성(Forward Secrecy), 또는 완전 순방향 비밀성(Perfect Forward Secrecy)이라고 한다. | ||
| + | |||
| + | ; 디피-헬만 키 합의 프로토콜 | ||
| + | 안전하지 않은 채널에서 안전하게 세션 키를 만들 수 있게 하고, 순방향 비밀성도 보장한다. 네트워크를 통해 세션 키를 전달하는 것이 아니라, 세션 키를 만들 수 있는 힌트만 네트워크상으로 전달하기 때문에 가능하다. 목표는 앨리스와 밥이 안전하지 않은 통신을 통해 공통의 색을 만드는 것이다. 색의 혼합이 일방향 함수라는 가정이 있다. 즉, 두 색을 섞어 새로운 색을 만들기는 쉽지만, 섞여 있는 두 색을 원래의 색으로 분리하는 것은 어렵다. 앨리스와 밥은 통신에 사용할 색을 공개적으로 정한 후, 각자 비밀 색을 정한다. 직접 비밀 색을 전송하지 않고, 기저 색과 비밀 색을 섞은 결과를 전송한다. 각자 받은 것을 비밀 색과 섞어 공통의 색을 만들 수 있다. 하지만 이브는 기저 색과 다른 색을 가지고도 가정에 의해서 공통의 색을 만들 수 없다. 훗날 비밀 색을 알아내면 공통 색을 만들 수 있기에, 앨리스와 밥은 필요하지 않은 비밀 색을 버린다. 이 방식을 수학적으로 구현한 것이 디피-헬만 키 합의 프로토콜이다. 이 방식을 이용하면, 툴의 통신을 기록해두고, 밥의 개인키를 탈취하더라도 얻을 수 있는 것은 힌트 뿐이기에 복호화할 수 없다. | ||
| + | |||
| + | === 무결성 === | ||
| + | 데이터의 무결성을 제공하기 위해 [[해시 함수]](Hash Function)와 키 있는 해시 함수(Keyed Hash Function)가 있다. | ||
| + | |||
| + | ; 암호학적 해시 함수 | ||
| + | 해시 함수는 어떤 임의의 데이터를 입력으로 받아서 일정한 길이의 데이터로 바꾸어주는 함수를 말한다. 이때 나오는 결과인 일정한 길이의 데이터를 해시 또는 [[해시값]]이라고 한다. 이 중에서 암호학적으로 강점을 가지는 요소들을 가진 해시 함수들을 암호학적 해시 함수라고 한다. 암호학적으로 강점을 가지는 요소에는 해시값을 보고 입력 데이터를 찾기 어렵다는 점, 특정 입력 데이터의 해시값과 해시값을 가지는 다른 데이터를 찾기 어렵다는 점, 같은 해시값을 가지는 서로 다른 두 입력 데이터를 찾기 어렵다는 점이 있다. 이러한 특성으로 무결성을 보장하는 데 사용 한다. | ||
| + | |||
| + | ; 메시지 인증코드 | ||
| + | 키 있는 해시함수의 종류로, 메시지 인증 코드(Message Authentication Code, MAC)는 대칭키 암호화의 개념과 해시 함수를 섞은 형태이다. 키에 따라 메시지를 넣었을 때 나오는 해시값이 달라지는 것이 특징이다. 따라서 키를 모르는 이브는 메시지를 변경하고 그에 맞는 해시값을 계산하여 붙이려고 해도 올바른 해시값을 계산할 수 없으므로, 위조나 변조를 할 수 없다. 키를 알고 있는 사람만이 올바를 해시값을 만들 수 있다는 점에서 메시지가 변조되지 않았다는 무결성을 보장할 수 있고, 해시를 계산하는 데 사용할 키를 가지고 있음을 증명하기 때문에 약한 인증성도 제공한다.<ref name="스"></ref> | ||
| + | |||
| + | == 악용 == | ||
| + | 클라이언트와 서버 사이에서 어떤 정보가 오고 가는지 알 수가 없어서, 한 번 암호화되어 덧입혀져 나가면 정보를 유출해도 기존 보안 솔루션으로는 파악할 수 없다. 즉, 복호화키는 클라이언트와 서버만 알고 있어서 제 3자인 보안 솔루션은 정보가 유출되었는지 알 수가 없다. 또한, 악성코드나 [[랜섬웨어]]는 PDF, 워드, 한글파일 등으로 위장한 실행 파일을 클릭함으로써 감염되는데, 이 외에도 의심스러운 [[URL]]을 클릭하여 감염되기도 한다. 링크에 접속하는 순간, [[드라이브 바이 다운로드]](Drive By Download) 공격으로 악성코드나 랜섬웨어 파일을 자동으로 다운로드받게 된다. 이 파일로 인해 정보 유출과 데이터의 위변조, [[디도스]] 공격으로 악용될 수 있다.<ref> 〈[https://www.somansa.com/introduce/newsevent/ssltls-%EC%97%AD%EC%82%AC%EC%99%80-%ED%98%84%EC%9E%AC-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EA%B0%80%EC%8B%9C%EC%84%B1-%ED%99%95%EB%B3%B4-%ED%95%84%EC%9A%94%EC%84%B1/ SSL/TLS 역사와 현재, 그리고 가시성 확보 필요성]〉, 《소만사》, 2020-06-18 </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://reakwon.tistory.com/106 (네트워크/보안) TLS(SSL) 개념과 기본 동작 원리]〉, 《티스토리》, 2020-06-23 | ||
| + | * 〈[https://whitelka.tistory.com/103 TLS 프로토콜 정리]〉, 《티스토리》, 2012-04-12 | ||
| + | * 개인정보보호, 〈[https://blog.naver.com/n_privacy/221412043898 SSL/TLS 알아보기 – TLS 1.3과 프라이버시]〉, 《네이버 블로그》, 2018-12-04 | ||
| + | * Buzzvil, 〈[https://www.mobiinside.co.kr/2019/02/13/buzzvil-tls/ (버즈빌의 누구나 궁금해하는 개발 이야기) 보안 프로토콜, TLS 1.3]〉, 《모비인사이드》, 2019-02-13 | ||
| + | * 〈[https://www.somansa.com/introduce/newsevent/ssltls-%EC%97%AD%EC%82%AC%EC%99%80-%ED%98%84%EC%9E%AC-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EA%B0%80%EC%8B%9C%EC%84%B1-%ED%99%95%EB%B3%B4-%ED%95%84%EC%9A%94%EC%84%B1/ SSL/TLS 역사와 현재, 그리고 가시성 확보 필요성]〉, 《소만사》, 2020-06-18 | ||
| + | * 장구리, 〈[https://m.blog.naver.com/hai0416/221623579719 HTTPS와 SSL/TLS의 뜻과 차이]〉, 《네이버 블로그》, 2019-08-28 | ||
| + | * 오세용 기자, 〈[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 | ||
== 같이 보기 == | == 같이 보기 == | ||
| 5번째 줄: | 76번째 줄: | ||
* [[SSL]] | * [[SSL]] | ||
* [[OpenSSL]] | * [[OpenSSL]] | ||
| + | * [[넷스케이프]] | ||
| + | * [[HTTPS]] | ||
| + | * [[텔넷]] | ||
| + | * [[TCP]] | ||
| − | {{인터넷| | + | {{인터넷|검토 필요}} |
2021년 2월 22일 (월) 14:03 기준 최신판
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 Protocol), 체인지 사이퍼 스팩 프로토콜(Change Cipher Spec Protocol), 알러트 프로토콜(Alert Protocol), 레코드 프로토콜(Record Protocol), 애플리케이션 데이터(Application Data)로, 핸드쉐이크 프로토콜은 양쪽 간에 연결을 설정할 때 보안 협상을 위한 프로토콜이다. 서버와 클라이언트 간의 상호 인증을 수행하고, 사용할 키 교환 방식, 대칭키 암호방식, HMAC 방식, 압축 방식 등의 보안 속성을 협상한다. 체인지 사이퍼 스팩 프로토콜은 보안 파라미터를 변경하거나 적용할 때 사용한다. 하나의 메시지로 되어 있으며, 값 1을 갖는 한 바이트로 구성된다. 핸드쉐이크 프로토콜에 의해 협상된 압축, 맥(MAC), 암호화 방식 등이 적용됨을 상대방에게 알려준다. 알러트 프로토콜은 오류를 전송할 때 사용되는 프로토콜이다. 경고 메시지는 압축되고, 암호화된다. 프로토콜에 있는 각 메시지는 2바이트로 되어 있다. 레코드 프로토콜은 협상된 보안 파라미터를 이용하여 암호화, 복호화, 무결성 검증 등을 수행하는 프로토콜이다. 메시지를 전송하고, 데이터를 블록으로 나눈다. 때에 따라 데이터를 압축하고, 맥(MAC)을 제공해 암호화하고 그 결과를 전송한다. 그리고 애플리케이션 데이터는 실제 데이터가 전송될 때 사용되는 프로토콜이다.[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]
보안 목표[편집]
예를 들어 앨리스는 자신의 친구인 밥과 통신을 하려고 한다. 이브가 앨리스에게 응답을 보내어 자신이 밥이라고 속일 수 있고, 앨리스가 보낸 메시지를 확인할 수 있다. 또한, 이브는 앨리스가 보낸 메시지를 변경 또는 위조할 수 있다. 따라서 TLS의 보안 목표는 이처럼 앨리스와 밥이 주고받는 통신을 이브가 방해할 수 없게 하는 것이다. 이 보안 위협에 대응하기 위해 앨리스의 상대방이 밥이라는 것을 인증하는 인증성(Authenticity), 앨리스와 밥이 통신을 할 수 있고, 이브는 불가능하게 하는 기밀성(Confidentiality), 앨리스가 보낸 메시지가 변경되지 않았음을 보장하는 무결성(Integrity)의 보안 목표를 세울 수 있다.[8]
암호 기본 요소[편집]
암호화 모음은 여러 구성 요소로 이루어져 있다. 대표적으로 대칭키 암호화, 비대칭 키 암호화, 키 합의 프로토콜, 암호학적 해시함수, 메시지 인증 코드 등이 있다.
대칭키 암호화[편집]
암호화를 하는 데 사용하는 키와 복호화를 하는 데 사용하는 키가 같은 암호화를 말한다. 수행 속도가 빠르고, 키를 아는 사람만 암호화와 복호화를 할 수 있다는 점에서 기밀성, 그리고 단둘만 키를 가지고 있다면 그 자체로도 약간의 인증성을 제공할 수 있는 장점이 있다. 하지만 멀리 떨어져 있는 두 대상이 안전하지 않은 네트워크를 사이에 두고 같은 키를 어떻게 공유할 것인가가 문제점이다.
비대칭 키 암호화[편집]
암호화 단계에 사용하는 키와 복호화 단계에 사용하는 키가 다른 암호화를 말한다. 키는 한 쌍으로 구성되는데, 하나의 키로 암호화한 것은 다른 한쪽의 키로 복호화할 수 있다. 일반적으로 하나는 안전하게 보관하는 개인 키로 사용하고, 다른 하나는 공개하는 공개 키로 사용한다. 특정 공개 키에 대한 개인키의 소유를 증명할 수 있는 인증성을 보장하고, 실제 암호화에서 사용할 세션 키를 안전하지 않은 채널을 통해 교환하는 방법으로 사용할 수 있다. 공개키로 암호화한 것은 개인 키를 이용해야만 복호화가 가능하다는 점에서 단방향으로 기밀성을 보장한다. 하지만 암호화와 복호화의 비용이 크기 때문에 일반적인 암호화 통신에는 대칭키 암호화를 사용한다.
디지털 인증서[편집]
상대방이 통신하고자 하는 대상을 확인하기 위해 디지털 인증서를 사용한다. 디지털 인증서는 모두가 신뢰할 수 있는 제 3자인 인증기관(Certificate Authority, CA)과 비대칭 키 암호화가 필요하다. 밥은 인증기관(CA)에 자신을 다양한 방식으로 증명하고, 자신의 공개 키가 밥의 공개 키가 맞음을 인증하는 인증서를 발급받는다. 이후 앨리스에게 인증서를 주고, 앨리스는 자신이 신뢰할 수 있는 인증기관(CA)이 발급한 인증서인지 확인하고, 맞으면 인증서에 포함된 밥의 공개 키로 데이터를 암호화해서 전달한다. 밥이 이것을 올바르게 복호화하면, 인증기관(CA)이 인증하는 밥의 공개 키에 대응하는 개인키를 가지고 있다는 것이기 때문에 이 과정을 통해 현재 통신하고 있는 상대방을 인증할 수 있다.
키 합의 프로토콜[편집]
대칭키 암호화를 사용하기 위해 안전하지 않은 네트워크상에서 안전하게 키를 교환할 수 있어야 한다. 이 역할을 하는 것이 키 합의 프로토콜이다. 이 방법에는 크게 두 가지가 있다. 하나는 비대칭 키 암호화 중 대표적인 RSA를 기반으로 한 프로토콜이고, 다른 하나는 디피-헬만 키 합의 프로토콜이다.
- RSA 키 합의 프로토콜
앨리스가 밥의 공개키를 알고 있을 때, 앨리스가 둘의 통신에 사용할 세션 키를 만들어 공개 키로 암호화한 다음 전송한다. 이를 복호화할 수 있는 개인 키를 가지고 있는 사람은 밥뿐이므로, 제 3자인 이브는 세션 키를 얻을 수 없고, 둘은 안전하게 세션 키를 교환하여 보안 채널을 만들 수 있다. 하지만 이 방식에는 새로운 보안 문제가 있다. 밥의 개인 키를 모르는 이브는 둘의 모든 통신을 기록해고, 밥의 개인 키를 알아내면 그동안 기록해 둔 것을 복호화하여 세션 키를 얻는다. 세션 키를 얻으면 둘의 대화 내용을 알아낼 수 있기 때문이다. 개인 키가 유출되고 나면, 둘의 통신이 유출되기 전에 일어났다고 해도 안전하지 않다. 이 상황을 대비하여, 현재만 안전한 것이 아니라, 미래에 개인 키가 유출되어도 안전하게 하는 보안 목표를 순방향 비밀성(Forward Secrecy), 또는 완전 순방향 비밀성(Perfect Forward Secrecy)이라고 한다.
- 디피-헬만 키 합의 프로토콜
안전하지 않은 채널에서 안전하게 세션 키를 만들 수 있게 하고, 순방향 비밀성도 보장한다. 네트워크를 통해 세션 키를 전달하는 것이 아니라, 세션 키를 만들 수 있는 힌트만 네트워크상으로 전달하기 때문에 가능하다. 목표는 앨리스와 밥이 안전하지 않은 통신을 통해 공통의 색을 만드는 것이다. 색의 혼합이 일방향 함수라는 가정이 있다. 즉, 두 색을 섞어 새로운 색을 만들기는 쉽지만, 섞여 있는 두 색을 원래의 색으로 분리하는 것은 어렵다. 앨리스와 밥은 통신에 사용할 색을 공개적으로 정한 후, 각자 비밀 색을 정한다. 직접 비밀 색을 전송하지 않고, 기저 색과 비밀 색을 섞은 결과를 전송한다. 각자 받은 것을 비밀 색과 섞어 공통의 색을 만들 수 있다. 하지만 이브는 기저 색과 다른 색을 가지고도 가정에 의해서 공통의 색을 만들 수 없다. 훗날 비밀 색을 알아내면 공통 색을 만들 수 있기에, 앨리스와 밥은 필요하지 않은 비밀 색을 버린다. 이 방식을 수학적으로 구현한 것이 디피-헬만 키 합의 프로토콜이다. 이 방식을 이용하면, 툴의 통신을 기록해두고, 밥의 개인키를 탈취하더라도 얻을 수 있는 것은 힌트 뿐이기에 복호화할 수 없다.
무결성[편집]
데이터의 무결성을 제공하기 위해 해시 함수(Hash Function)와 키 있는 해시 함수(Keyed Hash Function)가 있다.
- 암호학적 해시 함수
해시 함수는 어떤 임의의 데이터를 입력으로 받아서 일정한 길이의 데이터로 바꾸어주는 함수를 말한다. 이때 나오는 결과인 일정한 길이의 데이터를 해시 또는 해시값이라고 한다. 이 중에서 암호학적으로 강점을 가지는 요소들을 가진 해시 함수들을 암호학적 해시 함수라고 한다. 암호학적으로 강점을 가지는 요소에는 해시값을 보고 입력 데이터를 찾기 어렵다는 점, 특정 입력 데이터의 해시값과 해시값을 가지는 다른 데이터를 찾기 어렵다는 점, 같은 해시값을 가지는 서로 다른 두 입력 데이터를 찾기 어렵다는 점이 있다. 이러한 특성으로 무결성을 보장하는 데 사용 한다.
- 메시지 인증코드
키 있는 해시함수의 종류로, 메시지 인증 코드(Message Authentication Code, MAC)는 대칭키 암호화의 개념과 해시 함수를 섞은 형태이다. 키에 따라 메시지를 넣었을 때 나오는 해시값이 달라지는 것이 특징이다. 따라서 키를 모르는 이브는 메시지를 변경하고 그에 맞는 해시값을 계산하여 붙이려고 해도 올바른 해시값을 계산할 수 없으므로, 위조나 변조를 할 수 없다. 키를 알고 있는 사람만이 올바를 해시값을 만들 수 있다는 점에서 메시지가 변조되지 않았다는 무결성을 보장할 수 있고, 해시를 계산하는 데 사용할 키를 가지고 있음을 증명하기 때문에 약한 인증성도 제공한다.[8]
악용[편집]
클라이언트와 서버 사이에서 어떤 정보가 오고 가는지 알 수가 없어서, 한 번 암호화되어 덧입혀져 나가면 정보를 유출해도 기존 보안 솔루션으로는 파악할 수 없다. 즉, 복호화키는 클라이언트와 서버만 알고 있어서 제 3자인 보안 솔루션은 정보가 유출되었는지 알 수가 없다. 또한, 악성코드나 랜섬웨어는 PDF, 워드, 한글파일 등으로 위장한 실행 파일을 클릭함으로써 감염되는데, 이 외에도 의심스러운 URL을 클릭하여 감염되기도 한다. 링크에 접속하는 순간, 드라이브 바이 다운로드(Drive By Download) 공격으로 악성코드나 랜섬웨어 파일을 자동으로 다운로드받게 된다. 이 파일로 인해 정보 유출과 데이터의 위변조, 디도스 공격으로 악용될 수 있다.[9]
비교[편집]
개발하는 서비스 중에서 인터넷의 연결이 필요 없는 서비스는 거의 없다. 이런 서비스는 만든 앱 혹은 웹을 통해 데이터를 받아 서버에 저장한다. 이 데이터에는 굉장히 민감한 정보인 카드 번호, 주소, 심지어 집 거실에 있는 공유기의 맥(MAC) 주소까지 포함되어 있는데 이 정보들이 데이터화되어 전송된다. 중간에 데이터가 조작되거나 변조되지 않도록 암호화하여 데이터를 보내야 한다. 이런 정보를 보내기 위해 HTTP보다는 HTTPS를 사용해야 한다. HTTPS의 안정성은 TLS 프로토콜을 통해 보장된다. HTTPS는 보안용 프로토콜에 HTTP를 얹어서 보안 된 HTTP 통신을 하는 프로토콜이고, 보안 소켓 계층(SSL)과 TLS는 보안 통신을 하기 위한 보안용 프로토콜이다.[10][11] 보안 소켓 계층(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 메시지가 생성된다.[12]
각주[편집]
- ↑ 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
- ↑ 8.0 8.1 Buzzvil, 〈(버즈빌의 누구나 궁금해하는 개발 이야기) 보안 프로토콜, TLS 1.3〉, 《모비인사이드》, 2019-02-13
- ↑ 〈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
- Buzzvil, 〈(버즈빌의 누구나 궁금해하는 개발 이야기) 보안 프로토콜, TLS 1.3〉, 《모비인사이드》, 2019-02-13
- 〈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
같이 보기[편집]
