전송 계층 보안 (r1)

SSL은 1990년대 초 넷스케이프 커뮤니케이션스에 의해 개발된 최초의 널리 채택된 보안 프로토콜이다. SSL 1.0은 공개되지 않았으며, SSL 2.0(1995년)과 SSL 3.0(1996년)이 실제로 배포되었다. SSL 3.0은 2.0의 여러 보안 결함을 해결했지만, 여전히 설계상의 근본적인 문제를 안고 있었다.

1999년, IETF(인터넷 엔지니어링 태스크 포스)는 SSL 3.0을 기반으로 하여 공식적인 표준 프로토콜을 제정했다. 이 새로운 프로토콜은 전송 계층 보안(TLS) 1.0으로 명명되었으며, RFC 2246으로 발표되었다. SSL에서 TLS로의 이름 변경은 IETF가 표준화 과정을 주도하게 되었음을 나타내며, 기술적으로는 호환되지만 독립적인 프로토콜로 진화했음을 의미한다.

TLS 1.0은 SSL 3.0과의 상호 운용성을 유지하면서도 몇 가지 중요한 보안 강화를 도입했다. 주요 차이점은 다음과 같다.

이 진화는 단순한 이름 변경을 넘어서, 프로토콜의 암호화 유연성과 메시지 무결성 보호를 강화하는 방향으로 이루어졌다. 이후 TLS는 지속적인 보안 연구와 취약점 발견을 통해 TLS 1.1, 1.2, 1.3으로 발전해 나갔다. SSL 3.0은 2014년 POODLE 공격의 발견 이후 공식적으로 폐기 권고를 받았다.

TLS는 SSL 3.0을 기반으로 하여 1999년에 표준화된 TLS 1.0으로 시작되었다. SSL 3.0과의 호환성을 유지했지만, HMAC을 사용한 메시지 인증, 더 강력한 키 유도 함수 등 보안성이 향상되었다. 그러나 이후 BEAST 공격[2]이나 POODLE 공격과 같은 취약점이 발견되면서 개선의 필요성이 제기되었다.

TLS 1.1은 2006년에 발표되어 초기화 벡터에 대한 보호를 강화하고, 명시적인 패딩을 도입하여 CBC 모드에 대한 공격을 완화했다. 2008년에 등장한 TLS 1.2는 현대적인 암호화 해시 함수인 SHA-256을 기본으로 지원하고, 암호화 스위트의 협상 방식을 유연하게 변경했다. 또한 AEAD 암호화 방식인 GCM과 CCM 모드에 대한 지원이 추가되어 보안성과 효율성이 크게 높아졌다.

2018년에 최종 확정된 TLS 1.3은 이전 버전들과 비교하여 가장 큰 변화를 가져왔다. 핵심 목표는 보안 강화와 지연 시간 단축이었다. 이를 위해 취약한 것으로 알려진 레거시 암호화 알고리즘과 기능(예: RSA 기반의 정적 키 교환, CBC 모드 암호, SHA-1 해시, 압축 등)을 대거 제거했다. 핸드셰이크 과정이 단순화되고, 대부분의 경우 1-RTT(왕복 1회)로 연결이 수립되며, 0-RTT 모드를 지원하여 성능이 향상되었다. 또한 전달 비밀성을 기본으로 보장하도록 설계되었다.

각 버전은 이전 버전의 보안 결함을 해결하고 새로운 암호학적 표준을 반영하며 발전해왔다. 특히 TLS 1.3은 설계 철학 자체를 보안과 속도에 집중하여 현대 인터넷 보안의 핵심 프로토콜로 자리 잡았다.

핸드셰이크 프로토콜은 전송 계층 보안 연결이 수립되기 전에 클라이언트와 서버 간에 수행되는 초기 협상 과정을 담당한다. 이 프로토콜의 주요 목적은 통신 당사자를 인증하고, 사용할 암호화 스위트를 협상하며, 실제 데이터 암호화에 사용될 세션 키를 안전하게 생성하고 교환하는 것이다. 핸드셰이크가 성공적으로 완료되어야만 레코드 프로토콜을 통한 보안된 애플리케이션 데이터 교환이 시작된다.

핸드셰이크 과정은 일련의 메시지 교환으로 이루어진다. 일반적인 흐름은 클라이언트가 지원하는 TLS 버전, 암호화 스위트 목록, 무작위 값 등을 포함한 ClientHello 메시지를 전송하는 것으로 시작한다. 서버는 이에 응답하여 선택한 암호 스위트, 서버의 무작위 값, 그리고 서버의 디지털 인증서를 포함한 ServerHello 메시지를 보낸다. 이후 서버는 클라이언트 인증이 필요한 경우 인증서 요청을 보낼 수 있으며, ServerHelloDone 메시지로 협상 단계를 마무리한다.

클라이언트는 서버 인증서의 유효성을 검증한 후, 세션 키의 기반이 될 pre-master secret을 생성하여 서버의 공개키로 암호화하여 ClientKeyExchange 메시지로 전송한다. 이 시점에서 클라이언트와 서버는 무작위 값과 pre-master secret을 사용하여 동일한 master secret과 세션 키를 독립적으로 계산한다. 이후 양측은 지금까지 교환한 핸드셰이크 메시지의 무결성을 검증하기 위해 메시지 인증 코드를 계산하여 Finished 메시지를 교환한다. 이 Finished 메시지의 검증이 성공하면 핸드셰이크가 완료되고 보안 채널이 수립된다.

