TLS편집자 확인

SSL은 1990년대 초 넷스케이프 커뮤니케이션스에 의해 개발된 최초의 널리 채택된 인터넷 보안 프로토콜이다. SSL 1.0은 공개되지 않았으며, SSL 2.0(1995년)과 SSL 3.0(1996년)이 실제 표준으로 자리 잡았다. 그러나 SSL 2.0에는 설계상의 심각한 결함이 다수 발견되어 빠르게 SSL 3.0으로 대체되었다.

SSL 3.0의 성공에도 불구하고, 프로토콜을 더욱 강화하고 공개 표준 기구의 관리를 받기 위해 IETF가 작업을 인수했다. IETF는 SSL 3.0을 기반으로 하여 공식적인 인터넷 표준을 개발했으며, 이 과정에서 프로토콜의 이름을 전송 계층 보안(TLS)으로 변경했다. 이로써 1999년에 발표된 RFC 2246이 TLS 1.0의 표준을 정의하게 되었다.

TLS 1.0은 SSL 3.0과 매우 유사했지만, 몇 가지 중요한 보안 강화와 호환성 끊기가 이루어졌다. 주요 차이점은 다음과 같다.

이러한 진화는 단순한 이름 변경이 아니라, 보다 개방적이고 투명한 표준화 과정과 초기 SSL 설계의 취약점을 해결하려는 노력의 결과였다. 이후 TLS는 독자적인 발전 경로를 걸어가며 SSL과의 하위 호환성을 점차 끊어나갔다. 현대의 보안 권고사항은 SSL 2.0과 SSL 3.0을 완전히 사용 중지할 것을 강력히 권고하고 있다[1].

TLS는 1999년 첫 표준 버전인 TLS 1.0이 공개된 이후 지속적으로 발전해왔다. 각 주요 버전은 보안 강화, 성능 개선, 이전 버전에서 발견된 취약점 해결을 목표로 했다. 아래 표는 TLS의 주요 버전과 그 특징, 출시 연도를 요약한다.

TLS 1.0과 1.1은 현재 심각한 보안 취약점을 가지고 있는 것으로 간주되어 대부분의 현대적인 브라우저와 서버에서 지원이 중단되었다. TLS 1.2는 오랫동안 사실상의 표준으로 자리 잡았으며, 광범위한 호환성과 강력한 보안을 제공했다. 최신 버전인 TLS 1.3은 설계부터 보안을 최우선으로 하여 핸드셰이크 과정을 단순화하고, 암호화 스위트를 현대적인 알고리즘으로 제한함으로써 제로 라운드 트립 타임을 포함한 성능 향상과 함께 공격 표면을 크게 줄였다.

핸드셰이크 프로토콜은 TLS 연결이 수립되는 과정을 정의한 하위 프로토콜이다. 이 과정에서 클라이언트와 서버는 통신에 사용할 암호화 알고리즘을 협상하고, 서버를 인증하며, 세션 키를 안전하게 생성하여 교환한다. 핸드셰이크가 완료되어야 실제 응용 프로그램 데이터를 암호화하여 전송하는 레코드 레이어 프로토콜이 사용될 수 있다.

핸드셰이크의 기본적인 흐름은 다음과 같다. 먼저 클라이언트가 ClientHello 메시지를 보내 지원하는 TLS 버전, 지원 암호 스위트 목록, 클라이언트 무작위 값 등을 서버에 알린다. 서버는 ServerHello 메시지로 협상된 버전과 암호 스위트, 서버 무작위 값을 응답한다. 이어서 서버는 자신의 디지털 인증서를 Certificate 메시지로 보내고, 필요에 따라 클라이언트 인증을 요청할 수 있다. 서버는 ServerHelloDone 메시지로 협상 단계의 종료를 알린다.

클라이언트는 서버의 인증서를 검증한 후, ClientKeyExchange 메시지를 보낸다. 이 메시지에는 클라이언트가 생성한 프리마스터 비밀키가 서버의 공개키로 암호화되어 담긴다. 클라이언트와 서버는 양측의 무작위 값과 프리마스터 비밀키를 이용해 동일한 마스터 비밀키를 도출하고, 이를 바탕으로 데이터 암호화에 사용할 세션 키를 생성한다. 이후 ChangeCipherSpec 메시지를 교환하여 협상된 암호 스위트로 전환을 알리고, Finished 메시지를 교환하여 핸드셰이크 과정의 무결성과 인증을 최종 확인한다.

