전송 계층 보안(TLS)이란 무엇인가요?

TLS는 다양한 비대칭 및 대칭 암호화 기술을 통해 종단 간 인증, 기밀성 및 데이터 무결성을 제공합니다.이 보호 조치는 이메일, 메시지, Voice over IP(VoIP) 및 가상 사설 네트워크(VPN)를 포함한 다양한 네트워크 통신에 적용됩니다.

TLS는 웹 브라우징을 위한 보안 연결을 구축하는 것으로 널리 알려져 있습니다. 웹 애플리케이션과 대부분의 주요 웹 브라우저 간에 암호화된 데이터 교환을 가능하게 하는 애플리케이션 계층 프로토콜인 하이퍼텍스트 전송 프로토콜 보안(HTTPS) 의 기반이 됩니다.

TLS 암호화 프로토콜에는 TLS 핸드셰이크 프로토콜과 TLS 레코드 프로토콜이라는 두 가지 계층이 있습니다. 핸드셰이크 프로토콜은 웹 서버와 클라이언트(서버에 연결하는 장치) 를 인증합니다. 레코드 프로토콜은 전송용 데이터를 확인하고 보호합니다.

이러한 계층은 컴퓨터 간의 통신 표준을 지정하고 “인터넷을 하나로 묶는 접착제”로 간주되는 프로토콜 제품군인 TCP/Internet Protocol 모델 내에서와 같은 전송 프로토콜 위에 위치합니다.¹

TLS 프로토콜은 Netscape Communications Corporation에서 개발한 SSL(보안 소켓 계층) 프로토콜 표준의 후속 프로토콜입니다. 1996년, 인터넷 엔지니어링 태스크 포스(IETF) 는 공식적으로 SSL 프로토콜을 표준화했습니다.

1999년 1월, IETF는 최신 SSL 버전(SSL 3.0)에 대한 취약점을 개선하고 해결하여 이름을 전송 계층 보안으로 변경했습니다. 이는 RFC(Request for Comments) 2246에서 공식적으로 정의되었습니다. 오늘날 "TLS"와 "SSL"이라는 용어는 종종 TLS/SSL로 같은 의미로 사용되거나 양식화됩니다.

IETF에서 "인터넷에서 가장 중요한 보안 프로토콜"이라고 불리는 TLS는 무단 액세스로부터 온라인 통신을 보호하는 데 매우 중요합니다. 최신 버전인 TLS 1.3은 더욱 강력하고 빠른 보안을 제공하며, 오늘날 안전한 디지털 세계의 중추 역할을 합니다.

전 세계 인구의 약 68%가 온라인에 접속하고 있으며,² 수십억 명이 쇼핑, 뱅킹부터 건강 관리, 개인 커뮤니케이션까지 모든 것을 위해 매일 인터넷에 의존하고 있습니다. 이러한 모든 사용 사례에서 민감한 데이터를 보호하는 것은 필수적입니다. 이는 해커, 변조, 도청 및 데이터 침해, 멀웨어 또는 중간자 공격과 같은 기타 사이버 보안 위협으로부터 데이터를 보호하는 것을 의미합니다.

TLS는 특히 웹사이트의 표준 보안 프로토콜인 HTTPS를 뒷받침합니다. 이제 웹 브라우저에서 친숙한 기능인 HTTPS 자물쇠 아이콘은 웹사이트가 신뢰할 수 있고 안전하다는 신호를 사용자에게 보냅니다.

이 아이콘은 또한 웹 사이트에 유효한 TLS 인증서(SSL 인증서라고도 함)가 있음을 나타냅니다. 인증 기관(CA)에서 발급한 이 디지털 자격 증명은 웹사이트의 ID를 검증하고 암호화된 연결을 활성화합니다. TLS 및 HTTPS 사용 규모를 설명하자면, 한 주요 TLS 인증서 공급자는 시간당 340,000개 이상의 인증서를 발급합니다. 

TLS는 안전한 채널의 세 가지 핵심 속성을 보장함으로써 인터넷 통신 보안을 확보합니다.