핸드셰이크 프로토콜은 성능과 보안을 위해 몇 가지 최적화 모드를 제공한다. 가장 일반적인 모드는 위에 설명된 전체 핸드셰이크이다. 이전에 연결된 세션의 매개변수를 재사용하는 세션 재개는 불필요한 암호 연산과 통신 지연을 줄여준다. 또한 TLS 1.3에서는 핸드셰이크를 단일 왕복으로 최적화하고 암호화된 확장, 제로 RTT 모드 등을 도입하여 지연 시간을 크게 단축하였다.

레코드 프로토콜은 전송 계층 보안 연결이 수립된 후, 실제 애플리케이션 데이터를 안전하게 전송하는 역할을 담당한다. 이 프로토콜은 핸드셰이크 과정에서 협상된 보안 매개변수를 사용하여 상위 계층에서 내려온 데이터를 암호화, 압축, 전송하며, 수신 측에서는 이를 복호화하고 검증한다. 레코드 프로토콜의 주요 작업은 기밀성, 데이터 무결성, 그리고 재전송 공격 방지를 보장하는 것이다.

레코드 프로토콜의 처리 과정은 몇 가지 단계로 나뉜다. 먼저, 상위 계층(예: HTTP)에서 내려온 데이터를 레코드 단위로 분할한다. 각 레코드는 최대 16KB 크기를 가질 수 있다. 이후, 협상된 압축 알고리즘이 있다면 이 단계에서 압축을 수행하지만, 현대 TLS 구현에서는 보안상의 이유로 압축 기능은 일반적으로 사용되지 않는다. 그 다음, 메시지 인증 코드를 계산하여 데이터 무결성을 보장하고, 최종적으로 협상된 대칭 암호 알고리즘(예: AES 또는 ChaCha20)을 사용하여 데이터와 MAC을 함께 암호화한다. 암호화된 레코드에는 콘텐츠 유형, 프로토콜 버전, 길이를 나타내는 레코드 헤더가 추가되어 전송된다.

수신 측에서는 이 과정을 역순으로 수행한다. 레코드 헤더를 확인한 후, 대칭 키를 사용하여 데이터를 복호화한다. 복호화된 데이터의 MAC 값을 검증하여 전송 중 변조가 없었는지 확인한다. 무결성 검증에 성공하면, 압축이 적용되었다면 해제하고, 최종적으로 원본 데이터를 상위 계층 애플리케이션에 전달한다. 이 모든 과정은 핸드셰이크 프로토콜을 통해 교환된 세션 키와 협상된 암호화 스위트에 기반하여 이루어진다.

레코드 프로토콜은 다양한 콘텐츠 유형을 처리할 수 있도록 설계되었다. 주요 유형은 다음과 같다.

이 구조를 통해 TLS는 단일 연결 내에서 제어 메시지와 사용자 데이터를 구분하여 안전하게 전송할 수 있다.

암호화 스위트는 전송 계층 보안 연결을 설정할 때 협상되는 암호 알고리즘의 조합을 가리킨다. 이 조합은 네 가지 핵심 구성 요소로 이루어지며, 각 요소는 연결의 특정 보안 기능을 담당한다. 일반적으로 "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"과 같은 형식으로 표현되며, 이는 키 교환 알고리즘, 인증 알고리즘, 대칭 암호화 알고리즘, 메시지 인증 코드 알고리즘의 순서로 정의된다.

구성 요소는 다음과 같다.

시간이 지남에 따라 취약해진 알고리즘은 스위트 목록에서 제거되고 더 강력한 알고리즘으로 대체되었다. 예를 들어, TLS 1.2에서는 RC4 스트림 암호와 SHA-1 해시 함수의 사용이 권장되지 않게 되었으며, TLS 1.3에서는 보안과 성능을 고려하여 지원되는 암호화 스위트의 수가 크게 줄어들었다. TLS 1.3에서는 모든 키 교환이 Diffie-Hellman 방식*전진 비밀성(Forward Secrecy)을 보장하기 위해으로 이루어져야 하며, RSA 키 교환은 완전히 제거되었다. 또한 AES-GCM이나 ChaCha20-POLY1305와 같이 인증 암호화(AEAD)를 지원하는 현대적인 알고리즘 조합만을 사용한다.

핸드셰이크 과정은 클라이언트와 서버가 통신을 시작하기 전에 보안 매개변수를 협상하고, 서로를 인증하며, 세션에 사용할 암호화 키를 안전하게 생성하는 절차이다. 이 과정은 전송 계층 보안 연결의 기초를 마련한다.

핸드셰이크는 주로 다음 단계로 이루어진다. 먼저, 클라이언트가 ClientHello 메시지를 서버로 보낸다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 지원하는 암호화 스위트 목록, 그리고 나중에 세션 키를 생성하는 데 사용할 무작위 데이터(클라이언트 랜덤)가 포함된다. 서버는 ServerHello 메시지로 응답하며, 협상된 TLS 버전, 선택한 암호화 스위트, 그리고 서버 자신의 무작위 데이터(서버 랜덤)를 전송한다. 이후 서버는 일반적으로 자신의 디지털 인증서를 Certificate 메시지로 보내고, 필요에 따라 클라이언트 인증을 요청할 수 있다. 서버는 ServerHelloDone 메시지를 보내 이 단계를 마친다.