TLS 연결을 수립할 때 협상되는 가장 중요한 요소 중 하나는 암호화 스위트이다. 암호화 스위트는 연결에 사용될 구체적인 암호 알고리즘들의 조합을 정의하는 명세이다. 일반적으로 키 교환 알고리즘, 인증 알고리즘, 대칭 암호화 알고리즘, 메시지 인증 코드(MAC) 알고리즘의 네 가지 구성 요소로 이루어진다. 클라이언트와 서버는 핸드셰이크 초기에 각자가 지원하는 암호화 스위트 목록을 교환하고, 서버가 최종적으로 하나의 스위트를 선택하여 사용한다.

키 교환은 암호화 스위트의 핵심 부분으로, 클라이언트와 서버가 안전하게 공통의 대칭키를 생성하는 과정이다. 초기 SSL과 TLS 1.0에서는 주로 RSA 키 교환이 사용되었다. 이 방식에서는 클라이언트가 생성한 프리마스터 시크릿을 서버의 공개키로 암호화하여 전송한다. 그러나 이 방법은 서버의 개인키가 노출될 경우 과거 통신의 기밀성이 훼질 수 있는 전방향 비밀성을 제공하지 못하는 단점이 있었다.

이를 해결하기 위해 디피-헬만 키 교환과 그 변형인 타원곡선 디피-헬만 키 교환이 널리 채택되었다. 이 방식에서는 통신 당사자가 각자의 비밀값과 공개된 파라미터를 사용하여 계산을 수행함으로써, 중간에서 도청하는 공격자가 알 수 없는 공유 비밀값을 생성한다. 이 공유 비밀값은 이후 프리마스터 시크릿을 유도하는 데 사용된다. 서버의 개인키가 유출되더라도 과거 세션 키를 복구할 수 없어 전방향 비밀성을 보장한다. TLS 1.3에서는 보안성을 강화하기 위해 정적 RSA 키 교환을 완전히 제거하고, 디피-헬만 또는 타원곡선 디피-헬만 기반의 키 교환만을 지원한다.

다음은 주요 키 교환 방식의 특징을 비교한 표이다.

최종적으로, 키 교환 과정을 통해 생성된 프리마스터 시크릿은 양측이 공유하는 난수와 결합되어 마스터 시크릿을 생성한다. 이 마스터 시크릿은 다시 여러 개의 세션 키로 유도되어, 실제 데이터 암호화와 무결성 검증에 사용된다.

TLS 연결에서 서버(및 필요시 클라이언트)의 신원을 확인하고, 신뢰할 수 있는 제3자를 통해 그 신원을 보증하는 메커니즘이 필요하다. 이를 위해 공개키 암호 방식의 디지털 인증서와 이를 관리하는 공개키 기반구조(PKI)가 사용된다.

디지털 인증서는 '전자 신분증'에 비유할 수 있다. 이 인증서에는 서버의 도메인 이름, 소유자 정보, 서버의 공개키, 그리고 인증서를 발급한 인증 기관(CA)의 디지털 서명 등이 포함되어 있다. 클라이언트(예: 웹 브라우저)는 핸드셰이크 과정 중 서버로부터 이 인증서를 받아 검증한다. 검증은 인증서의 서명이 클라이언트가 이미 신뢰하는 루트 인증 기관의 공개키로 유효한지, 인증서의 유효기간이 만료되지 않았는지, 그리고 인증서에 적힌 도메인 이름이 실제 접속한 서버의 도메인과 일치하는지 등을 확인하는 과정을 거친다.

이러한 신뢰 체계를 가능하게 하는 것이 공개키 기반구조이다. PKI는 디지털 인증서의 생성, 배포, 관리, 저장, 폐기를 포함한 일련의 정책, 하드웨어, 소프트웨어, 절차를 총칭한다. 주요 구성 요소는 다음과 같다.

클라이언트는 운영체제나 브라우저에 미리 내장된 신뢰할 수 있는 루트 인증서 저장소를 통해 주요 CA들의 루트 인증서를 보유하고 있다. 서버의 인증서가 이러한 CA 중 하나에 의해 서명된 체인을 형성하면 클라이언트는 서버를 신뢰하게 된다. 또한, 확장 검증 인증서(EV)처럼 발급 절차가 더 엄격한 인증서는 브라우저 주소창에 기관 이름을 표시하여 더 높은 신뢰도를 제공하기도 한다.