전송 계층 보안은 전송된 정보를 보호하기 위해 암호화 프로세스에 의존하기 때문에 효과적입니다.

암호학은 “숨겨진”을 의미하는 그리스어 “kryptos”에서 유래했습니다. 암호의 주 목적은 암호화를 통해 통신을 보호하고 숨기는 것입니다. 암호화는 복잡한 알고리즘을 사용하여 읽을 수 있는 메시지(평문)를 암호화된 메시지(암호문)로 변환하는 과정입니다. 암호문은 특정 키를 사용하여 인증된 수신자만 읽을 수 있는 형식으로 해독할 수 있습니다.

TLS 암호화와 같은 암호화의 맥락에서 키는 임의의 숫자 또는 문자 문자열입니다. 암호화 알고리즘과 함께 사용하면 정보를 암호화(잠금)하고 해독(잠금 해제)합니다. 네트워크를 통해 전송되는 데이터를 암호화하고 해독하는 데 사용되는 알고리즘은 일반적으로 비밀 키 암호화와 공개 키 암호화의 두 가지 카테고리로 나뉩니다.

대칭 암호화 또는 대칭 키 암호화라고도 하는 이 시스템은 민감한 데이터를 암호화하고 복호화하기 위한 단일 공유 키를 생성합니다. 대칭 암호화 시스템은 간단하고 효율적이지만, 안전한 키 교환과 키 관리가 필요합니다.

TLS 세션에서 전송되는 대부분의 민감한 데이터는 비밀 키 암호화를 사용하여 전송됩니다. TLS는 암호화 해시 함수를 사용하여 프라이버시 및 데이터 무결성을 보장합니다. 해시 함수는 입력 데이터에서 고정 크기 해시 값을 생성합니다. 이 값은 전송 전후에 비교할 수 있는 디지털 지문 역할을 합니다. 해시가 변경된 경우 누군가가 데이터를 변조했다는 의미입니다.

메시지 인증 코드(MAC)는 발신자를 인증한다는 점을 제외하고는 암호화 해시와 비슷합니다. 해시된 메시지에 비밀 키를 적용하며, 결과 해시는 해시 메시지 인증 코드(HMAC)라고 합니다.

비대칭 암호화 또는 공개 키 암호화라고도 하는 이 시스템은 수학적으로 연결된 키 쌍(하나는 공개, 다른 하나는 개인)을 사용하여 데이터를 암호화하고 해독합니다. 이를 통해 사람과 시스템은 비밀 키를 미리 공유하지 않고도 민감한 정보를 교환할 수 있습니다. 우편함과 비슷합니다. 누구나 편지를 넣을 수 있지만 소유자만이 잠금을 해제하고 내용물을 회수할 수 있습니다.

이러한 능력은 공개 키 인프라(PKI)와 통합될 때 신뢰 구축에 도움을 줍니다. 예를 들어, 공개 키 인증서(디지털 인증서 또는 SSL/TLS 인증서라고도 함)는 인증 기관을 통해 공개 키를 검증된 신원과 연결합니다.

또한 이들은 디지털 서명의 기반을 제공합니다. 디지털 서명은 TLS에서 클라이언트 또는 웹 서버를 인증하는 데 사용되는 디지털 인증서의 구성 요소입니다. 메시지에 대한 암호화 해시가 생성되면, 해당 해시는 발신자의 개인 키로 암호화됩니다.

이 암호화된 해시는 디지털 서명입니다. 서명은 누구나 공개 키를 사용하여 확인할 수 있으므로 발신자의 ID와 데이터 무결성을 확인할 수 있습니다.

TLS 프로토콜에는 TLS 핸드셰이크 프로토콜과 TLS 레코드 프로토콜이라는 두 개의 하위 프로토콜이 있습니다. 정확한 단계는 TLS 버전에 따라 다를 수 있습니다.