클라이언트는 서버의 인증서를 검증한 후, ClientKeyExchange 메시지를 보낸다. 이 메시지에는 프리마스터 시크릿이 포함되며, 이 값은 서버의 공개키로 암호화되어 전송되어 기밀성을 보장한다. 클라이언트와 서버는 이제 클라이언트 랜덤, 서버 랜덤, 프리마스터 시크릿을 입력값으로 사용하여 동일한 마스터 시크릿을 각자 독립적으로 생성한다. 이 마스터 시크릿으로부터 실제 데이터 암호화에 사용할 세션 키를 유도해낸다. 이후 양측은 ChangeCipherSpec 메시지를 교환하여 협상된 암호화 스위트로 전환할 것을 알리고, Finished 메시지를 교환하여 지금까지의 핸드셰이크 메시지 무결성과 키 교환의 성공을 확인한다. Finished 메시지 검증이 완료되면, 보안 채널이 수립되고 레코드 프로토콜을 통한 응용 데이터의 암호화된 전송이 시작된다.

전송 계층 보안에서 세션 키 교환은 핸드셰이크 과정의 핵심 단계로, 클라이언트와 서버가 이후 통신에 사용할 대칭 암호화 키를 안전하게 공유하는 절차이다. 이 과정은 디피-헬만 키 교환이나 타원곡선 디피-헬만과 같은 비대칭 키 교환 알고리즘을 기반으로 한다. 공개키 암호화 방식으로 사전에 공유된 비밀 정보 없이도 양측이 공통의 비밀값(프리마스터 시크릿)을 생성할 수 있게 한다. 생성된 프리마스터 시크릿은 이후 일련의 해시 함수를 거쳐 실제 데이터 암호화와 무결성 검증에 사용되는 마스터 시크릿 및 세션 키들을 도출하는 데 사용된다.

세션 키 교환의 주요 목표는 기밀성과 전방향 안전성을 보장하는 것이다. 전방향 안전성은 장기적인 개인키가 유출되더라도 과거에 교환된 세션 키를 복구할 수 없음을 의미한다. 이를 위해 TLS 1.3에서는 에피머럴 디피-헬만 방식을 의무화하여, 매 세션마다 일회용 키 쌍을 생성하고 폐기함으로써 전방향 안전성을 강화하였다. 이전 버전에서는 RSA 암호화를 통한 키 교환도 지원했으나, 이 방식은 서버의 개인키 유출 시 과거 세션의 복호화가 가능해 전방향 안전성을 제공하지 않는다는 단점이 있었다.

교환 과정은 일반적으로 다음과 같은 단계를 거친다.

1. 클라이언트와 서버가 지원하는 키 교환 알고리즘을 협상한다.

2. 서버는 선택된 알고리즘에 필요한 매개변수(예: 디피-헬man 공개값)를 자신의 디지털 인증서와 함께 클라이언트에 전송한다.

3. 클라이언트는 인증서를 검증한 후, 자신의 키 교환 공개값을 생성하여 서버에 전송한다.

4. 양측은 각자의 비밀값과 상대방의 공개값을 조합하여 동일한 프리마스터 시크릿을 계산한다.

이렇게 생성된 프리마스터 시크릿은 핸드셰이크 과정에서 교환된 모든 메시지의 해시값과 결합되어 마스터 시크릿을 생성하며, 최종적으로는 암호화 키와 메시지 인증 코드 키 등 여러 세션 키를 만들어낸다. 이 세션 키들은 레코드 프로토콜 단계에서 애플리케이션 데이터의 안전한 전송을 위해 직접 사용된다.

데이터 암호화는 대칭키 암호 알고리즘을 사용하여 수행된다. 핸드셰이크 과정에서 협상된 암호화 스위트에 포함된 대칭키 알고리즘(예: AES, ChaCha20)과 세션 키를 이용해 실제 애플리케이션 데이터를 암호화한다. 이 과정은 레코드 프로토콜에 의해 처리되며, 암호화된 데이터는 전송 계층을 통해 세그먼트로 분할되어 전송된다.

데이터 무결성과 인증은 메시지 인증 코드(MAC)를 통해 보장된다. 일반적으로 HMAC(Hash-based Message Authentication Code)이나 AEAD(Authenticated Encryption with Associated Data) 암호화 모드가 사용된다[4]. 이를 통해 데이터가 전송 중에 변조되지 않았음을 수신측이 검증할 수 있다.

인증은 주로 공개키 기반구조(PKI)와 X.509 디지털 인증서를 기반으로 한다. 서버는 핸드셰이크 과정에서 자신의 인증서를 클라이언트에 제공하며, 클라이언트는 해당 인증서의 유효성(만료일, 서명 체인, 해지 상태 등)을 검증한다. 선택적으로 클라이언트 인증도 수행될 수 있다.

암호화와 인증의 전체 과정은 다음 표와 같이 요약할 수 있다.

이러한 메커니즘은 도청, 중간자 공격, 데이터 변조로부터 통신을 보호한다.

전송 계층 보안의 기밀성은 교환되는 데이터가 오직 의도된 수신자만 읽을 수 있도록 보장하는 기능이다. 이는 대칭키 암호 알고리즘을 사용하여 평문 데이터를 암호문으로 변환함으로써 달성된다. 핵심은 핸드셰이크 과정에서 협상된 암호 스위트에 포함된 대칭 암호 알고리즘(예: AES, ChaCha20)과 그때 생성된 세션 키를 이용한다는 점이다.