TLS는 통신의 세 가지 근본적인 보안 목표인 기밀성, 무결성, 인증을 제공하는 것을 핵심 목표로 설계되었다. 이 세 가지 요소는 안전한 통신 채널을 구축하는 데 필수적인 기반이 된다.

기밀성은 제삼자가 통신 내용을 도청하거나 이해하는 것을 방지하는 것을 의미한다. TLS는 대칭키 암호 알고리즘을 사용하여 전송되는 실제 데이터를 암호화함으로써 이를 보장한다. 핸드셰이크 과정에서 협상된 암호 스위트에 포함된 AES나 ChaCha20 같은 알고리즘이 이 역할을 수행한다. 암호화에 사용되는 세션 키는 핸드셰이크 단계에서 안전하게 생성 및 교환되며, 각 통신 세션마다 고유한 키를 사용하는 것이 일반적이다.

무결성은 전송 중인 데이터가 변조되거나 손상되지 않았음을 보증하는 것이다. TLS는 메시지 인증 코드(MAC)나 인증 암호 방식을 통해 이를 구현한다. 송신자는 각 암호화된 데이터 블록에 대해 MAC 값을 계산하여 함께 전송하고, 수신자는 동일한 계산을 수행하여 비교한다. 값이 일치하지 않으면 데이터가 중간에 변경된 것으로 간주하여 연결을 종료한다. 이 과정은 재전송 공격을 포함한 중간자 공격을 탐지하는 데도 효과적이다.

인증은 통신 상대방이 자신이 주장하는 주체임을 확인하는 과정이다. TLS는 주로 서버의 신원을 공개키 인증서를 통해 인증하는 일방향 인증 방식을 사용한다. 클라이언트는 서버가 제공한 인증서를 신뢰할 수 있는 인증 기관(CA)의 루트 인증서 체인을 통해 검증한다. 필요에 따라 클라이언트도 인증서를 제출하는 상호 인증이 이루어질 수도 있다. 인증은 키 교환 과정과 결합되어, 교환되는 키가 인증된 상대방에게만 전달되도록 한다.

TLS는 재전송 공격을 방지하기 위해 몇 가지 메커니즘을 포함한다. 재전송 공격은 공격자가 합법적인 통신 세션에서 가로챈 데이터 패킷을 나중에 다시 전송하여 시스템을 속이는 공격 방식이다. 이를 방지하지 않으면, 예를 들어 인증 정보나 금융 거래 명령이 재사용될 수 있다.

TLS 핸드셰이크 과정에서 생성되는 무작위 값들이 재전송 공격 방지에 핵심 역할을 한다. 클라이언트와 서버는 각각 클라이언트 랜덤과 서버 랜덤이라는 고유한 난수를 생성하여 교환한다. 이 난수들은 세션 키를 생성하는 데 사용되며, 각 핸드셰이크마다 완전히 새로운 값이 생성된다. 따라서 과거에 가로챈 핸드셰이크 메시지를 재전송하더라도, 새로운 난수와 함께 생성되는 세션 키가 다르기 때문에 이후의 암호화된 통신을 복호화하거나 유효한 세션을 설정하는 것이 불가능해진다.

또한, TLS 1.3에서는 보안을 더욱 강화하여 핸드셰이크 메시지 자체의 재전송을 효과적으로 차단한다. 이전 버전에 비해 핸드셰이크 라운드 트립 횟수가 줄어들고, 대부분의 핸드셰이크 메시지가 암호화되어 전송된다. 특히, 서버의 인증 응답(인증서 등)이 클라이언트가 제공한 키 소재로 암호화되어 전송되므로, 공격자가 이를 미리 기록해 두었다가 재전송하는 것이 의미 없게 된다.

HTTPS는 HTTP 프로토콜에 TLS 보안 계층을 적용한 것이다. 기본 HTTP는 통신 내용이 암호화되지 않은 평문으로 전송되기 때문에, 네트워크 경로 상에서 제3자가 내용을 엿보거나 조작할 수 있는 중간자 공격에 취약하다. HTTPS는 이러한 문제를 해결하여 웹 브라우저와 웹 서버 간의 모든 통신을 암호화한다. 이를 통해 사용자가 웹사이트에 제출하는 로그인 정보, 결제 정보, 개인 메시지 등의 민감한 데이터가 안전하게 보호된다.