TLS 핸드셰이크는 클라이언트와 웹 서버 간에 보안 연결을 설정합니다. 공개 키 암호화를 사용하여 서버(때로는 클라이언트)는 디지털 인증서를 통해 인증됩니다. 그런 다음 클라이언트와 서버는 암호 그룹(암호화 알고리즘 집합)에 동의하고 키 교환을 수행하여 공유 세션 키(암호화 및 해싱을 위한 비밀 키)를 안전하게 설정합니다.

세션 키가 설정되면 보안 세션이 설정된 것으로 간주됩니다. 이 시점부터 공개 키 암호화는 더 이상 사용되지 않으며 전송되는 모든 후속 데이터는 비밀 키 암호화를 사용하여 암호화 및 인증됩니다.

(자세한 내용은 "TLS 핸드셰이크의 과정은 무엇입니까?"를 참조하십시오.)

레코드 프로토콜은 TLS 연결 중에 전송되는 데이터를 보호하는 역할을 합니다. 이를 위해 핸드셰이크 중에 협상된 암호군과 키를 데이터 보호 방법에 대한 일종의 레시피로 사용합니다.

암호 스위트는 키 교환, 암호화, 메시지 인증에 사용할 알고리즘을 정의합니다. 대칭(비밀) 키는 송신 데이터를 암호화하고 수신 데이터를 복호화하는 데 사용됩니다. 이러한 키는 데이터의 무결성을 검증하는 메시지 인증 코드를 생성하는 데에도 사용됩니다.

이러한 메커니즘을 통해 레코드 프로토콜은 연결의 인증, 무결성 및 기밀성을 보장합니다.

TLS 핸드셰이크의 정확한 과정은 TLS 버전에 따라 다릅니다. 이 과정은 약 200~300밀리초, 또는 최소 100밀리초가 소요될 수 있습니다. 물론 정확한 소요 시간은 지연 시간, 왕복 시간(RTT), 서버 성능 및 기타 네트워크 요인에 따라 달라집니다.

이 일러스트레이션은 TLS 1.3을 사용합니다. TLS 1.3은 가장 빠르고, 가장 최신이며, 가장 안전한 TLS 버전입니다.

클라이언트는 ECDHE(Elliptic Curve Diffie-Hellman Ephemeral) 키 교환 방법을 사용하여 지원되는 TLS 버전(TLS 1.3), 암호 그룹, 임의 바이트 문자열(client_random) 및 임시 공유 키가 포함된 ClientHello 메시지를 보냅니다.

서버는 선택된 암호 그룹, 또 다른 난수 바이트 문자열(server_random) 및 자체 임시 공유 키를 포함하는 ServerHello 메시지로 응답합니다. 이 단계에서는 키 교환 매개변수를 설정합니다.

이제 양 당사자는 ECDHE를 사용하여 공유 암호를 계산할 수 있습니다. 이 공유 암호는 핸드셰이크 키를 파생하는 데 사용됩니다.

그런 다음 서버는 디지털 인증서, CertificateVerify 메시지(개인 키로 서명됨) 및 완료 메시지(핸드셰이크 키로 암호화됨)를 보냅니다.

(선택 사항: 서버에 클라이언트 인증이 필요한 경우 CertificateRequest를 보냅니다. 그러면 클라이언트는 해당 인증서와 CertificateVerify 메시지로 응답합니다.)

클라이언트는 서버의 인증서가 신뢰할 수 있는 인증 기관에서 발급되었는지, 유효한지, 취소되지 않았는지, 그리고 도메인이 일치하는지 확인합니다. 또한 서버의 공개 키로 서버의 CertificateVerify 메시지를 검증하고 핸드셰이크 키로 Finished 메시지를 검증합니다.

클라이언트는 핸드셰이크 키를 사용하여 자체 완료 메시지를 보내고 핸드셰이크가 완료된 것으로 확인됩니다.

이 시점에서 양측은 서로의 신원을 인증하고 공유 비밀 키를 공유한 상태입니다. 이제 대칭 암호화를 사용하여 메시지를 교환할 수 있습니다.

키 교환 방법은 사용자가 암호화 키를 안전하게 교환할 수 있도록 합니다. TLS 구현에 사용되는 여러 가지 주요 키 교환 방법은 다음과 같습니다.