기밀성 제공의 구체적인 과정은 다음과 같다. 먼저, 클라이언트와 서버는 핸드셰이크를 통해 사용할 암호화 알고리즘과 키를 안전하게 협상한다. 이후 애플리케이션 데이터는 TLS 레코드 프로토콜에 의해 처리된다. 레코드 프로토콜은 데이터를 조각내고, 협상된 암호 알고리즘과 세션 키를 사용해 각 조각을 암호화한 후 전송한다. 수신 측은 동일한 세션 키를 사용해 암호문을 원래의 평문으로 복호화한다. 이 세션 키는 한 번의 연결(세션)에 대해서만 유효하며, 연결이 종료되면 폐기된다[5].

기밀성은 도청이나 패킷 스니핑과 같은 수동적 공격으로부터 데이터를 보호한다. 예를 들어, 신용카드 정보나 로그인 자격 증명, 개인 메시지 등이 네트워크를 통해 전송될 때 제3자가 그 내용을 알아볼 수 없게 만든다. 그러나 기밀성만으로는 데이터가 전송 중에 변조되지 않았음을 보장하거나, 통신 상대의 신원을 확인할 수 없다. 이러한 무결성과 인증 기능은 메시지 인증 코드(MAC)와 디지털 인증서를 통해 별도로 제공된다.

전송 계층 보안의 무결성 보장은 메시지 인증 코드를 통해 이루어진다. 메시지 인증 코드는 전송된 데이터가 중간에 변조되거나 위조되지 않았음을 검증하는 암호학적 체크섬이다. TLS에서는 일반적으로 HMAC이나 AEAD 암호화 스위트의 일부로 제공되는 인증 기능을 사용한다.

메시지 인증 코드의 작동 방식은 다음과 같다. 송신 측은 전송할 평문 데이터와 양측이 공유한 비밀 키를 특정 알고리즘(HMAC-SHA256 등)에 입력하여 짧은 고정 길이의 MAC 값을 생성한다. 이 값은 데이터와 함께 암호화되어 수신자에게 전송된다. 수신 측은 동일한 비밀 키를 사용하여 수신한 데이터로부터 MAC 값을 다시 계산하고, 전달받은 MAC 값과 비교한다. 두 값이 일치하면 데이터가 전송 중 변경되지 않았음을, 일치하지 않으면 변조가 의심되어 연결을 종료함으로써 무결성을 보장한다.

TLS 1.2까지는 레코드 프로토콜 단계에서 별도로 HMAC을 계산하는 방식이 일반적이었다. 그러나 TLS 1.3에서는 대부분의 암호화 스위트가 인증 암호 방식을 채택하여 암호화와 인증을 한 번에 처리한다[6]. 이 방식은 별도의 MAC 계산 단계를 없애 성능을 향상시키고, 암호화와 인증을 분리할 때 발생할 수 있는 보안 위험을 줄인다. 무결성 검증 실패는 즉각적인 연결 종료를 유발하여 공격자가 변조된 데이터를 주입하는 것을 방지한다.

전송 계층 보안의 인증 기능은 주로 공개키 기반구조와 디지털 인증서를 활용하여 통신 상대방의 신원을 확인하는 과정이다. 이는 클라이언트가 연결하려는 서버가 진짜 의도한 서버인지, 또는 서버가 특정 클라이언트를 신원 확인해야 할 때 그 정체성을 검증하는 데 필수적이다.

가장 일반적인 형태는 서버 인증이다. 클라이언트가 서버에 연결을 시도하면, 서버는 자신의 디지털 인증서를 클라이언트에 전송한다. 이 인증서에는 서버의 공개키와 서버의 도메인 이름(주체 일반 이름) 같은 정보가 포함되어 있으며, 신뢰할 수 있는 인증 기관의 개인키로 서명되어 있다. 클라이언트는 미리 내장된 또는 신뢰하는 인증 기관 목록을 참조하여 해당 서명을 검증한다. 서명 검증이 성공하면, 해당 인증서가 변조되지 않았고 명시된 서버가 소유하고 있다는 것을 신뢰할 수 있다. 이 과정을 통해 클라이언트는 중간자 공격으로 가짜 서버에 연결되는 위험을 방지한다.

필요에 따라 클라이언트 인증도 수행될 수 있다. 이는 서버가 클라이언트의 신원을 확인해야 하는 높은 보안이 요구되는 환경에서 사용된다. 클라이언트 인증은 서버가 클라이언트에게 자신의 인증서를 요청하고, 클라이언트가 서명을 생성하여 응답하는 방식으로 이루어진다. 인증의 강도는 협상된 암호화 스위트와 사용된 인증서의 종류(예: RSA, ECDSA)에 따라 달라진다. 인증 실패 시 연결은 거부된다.

디지털 인증서는 전송 계층 보안 연결에서 상대방의 신원을 확인하고, 그 신원에 바인딩된 공개 키를 안전하게 전달하는 역할을 한다. 이는 공개키 기반구조의 핵심 구성 요소로서, 클라이언트(예: 웹 브라우저)가 접속하려는 서버(예: 웹사이트)가 자신이 주장하는 정당한 주체인지를 검증하는 근거를 제공한다. 인증서에는 서버의 도메인 이름, 소유 조직 정보, 서버의 공개 키, 인증서 발급자(인증 기관) 정보, 유효 기간 등이 포함되어 있으며, 이 모든 정보는 발급 인증 기관의 디지털 서명으로 보호된다.