HTTPS 연결이 수립되기 위해서는 먼저 TLS 핸드셰이크 과정이 수행된다. 이 과정에서 클라이언트와 서버는 사용할 암호화 알고리즘을 협상하고, 서버는 자신의 신원을 증명하는 디지털 인증서를 제시한다. 클라이언트는 이 인증서가 신뢰할 수 있는 인증 기관에 의해 발급되었는지 확인한다. 성공적인 핸드셰이크 이후, 양측은 대칭 암호화에 사용할 세션 키를 공유하고, 모든 HTTP 데이터는 이 키로 암호화된 채널을 통해 교환된다.

HTTPS의 보안 이점은 다음과 같이 요약할 수 있다.

* 기밀성: 통신 내용이 암호화되어 제3자에게 노출되지 않는다.

* 무결성: 메시지 인증 코드 등을 통해 데이터가 전송 중에 변조되지 않았음을 보장한다.

* 인증: 서버의 디지털 인증서를 통해 사용자가 의도한 정당한 서버와 통신하고 있음을 확인한다. 이는 피싱 사이트 방지에 중요하다.

현대 웹에서는 HTTPS가 필수 표준이 되었다. 주요 웹 브라우저들은 HTTP 사이트에 대해 '안전하지 않음' 경고를 표시하며, 검색 엔진은 HTTPS 사이트에 검색 순위 가중치를 부여한다. 또한 HTTP/2 및 HTTP/3와 같은 고성능 프로토콜의 대부분 구현은 HTTPS를 전제로 동작한다. 이는 보안뿐만 아니라 웹의 성능과 현대화에도 HTTPS가 핵심 인프라가 되었음을 의미한다.

TLS는 이메일 통신의 보안을 강화하는 데 핵심적인 역할을 한다. 주로 SMTP(Simple Mail Transfer Protocol), IMAP(Internet Message Access Protocol), POP3(Post Office Protocol version 3)과 같은 이메일 프로토콜에 적용된다. 이 프로토콜들은 기본적으로 평문 통신을 사용하므로, TLS를 통해 암호화된 채널 위에서 운용될 때 SMTPS, IMAPS, POP3S로 불린다. 이를 통해 이메일 서버와 클라이언트 간의 로그인 정보(사용자명과 비밀번호)와 이메일 내용이 제3자에 의해 엿들리는 것을 방지한다.

운용 방식은 일반적으로 명시적(Explicit TLS) 또는 암시적(Implicit TLS) 방식으로 구분된다. 명시적 TLS(일반적으로 STARTTLS 명령 사용)에서는 클라이언트가 먼저 평문 연결을 수립한 후, TLS 암호화 채널로 업그레이드할 것을 협상한다. 반면 암시적 TLS에서는 연결 시작부터 TLS 암호화 채널을 사용하는 별도의 포트(예: SMTPS용 465번, IMAPS용 993번)를 사용한다. 현대적인 보안 관행에서는 암시적 TLS 방식이 더 선호되는 경향이 있다.

이메일 보안에서 TLS는 전송 중 데이터의 기밀성과 무결성을 제공하지만, 엔드투엔드 암호화를 보장하지는 않는다. 이는 이메일이 발신자와 수신자의 메일 서버 간 구간만 암호화될 수 있으며, 서버 내부나 서버-클라이언트 구간에서 평문으로 처리될 수 있음을 의미한다. 따라서 더 높은 수준의 비밀성을 위해서는 PGP나 S/MIME과 같은 콘텐츠 수준의 엔드투엔드 암호화 기술이 추가로 필요하다.

TLS는 가상사설망(VPN)을 구축하는 데 있어 핵심적인 보안 프로토콜로 자리 잡았다. 특히, 원격 접속 VPN에서 사용자는 공용 네트워크(예: 인터넷)를 통해 사내 네트워크에 안전하게 연결해야 한다. TLS는 이 연결 터널을 암호화하고 서버를 인증하여 데이터의 기밀성과 무결성을 보장한다. 이 방식은 전통적인 IPsec VPN에 비해 방화벽을 통과하기 쉬우며, 표준 HTTPS 포트(443)를 사용하기 때문에 차단될 가능성이 낮다는 장점이 있다.

가장 일반적인 형태는 SSL/TLS VPN 또는 웹 VPN으로 불린다. 사용자는 웹 브라우저를 통해 VPN 게이트웨이에 접속하고, TLS 핸드셰이크를 완료한 후 인증을 거쳐 내부 자원에 접근한다. 더 포괄적인 접근을 제공하는 TLS 터널링 프로토콜로는 OpenVPN이 널리 사용된다. OpenVPN은 TLS 프로토콜을 기반으로 완전한 네트워크 계층의 터널을 생성하며, 강력한 암호화와 플랫폼 간 호환성을 제공한다.