Diffie-Hellman은 가장 일반적인 키 교환 방법 중 하나입니다. 이는 서로에 대한 사전 지식 없이도 두 당사자가 안전하지 않은 채널을 통한 보안 통신을 위한 공유 비밀 키를 생성할 수 있도록 하는 비대칭 키 교환 프로토콜입니다. 보안은 이산 로그 문제를 푸는 난이도에 달려 있습니다. 이산 로그 문제는 복잡한 수학 문제로, 공유된 비밀을 해독하는 것을 계산적으로 불가능하게 만듭니다.

Diffie-Hellman 키 교환에는 다음과 같은 여러 변형이 있습니다.

• Diffie-Hellman Ephemeral(DHE): DHE에서 "임시(Ephemeral)"는 각 세션에 대해 임시 또는 일회용 키가 생성됨을 의미합니다. 이는 전방 비밀성을 제공하여 장기 키의 손상이 과거 세션을 손상시키지 않도록 합니다. DHE는 일반적으로 TLS 1.2에서 사용되지만 TLS 1.2는 DH와 DHE를 모두 지원합니다.
  
  
• Elliptic Curve Diffie-Hellman(ECDH): ECDH는 DH와 유사하지만 타원 곡선 암호화를 사용하여 더 작은 키 크기로 더 큰 보안을 제공합니다. 따라서 ECDH 계산은 더 빠르고 리소스 집약도가 낮습니다. 그러나 비임시 암호군은 순방향 비밀성이 부족하기 때문에 IETF에서 권장하지 않습니다.
  
  
• Elliptic Curve Diffie-Hellman Ephemeral(ECDHE): 각 세션에 대해 임시 키가 생성되어 정방향 비밀성을 제공하는 ECDH의 임시 버전입니다. 이는 TLS 1.3의 필수 키 교환 방법입니다.

RSA는 키 쌍을 생성하기 위해 큰 소수를 인수분해하는 수학적 복잡성에 의존하는 비대칭 암호화 알고리즘입니다. 암호화 및 복호화에 공개-개인 키 쌍을 사용하므로 안전한 데이터 전송 및 디지털 서명에 적합합니다. RSA는 보안 문제로 인해 키 교환을 위해 TLS 1.3에서 지원되지 않습니다. 즉, 순방향 비밀성을 제공하지 않습니다. 그러나 인증에는 사용할 수 있습니다.

PSK는 TLS 세션 전에 보안 채널을 사용하여 두 당사자 간에 사전에 공유된 비밀 공유 키입니다. 사용자는 한번의 TLS 핸드셰이크 중에 PSK를 설정한 다음 다른 핸드셰이크에서 PSK를 사용하여 새 연결을 설정할 수 있습니다. 이를 PSK를 사용한 세션 재개라고 합니다. 순방향 기밀성을 제공하기 위해 DHE 또는 ECDHE와 함께 PSK를 사용하는 것이 좋습니다.

1999년, TLS 1.0의 초기 릴리스(SSL 버전 3.0으로의 업그레이드) 이후 IETF는 세 가지 후속 TLS 버전을 릴리스했습니다.

• 2006년 4월 RFC 4346에 명시된 TLS 1.1: 이 버전에는 사소한 보안 및 편집 개선 사항과 설명이 포함되어 있습니다.
  
  
• 2008년 8월 RFC 5246에 명시된 TLS 1.2: 이 버전은 TLS 1.1의 업데이트로, 암호화 알고리즘 협상을 위한 유연성이 눈에 띄게 개선되었습니다.
  
  
• TLS 1.3, RFC 8446에 명시, 2018년 8월: 이 최신 업데이트는 제로 라운드 트립 타임(0-RTT)을 통한 지연 시간 감소와 협상 효율화 등의 변경 사항을 통해 보안, 성능, 프라이버시를 향상했습니다.

TLS 1.3은 이전 버전과의 호환성 모드로 구현할 수 있지만 이전 TLS 버전과 직접 호환되지는 않는다는 점에 유의하여야 합니다.