인증서의 주요 역할은 신뢰의 전이를 가능하게 하는 것이다. 사용자나 클라이언트 소프트웨어는 미리 신뢰할 수 있는 루트 인증 기관 목록을 가지고 있다. 서버가 제시하는 인증서가 이들 중 하나로부터 발급되었고, 서명이 유효하며, 도메인 이름이 일치하고, 유효 기간 내에 있다면, 클라이언트는 해당 서버의 신원과 공개 키를 신뢰할 수 있다. 이 과정을 통해 중간자 공격을 방지한다. 공격자가 중간에 개입하여 자신의 공개 키를 제공하려 해도, 신뢰할 수 있는 인증 기관의 서명이 없는 인증서는 클라이언트에 의해 거부된다.

따라서 디지털 인증서는 단순한 공개 키 전달 매체를 넘어, 인터넷 상에서 신뢰할 수 있는 통신 상대를 식별하는 데 필수적인 디지털 신분증 역할을 한다. 이 메커니즘 없이는 HTTPS를 통한 안전한 웹 브라우징, 전자 상거래, 이메일 암호화 등이 사실상 불가능해진다.

인증 기관(CA)은 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제3자 기관이다. 이 기관은 인증서 신청자의 신원을 확인한 후, 해당 신청자의 공개 키와 정보를 담은 디지털 인증서에 자신의 디지털 서명을 한다. 이 서명은 CA의 개인 키로 생성되며, 인증서의 내용이 위조되거나 변조되지 않았음을 보증한다. 클라이언트(예: 웹 브라우저)는 미리 내장된 신뢰할 수 있는 루트 CA 인증서 목록을 가지고 있으며, 서버로부터 받은 인증서의 서명이 이들 중 하나에 의해 검증될 수 있을 때 해당 서버를 신뢰한다.

신뢰 체인은 루트 인증서, 중간 인증서, 최종 엔티티(서버) 인증서로 구성된 계층적 구조이다. 루트 CA는 스스로에게 서명한(self-signed) 최상위 인증서를 보유하며, 이 인증서는 보안을 위해 오프라인 상태로 유지되는 경우가 많다. 루트 CA는 일반적으로 중간 CA의 인증서를 발급하는 데 사용되며, 중간 CA가 실제 서버나 클라이언트용 최종 인증서를 발급하는 업무를 담당한다. 이 다단계 구조는 루트 CA의 개인 키가 노출될 위험을 줄이고, 인증서 발급 및 폐지 관리를 유연하게 만든다.

클라이언트가 서버 인증서를 검증할 때는 이 신뢰 체인을 따라 올라가며 서명을 확인한다. 서버는 자신의 인증서와 함께, 해당 인증서에 서명한 중간 CA의 인증서를 함께 전송한다. 클라이언트는 내장된 루트 CA 인증서를 사용해 중간 CA 인증서의 서명을 검증하고, 검증된 중간 CA 인증서로 다시 서버 인증서의 서명을 검증한다. 이 과정에서 한 단계라도 서명 검증에 실패하거나 인증서가 폐지된 경우[7], 연결은 중단된다. 이 체인 구조는 전 세계적인 공개키 기반구조(PKI)의 핵심을 이루며, 전송 계층 보안의 인증 기능을 가능하게 한다.

전송 계층 보안 역사에서 여러 주요 취약점과 공격이 발견되어 프로토콜의 발전과 구현 방식에 큰 영향을 미쳤다.

POODLE 공격은 2014년 공개된 SSL 3.0 프로토콜의 취약점을 이용한 공격이다. 이 공격은 패딩 오라클을 악용하여 암호화된 세션 쿠키와 같은 정보를 점진적으로 해독할 수 있었다. POODLE 공격의 위험성은 SSL 3.0이 오래된 프로토콜임에도 불구하고, 호환성을 위해 많은 클라이언트와 서버가 이를 여전히 지원한다는 점에서 비롯되었다. 이 공격의 주요 대응책은 서버와 클라이언트 양측에서 SSL 3.0 지원을 완전히 비활성화하는 것이었다.

BEAST 공격은 2011년 발표된 TLS 1.0 및 그 이전 버전의 블록 암호 운용 모드에 존재하는 취약점을 표적으로 삼았다. 이 공격은 초기화 벡터 예측 가능성을 이용하여 암호화된 트래픽을 해독할 수 있었다. BEAST 공격을 완화하기 위한 임시 조치로 RC4 암호화 스위트 사용이 권장되기도 했으나, 이후 RC4 자체의 취약점이 발견되면서 이 방법은 권장되지 않게 되었다. 근본적인 해결책은 TLS 1.1 이상의 버전으로 업그레이드하는 것이었다.

Heartbleed 버그는 2014년 발견된 OpenSSL 암호화 라이브러리의 심각한 구현상 결함이었다. 이는 TLS 프로토콜 자체의 문제라기보다는 널리 사용되는 소프트웨어 구현체의 보안 허점이었다. Heartbleed 버그는 하트비트 확장 기능에서 입력 검증 부재로 인해 발생했으며, 공격자가 서버의 메모리 내용을 최대 64KB씩 읽어들일 수 있게 했다. 이로 인해 서버의 개인 키, 사용자 세션 쿠키, 비밀번호 등 민감한 정보가 유출될 위험이 있었다. 전 세계 수백만 개의 웹사이트가 영향을 받았으며, 패치 적용과 인증서 재발급이 긴급히 이루어져야 했다.