최근에는 제로 트러스트 네트워크 접근(ZTNA) 모델의 확산에 따라 TLS의 역할이 더욱 중요해졌다. ZTNA는 "신뢰할 수 없는 네트워크"를 전제로 하며, 사용자와 애플리케이션 간 각 세션에 대해 TLS를 이용한 암호화 터널과 엄격한 인증을 요구한다. 이는 네트워크 경계를 넘어서는 보안 접근을 가능하게 한다.

주요 TLS 기반 VPN 솔루션과 특징은 다음과 같다.

이처럼 TLS는 유연성과 강력한 보안으로 인해 현대 VPN 아키텍처의 근간을 이루며, 원격 접속 보안 표준으로 확고히 자리매김했다.

서버에서 TLS를 활성화하려면 먼저 적절한 디지털 인증서를 획득하고 설치해야 한다. 대부분의 웹 서버 소프트웨어(예: Apache HTTP Server, Nginx, Microsoft IIS)는 설정 파일을 통해 TLS를 구성한다. 핵심 설정 항목으로는 사용할 TLS 버전(예: TLS 1.2, TLS 1.3), 허용할 암호화 스위트 목록, 그리고 인증서 파일과 개인 키 파일의 경로 지정이 포함된다. 보안을 강화하기 위해 구식이고 안전하지 않은 SSL 프로토콜과 약한 암호화 스위트는 명시적으로 비활성화하는 것이 일반적이다.

클라이언트 측면에서, 웹 브라우저나 이메일 클라이언트 같은 응용 프로그램은 일반적으로 서버와의 TLS 연결을 자동으로 협상한다. 사용자는 주소창의 자물쇠 아이콘을 통해 연결 보안 상태를 확인할 수 있다. 그러나 클라이언트 응용 프로그램을 개발하거나 특별히 구성해야 하는 경우, 서버의 인증서를 검증할 수 있는 신뢰할 수 있는 인증 기관 목록(루트 인증서 저장소)을 올바르게 관리해야 한다. 또한 클라이언트도 특정 TLS 버전만 사용하도록 강제하거나 특정 암호화 스위트를 선호하도록 구성할 수 있다.

효율적인 배포를 위해 로드 밸런서나 콘텐츠 전송 네트워크와 같은 중간 장치에서 TLS 연결을 종료(Offloading)하는 경우가 많다. 이는 백엔드 서버의 부하를 줄여주지만, 종료 지점과 백엔드 서버 간 통로의 보안도 함께 고려해야 한다. 설정 후에는 SSL Labs와 같은 온라인 도구를 이용해 서버의 TLS 구성 강도를 테스트하고, 취약한 설정이나 지원 중인 프로토콜을 점검하는 것이 표준적인 절차이다.

인증서 발급 및 관리는 공개키 기반구조의 신뢰 체계를 유지하는 핵심 과정이다. 인증서 발급은 일반적으로 신뢰할 수 있는 제3자인 인증 기관에 의해 수행된다. 서버 운영자는 인증서 서명 요청을 생성하여 자신의 공개키와 서버 정보를 포함시킨 후, 이를 선택한 CA에 제출한다. CA는 요청자의 신원과 도메인 소유권을 검증한 후, 자신의 개인키로 서명한 디지털 인증서를 발급한다. 이 인증서에는 서버의 공개키, 소유자 정보, 유효 기간, 발행 CA 정보 등이 포함된다.

인증서 관리는 발급 이후의 전 생애주기를 다룬다. 주요 관리 작업으로는 인증서의 안전한 저장, 정기적인 갱신, 해지 상태 모니터링이 있다. 인증서는 유효 기간을 가지며, 만료되기 전에 갱신 절차를 거쳐야 서비스 중단을 방지할 수 있다. 또한, 개인키가 유출되거나 서버 정보가 변경되는 등 보안 사고가 발생하면, CA에 인증서 해지를 요청하여 해당 인증서를 무효화할 수 있다. 해지된 인증서 목록은 인증서 해지 목록이나 온라인 인증서 상태 프로토콜을 통해 배포 및 확인된다.