이러한 공격들은 프로토콜 설계의 결함과 소프트웨어 구현의 오류가 모두 보안 위협이 될 수 있음을 보여주었다. 이에 대한 대응으로 오래되고 안전하지 않은 프로토콜 버전과 암호화 스위트의 사용 중단이 촉진되었으며, 소프트웨어 라이브러리의 코드 검증과 보안 감사에 대한 중요성이 더욱 부각되었다.

다운그레이드 공격은 공격자가 통신 당사자 간의 협상 과정을 조작하여, 지원하는 가장 안전한 프로토콜 버전 대신 더 오래되고 취약한 버전(예: TLS 1.2 대신 SSL 3.0 또는 TLS 1.0)을 사용하도록 강제하는 보안 공격이다. 이 공격의 목표는 구버전 프로토콜에 알려진 취약점을 이용하여 통신의 기밀성이나 무결성을 훼손하는 것이다.

이 공격은 일반적으로 핸드셰이크 프로토콜 초기 단계에서 이루어진다. 클라이언트가 서버에 지원 가능한 최고 프로토콜 버전 목록을 보내면, 중간자 공격자가 이 메시지를 가로채 지원 목록을 조작하거나 서버의 응답을 변조하여 양측이 취약한 버전을 선택하도록 만든다. 대표적인 예로 2014년 발견된 POODLE 공격은 SSL 3.0의 취약점을 이용하기 위해 TLS 버전을 SSL 3.0으로 다운그레이드시키는 방식을 사용했다.

이러한 공격을 방어하기 위해 현대의 TLS 구현체에는 다운그레이드 방지 메커니즘이 도입되었다. TLS 1.3에서는 핸드셰이크 완료 시 교환된 메시지에 서명하여 협상된 버전이 조작되지 않았음을 검증한다[10]. 또한, 서버와 클라이언트는 오래된 안전하지 않은 버전(SSL 2.0, 3.0, TLS 1.0, 1.1 등)에 대한 지원을 완전히 중단하는 것이 권장된다.

인증서 만료는 가장 흔히 발생하는 디지털 인증서 관련 문제 중 하나이다. 모든 인증서는 유효 기간이 명시되어 있으며, 이 기간이 지나면 더 이상 유효하지 않게 된다. 만료된 인증서를 사용하는 서버에 접속하려고 하면 클라이언트(예: 웹 브라우저)는 보안 경고를 표시하고 연결을 차단한다. 이는 인증서의 개인 키가 장기간 노출될수록 해독될 위험이 증가하기 때문에 의도된 보안 조치이다. 시스템 관리자는 인증서의 만료 일정을 주기적으로 모니터링하고 갱신해야 한다.

신뢰할 수 없는 인증 기관(CA)에서 발급한 인증서 역시 주요 문제를 일으킨다. 클라이언트는 미리 정의된 '신뢰할 수 있는 루트 인증서 저장소'를 가지고 있으며, 서버의 인증서가 이 저장소에 없는 CA나 중간 CA에 의해 서명된 경우 연결을 신뢰하지 않는다. 이는 합법적인 조직이 자체 서명 인증서를 사용하거나, 클라이언트가 인식하지 못하는 소규모 CA를 이용할 때 발생할 수 있다. 더 심각한 경우는 악의적인 공격자가 합법적인 CA를 속이거나 해킹하여 위조 인증서를 발급받거나, 사용자의 저장소에 가짜 루트 인증서를 설치하는 것이다[11].

인증서의 주체 정보(예: 도메인 이름)가 실제 서버와 일치하지 않는 '도메인 이름 불일치' 오류도 빈번하다. 이는 하나의 인증서로 여러 도메인을 커버하지 못할 때, 특히 'www' 접두사 유무와 같은 사소한 차이에서도 발생한다. 또한, 인증서 서명 알고리즘이 취약해지거나(예: SHA-1), 키 길이가 너무 짧은 경우 보안 표준을 충족하지 못해 경고를 유발한다.

이러한 문제들을 완화하기 위해 인증서 투명성(CT) 로그, ACME 프로토콜을 통한 자동화된 인증서 관리(예: Let's Encrypt), 그리고 정기적인 보안 감사와 같은 기술과 관행이 도입되고 있다.

TLS 1.3은 전송 계층 보안 프로토콜의 주요 개정판으로, 보안성 강화와 성능 향상에 중점을 두었다. 이전 버전들에 비해 설계가 단순해지고 불필요한 기능이 제거되어 공격 표면이 줄어들었다. 가장 큰 변화는 핸드셰이크 과정의 단순화와 암호화 스위트의 현대화이다.

핸드셰이크 프로토콜이 크게 개선되어 연결 설정 시간이 단축되었다. 제로 RTT 모드를 지원하여, 이전에 연결한 적이 있는 서버와의 재접속 시 첫 번째 요청부터 데이터를 암호화하여 전송할 수 있다. 또한 핸드셰이크 과정에서 지원하는 암호화 방식을 협상하는 방식이 변경되어, 클라이언트가 처음부터 몇 가지 후보군만을 제안하고 서버가 그 중 하나를 선택하는 방식으로 바뀌었다. 이를 통해 다운그레이드 공격의 위험을 크게 낮췄다.

보안 측면에서는 오래되고 안전하지 않은 암호화 알고리즘과 기능을 대거 제거했다. 다음 표는 TLS 1.3에서 제거된 주요 요소를 보여준다.

마지막으로, 전달 암호화가 핵심 요구사항이 되었다. 세션 키는 일시적인 디피-헬만 키 교환을 통해 생성되어, 장기적인 개인키가 유출되더라도 과거의 통신 세션을 복호화할 수 없게 보장한다. 이로 인해 프로토콜의 보안 수준이 전반적으로 향상되었다.

향후 전송 계층 보안의 발전은 보안성 강화, 성능 최적화, 그리고 새로운 사용 사례와 기술에의 적응을 중심으로 이루어질 것으로 예상된다. 핵심 목표는 암호화의 범위를 확대하고 프로토콜의 복잡성을 줄이며, 양자 컴퓨팅과 같은 미래의 위협에 대비하는 것이다.

한 가지 중요한 방향은 암호화의 범위를 핸드셰이크 과정 전체로 확대하는 것이다. TLS 1.3은 이미 핸드셰이크 메시지의 대부분을 암호화했지만, 여전히 서버 이름 표시와 같은 일부 메타데이터는 평문으로 전송된다. 향후 버전에서는 이러한 정보도 암호화하여 사용자의 프라이버시를 더욱 강화하는 완전한 암호화 핸드셰이크를 지향할 것이다. 또한, 포스트-양자 암호의 표준화와 통합이 활발히 진행되고 있다. 미국 국립표준기술연구소와 같은 기관의 표준화 작업 이후, 양자 컴퓨터 공격에도 안전한 새로운 암호화 알고리즘이 TLS의 암호화 스위트에 추가될 전망이다.

사용 편의성과 자동화도 중요한 발전 축이다. 인증서 관리의 복잡성을 해결하기 위해 자동 인증서 관리 환경과 같은 프로토콜의 광범위한 채택이 예상된다. 이는 인증서 발급, 갱신, 해지 과정을 자동화하여 관리 부담과 인적 오류를 줄인다. 성능 측면에서는 0-RTT 모드의 안전성 개선 및 새로운 네트워크 프로토콜(예: QUIC)과의 긴밀한 통합이 계속될 것이다. 아래 표는 주요 발전 방향을 요약한 것이다.

또한, 사물인터넷과 같은 제한된 환경의 장치에서도 TLS를 효율적으로 사용할 수 있도록, 경량화된 구현과 에너지 효율적인 암호화 방식에 대한 연구가 지속될 것이다. 궁극적으로 TLS는 더 빠르고, 더 안전하며, 보이지 않게 동작하는 방향으로 진화하여 인터넷 통신의 보이지 않는 기반이 되도록 발전해 나갈 것이다.

서버에서 TLS를 활성화하려면, 먼저 디지털 인증서와 개인 키를 획득하고 구성해야 한다. 인증서는 신뢰할 수 있는 인증 기관으로부터 발급받거나, 테스트 목적으로 자체 서명된 인증서를 생성할 수 있다. 대표적인 웹 서버 소프트웨어인 Apache HTTP Server나 Nginx에서는 설정 파일을 수정하여 인증서 파일과 키 파일의 경로를 지정하고, 사용할 TLS 버전과 암호화 스위트를 정의한다. 서버 관리자는 오래된 SSL 버전과 알려진 취약점이 있는 암호화 알고리즘을 비활성화하여 보안 수준을 높이는 것이 권장된다.

클라이언트 측면에서 대부분의 현대 웹 브라우저와 애플리케이션은 기본적으로 TLS를 지원한다. 사용자는 특별한 설정 없이 HTTPS 사이트에 안전하게 접속할 수 있다. 그러나 애플리케이션을 개발하거나 특수한 클라이언트 소프트웨어를 구성하는 경우, 서버의 인증서를 검증하는 루트 인증서 저장소를 올바르게 관리해야 한다. 또한 클라이언트는 서버가 지원하는 가장 강력한 암호화 스위트를 협상하도록 설정될 수 있다.

서버 설정 시 고려해야 할 주요 항목은 다음과 같다.

이러한 설정은 서버의 보안 강도와 호환성에 직접적인 영향을 미친다. 설정 완료 후에는 SSL Labs 등의 온라인 도구를 이용하여 서버의 TLS 구성이 적절한지 점검하고 등급을 확인하는 것이 일반적이다.

전송 계층 보안 연결의 성능은 핸드셰이크 지연, 암호화/복호화 연산 부하, 네트워크 왕복 시간 등 여러 요소의 영향을 받는다. 핸드셰이크 과정은 완전한 연결 수립 전에 여러 번의 네트워크 왕복을 필요로 하므로, 특히 지리적으로 멀리 떨어진 클라이언트와 서버 간에 지연을 유발한다. 이를 완화하기 위해 세션 재개나 TLS 1.3의 0-RTT(Zero Round-Trip Time) 핸드셰이크 같은 기법이 사용된다. 또한, 선택하는 암호화 스위트에 따라 필요한 CPU 연산량이 크게 달라지며, AES와 같은 현대 암호화 방식은 하드웨어 가속을 지원하는 프로세서에서 훨씬 효율적으로 실행된다.

서버 측에서는 동시에 처리해야 하는 많은 수의 TLS 연결이 주요 성능 병목 지점이 될 수 있다. 이를 관리하기 위해 TLS 오프로딩을 수행하는 전용 하드웨어 가속기나 로드 밸런서를 사용하거나, Nginx, Apache 같은 소프트웨어의 효율적인 연결 관리 기능을 활용한다. 클라이언트 측에서는 모바일 장치와 같이 계산 자원이 제한된 환경에서 배터리 수명과 응답 속도에 영향을 미칠 수 있다.

최적의 성능을 위해서는 강력한 보안과 효율성을 함께 제공하는 최신 TLS 1.3 프로토콜을 사용하고, 오래되고 비효율적인 암호화 알고리즘을 사용하지 않도록 암호화 스위트를 신중하게 구성하는 것이 중요하다. 또한, HTTP/2나 HTTP/3와 함께 사용될 때는 단일 연결을 통한 멀티플렉싱이 성능에 긍정적인 영향을 미친다.

DTLS는 UDP와 같은 비연결형 전송 프로토콜 상에서 전송 계층 보안의 보안 서비스를 제공하기 위해 설계된 프로토콜이다. 기본적으로 TLS 프로토콜은 신뢰성 있는 전송을 전제로 하기 때문에 TCP와 같은 연결 지향형 프로토콜과 함께 사용된다. 그러나 UDP는 패킷 손실, 재전송, 순서 변경이 발생할 수 있는 환경에서 사용되므로, TLS를 직접 적용하기에는 어려움이 있다. DTLS는 이러한 환경에서도 기밀성, 무결성, 인증을 제공하기 위해 TLS를 수정한 버전이다.

DTLS의 핵심 설계 목표는 가능한 한 TLS와 유사하게 동작하면서도, UDP의 비연결적 특성과 잠재적인 패킷 손실을 처리하는 것이다. 이를 위해 DTLS는 TLS의 핸드셰이크 프로토콜에 재전송 타이머와 시퀀스 번호를 추가한다. 클라이언트와 서버는 응답이 지연되거나 손실될 경우 핸드셰이크 메시지를 재전송하여 연결 설정을 완료한다. 또한, DTLS 레코드 계층은 TLS와 달리 명시적인 시퀀스 번호를 포함하여 재전송 공격을 방지한다.

DTLS는 주로 지연에 민감하거나 실시간 통신이 필요한 애플리케이션에서 널리 사용된다. 대표적인 예로는 VoIP, 화상 회의, 온라인 게임, 그리고 IoT 기기 간 통신이 있다. 특히 WebRTC 표준은 보안된 미디어 스트리밍을 위해 DTLS를 필수 구성 요소로 채택하고 있다[12].

DTLS는 현재 두 가지 주요 버전, 즉 DTLS 1.0(TLS 1.1 기반)과 DTLS 1.2(TLS 1.2 기반)가 표준화되어 있다. TLS 1.3에 대응하는 DTLS 1.3도 표준화 진행 중이다. 이러한 발전은 지속적으로 증가하는 실시간 및 비연결형 통신의 보안 요구사항을 충족시키기 위한 것이다.

HTTPS는 HTTP 프로토콜에 전송 계층 보안을 적용한 보안 통신 방식이다. 기본적으로 HTTP는 평문으로 데이터를 전송하기 때문에 도청이나 변조의 위험이 존재한다. HTTPS는 이러한 문제를 해결하기 위해 HTTP 통신을 TLS 프로토콜 위에서 수행하도록 설계되었다. 이는 네트워크 상에서 전송되는 모든 데이터가 암호화되어 기밀성과 무결성을 보장받는다는 것을 의미한다.

HTTPS의 작동은 클라이언트(예: 웹 브라우저)가 서버에 접속할 때 이루어지는 TLS 핸드셰이크로 시작한다. 이 과정에서 서버는 자신의 신원을 증명하는 디지털 인증서를 제공하고, 양측은 안전한 통신에 사용할 세션 키를 협상한다. 핸드셰이크가 성공적으로 완료되면, 이후의 모든 HTTP 요청과 응답은 TLS 레코드 프로토콜을 통해 암호화된 채널을 거쳐 전송된다. 사용자 관점에서는 웹 주소가 'http://' 대신 'https://'로 시작하며, 대부분의 브라우저는 주소창에 자물쇠 아이콘을 표시하여 보안 연결 상태를 시각적으로 알려준다.

HTTPS의 채택은 웹 보안의 표준이 되었다. 주요 검색 엔진들은 HTTPS를 사용하는 사이트에 검색 결과 순위에서 가산점을 주는 등 적극적으로 장려하고 있다[13]. 또한 HTTP/2와 같은 최신 웹 프로토콜은 대부분의 구현에서 HTTPS를 필수 요구사항으로 삼고 있다. 이는 성능 향상 기능이 평문 HTTP에서 악용될 수 있는 보안 취약점을 방지하기 위함이다.

현대 웹에서는 로그인, 결제, 개인정보 조회 등 모든 민감한 정보 교환에 HTTPS가 필수적이다. 단순한 정보 제공 사이트에서도 사용자 프라이버시 보호와 통신 내용의 변조 방지를 위해 HTTPS를 기본으로 적용하는 것이 권장된다.