효율적인 관리를 위해 많은 조직에서는 인증서 관리 플랫폼을 도입한다. 이러한 플랫폼은 여러 CA로부터 발급받은 다양한 인증서의 만료 일정을 중앙에서 모니터링하고, 자동 갱신 프로세스를 실행하며, 보안 정책 준수 여부를 감사한다. 특히 와일드카드 인증서나 다중 도메인 인증서를 사용하는 경우, 여러 서비스에 걸친 인증서 배포와 관리를 단순화하는 데 도움이 된다.

TLS 프로토콜과 이를 구현하는 라이브러리에는 과거 여러 심각한 보안 취약점이 발견되었다. 이러한 취약점들은 주로 프로토콜 설계 결함이나 구현상의 오류에서 비롯되었으며, 대응책으로 프로토콜 업데이트와 구식 기능의 사용 중단이 촉진되었다.

주요 설계 결함 공격으로는 POODLE 공격이 있다. 이 공격은 TLS 1.0에서 하위 호환성을 위해 남아있던 SSL 3.0의 취약점을 악용한다. 공격자는 암호 블록을 조작하여 평문 데이터를 한 바이트씩 추출할 수 있다. 이에 대한 가장 효과적인 대응은 서버와 클라이언트 양측에서 SSL 3.0 지원을 완전히 비활성화하는 것이다. 또한 BEAST 공격은 TLS 1.0 및 그 이전 버전의 블록 암호 운용 모드 취약점을 이용한 것으로, TLS 1.1 이상으로 업그레이드하여 방어할 수 있다.

구현상의 결함에서 발생한 가장 유명한 공격은 Heartbleed 버그이다. 이는 OpenSSL 라이브러리의 하트비트 확장 기능 구현에 존재한 버퍼 오버리드 취약점이다. 이 취약점을 통해 공격자는 서버의 메모리 내용을 최대 64KB씩 유출시킬 수 있어, 세션 키나 사용자 비밀번호 같은 민감 정보가 노출될 위험이 컸다. 패치는 신속하게 배포되었으나, 전 세계 수백만 대의 서버에 영향을 미친 대규모 보안 사건이었다.

다음은 주요 공격과 그 특성을 정리한 표이다.

이러한 공격들에 대한 대응으로, 업계는 TLS 1.2와 TLS 1.3으로의 전환을 가속화했다. TLS 1.3은 설계부터 불안전한 암호화 스위트와 기능(예: 압축, RC4, 정적 RSA 키 교환 등)을 제거하여 공격 면적을 크게 줄였다. 시스템 관리자와 개발자는 최신 TLS 버전을 사용하고, 정기적인 보안 업데이트를 적용하며, 취약한 구식 프로토콜을 비활성화하는 것이 필수적이다.

TLS 1.0과 TLS 1.1은 여러 심각한 보안 취약점이 발견되어 더 이상 안전하지 않은 것으로 간주된다. 주요 취약점으로는 블록 암호에서 CBC 모드를 사용할 때 발생할 수 있는 패딩 오라클 공격이 있으며, POODLE 공격은 이러한 취약성을 악용하는 대표적인 사례이다. 또한 이 버전들은 현대적인 암호화 스위트를 지원하지 않아 기밀성과 무결성을 충분히 보장할 수 없다.

이에 따라 국제 인터넷 표준화 기구와 주요 기술 기업들은 구식 프로토콜의 사용 중단을 권고하고 있다. IETF는 2021년 3월에 TLS 1.0과 1.1을 공식적으로 역사적인 문서로 만드는 RFC 8996을 발표했다[7]. 주요 웹 브라우저와 운영체제 또한 이러한 버전에 대한 지원을 단계적으로 제거했다.

현재 표준으로 권장되는 버전은 TLS 1.2와 TLS 1.3이다. 특히 TLS 1.3은 설계부터 보안과 성능을 중점적으로 개선했다. 핸드셰이크 과정을 단순화하고, 안전하지 않은 암호화 알고리즘을 제거하며, 전방향 비밀성을 기본으로 지원한다. 배포 시에는 최소한 TLS 1.2를 사용해야 하며, 가능하면 가장 강력한 보안과 성능 향상을 제공하는 TLS 1.3으로의 업그레이드가 강력히 권장된다.

서버와 클라이언트를 구성할 때는 지원하는 프로토콜 버전과 암호화 스위트를 명시적으로 설정하는 것이 중요하다. 아래는 권장 설정의 예시이다.

이러한 조치는 중간자 공격, 다운그레이드 공격을 포함한 다양한 위협으로부터 통신을 보호하는 데 필수적이다.