보안 소켓 계층편집자 확인

넷스케이프 커뮤니케이션스의 엔지니어 팀이 1994년에 개발을 시작했다. 당시 월드 와이드 웹의 폭발적 성장과 함께 온라인 상거래에 대한 수요가 증가하면서, 네트워크를 통한 데이터 전송의 보안 문제가 대두되었다. 이에 넷스케이프는 안전한 통신 채널을 제공할 목적으로 보안 소켓 계층 프로토콜을 설계했다.

초기 버전인 SSL 1.0은 심각한 보안 결함으로 인해 공식적으로 발표되지 않았다. 첫 번째 공개 버전은 1995년 2월에 발표된 SSL 2.0이다. 그러나 이 버전도 여러 취약점을 가지고 있었는데, 특히 MAC(메시지 인증 코드)의 부재와 취약한 암호화 방식이 문제였다[2].

이러한 결함을 해결하기 위해 넷스케이프는 1996년에 SSL 3.0을 발표했다. SSL 3.0은 완전히 재설계되어 이전 버전의 주요 보안 문제를 대부분 해결했다. 핵심 개선 사항은 다음과 같다.

SSL 3.0은 핸드셰이크 프로토콜을 강화하고, 암호화와 메시지 인증을 위한 별도의 키를 생성하며, 더 많은 암호화 스위트를 지원했다. 이 버전은 이후 20년 가까이 인터넷 보안의 사실상 표준으로 자리 잡았으나, 2014년 POODLE 취약점이 발견되면서 공식적으로 폐기 권고를 받게 되었다. SSL 3.0의 설계는 이후 전송 계층 보안(TLS) 프로토콜의 기초가 되었다.

SSL 3.0 이후, 인터넷 엔지니어링 태스크 포스는 SSL 프로토콜의 표준화를 위해 작업을 시작했다. 이 과정에서 넷스케이프 커뮤니케이션스로부터 독립된 개방형 표준을 만들기로 결정했고, 그 결과물이 전송 계층 보안 1.0이다. TLS 1.0은 1999년 1월 RFC 2246으로 공표되었다.

TLS는 SSL 3.0을 기반으로 하지만 여러 중요한 보안 및 기능적 개선이 이루어졌다. 주요 차이점은 다음과 같다.

이후 TLS는 지속적으로 발전하여 더 강력한 버전이 출시되었다. TLS 1.1(2006년, RFC 4346)은 CBC 모드 공격에 대한 보호를 추가했고, TLS 1.2(2008년, RFC 5246)는 SHA-256 같은 더 강력한 해시 함수를 지원하고 암호화 스위트의 협상 방식을 현대화했다. 최종적으로 TLS 1.3(2018년, RFC 8446)은 핸드셰이크를 단순화하고 오래된 암호화 알고리즘을 제거하여 보안과 성능을 크게 향상시켰다.

현재 SSL과 그 초기 버전들은 심각한 보안 취약점으로 인해 사용이 중단되었다. 주요 보안 표준 및 브라우저, 서버 벤더들은 SSL 2.0과 SSL 3.0의 사용을 금지하고 TLS 1.2 이상의 사용을 권장한다. 따라서 현대의 보안 통신은 기술적으로나 용어상으로 모두 'TLS'를 기준으로 하지만, 역사적인 이유와 인지도로 인해 'SSL'이라는 명칭이 여전히 널리 통용되고 있다[3].

핸드셰이크 프로토콜은 보안 소켓 계층 또는 TLS 연결이 시작될 때 수행되는 일련의 협상 과정이다. 이 프로토콜의 주요 목적은 통신 당사자 간의 신원을 확인하고, 사용할 암호화 스위트를 합의하며, 실제 데이터 암호화에 사용될 대칭키를 안전하게 교환하는 것이다. 핸드셰이크는 클라이언트와 서버가 보안 채널을 설정하기 위해 필요한 모든 매개변수를 설정하는 기초 작업을 수행한다.

핸드셰이크 과정은 일반적으로 다음과 같은 단계로 진행된다. 먼저 클라이언트가 'ClientHello' 메시지를 서버로 보낸다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 지원 가능한 암호화 스위트 목록, 그리고 '클라이언트 무작위 값'이라고 불리는 난수 데이터가 포함된다. 서버는 'ServerHello' 메시지로 응답하며, 협상된 프로토콜 버전과 선택된 암호화 스위트, 서버의 난수('서버 무작위 값')를 전송한다. 이후 서버는 자신의 디지털 인증서를 'Certificate' 메시지로 보내고, 필요시 클라이언트 인증서를 요청할 수 있다. 서버는 'ServerHelloDone' 메시지를 보내 이 단계를 마친다.

클라이언트는 서버의 인증서를 검증한 후, 'pre-master secret'이라는 또 다른 비밀 값을 생성한다. 이 값은 서버의 공개키로 암호화되어 'ClientKeyExchange' 메시지에 담겨 서버로 전송된다[4]]을 사용하는 경우 프로세스는 다르게 진행된다]. 이 시점에서 클라이언트와 서버는 클라이언트 무작위 값, 서버 무작위 값, pre-master secret을 결합하여 동일한 '마스터 시크릿'을 독립적으로 생성한다. 이 마스터 시크릿은 세션 키를 생성하는 데 사용되는 근원 자료다. 이후 양측은 'ChangeCipherSpec' 메시지를 교환하여 협상이 완료되었음을 알리고, 협상된 보안 매개변수를 사용하여 이후 통신을 암호화하기 시작한다. 마지막으로 암호화된 'Finished' 메시지를 교환하여 핸드셰이크 과정의 무결성과 인증을 확인한다.

핸드셰이크 방식은 선택된 키 교환 알고리즘에 따라 세부 단계가 달라질 수 있다. 예를 들어, ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)를 사용하는 경우, 서버는 'Certificate' 메시지 이후에 서버의 임시 디피-헬만 키 교환 매개변수를 포함하는 'ServerKeyExchange' 메시지를 보내고, 클라이언트도 이에 상응하는 매개변수를 'ClientKeyExchange' 메시지에 포함시킨다. 이는 전달 비밀성을 제공하는 데 중요하다. 핸드셰이크가 성공적으로 완료되면, 양측은 동일한 세션 키를 공유하게 되며, 이를 이용해 대칭키 암호 방식으로 애플리케이션 데이터의 기밀성과 무결성을 보장한다.

암호화 스위트는 SSL/TLS 핸드셰이크 과정에서 협상되어 세션의 보안 매개변수를 정의하는 알고리즘 조합이다. 이는 키 교환, 인증, 대칭 암호화, 메시지 인증 코드 등 핵심 보안 기능을 수행할 네 가지 구성 요소를 명시한다.

일반적인 암호화 스위트의 구성 요소와 그 예는 다음과 같다.

암호화 스위트는 위 구성 요소들을 하나의 식별자로 표현하며, 예를 들어 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256은 타원곡선 디피-헬만(E) 임시(DHE) 키 교환, RSA 서버 인증, 128비트 AES-GCM 암호화, SHA256을 기반으로 하는 무결성 검증을 사용함을 의미한다. 시간이 지남에 따라 RC4, DES와 같이 취약해진 알고리즘은 스위트에서 제거되고, AES-GCM이나 ChaCha20-Poly1305 같은 더 강력하고 효율적인 알고리즘으로 대체되었다.

클라이언트와 서버는 핸드셰이크 초기에 각자가 지원하는 암호화 스위트 목록을 교환한다. 서버는 이 목록을 검토하고 공통적으로 지원하는 가장 강력한 스위트를 선택하여 세션을 설정한다. 이 협상 과정을 통해 다양한 장치와 소프트웨어 버전 간의 호환성을 유지하면서도 가능한 최고 수준의 보안을 제공한다.

SSL/TLS 연결에서 신원 확인과 암호화 키 교환의 핵심은 디지털 인증서와 공개키 기반 구조(PKI)에 기반합니다. 서버(때로는 클라이언트도)는 신원을 증명하기 위해 인증서를 제시합니다. 이 인증서는 서버의 공개 키와 도메인명, 소유자 정보 등을 포함하며, 신뢰할 수 있는 제3자인 인증 기관(CA)의 디지털 서명으로 보호됩니다.

인증서의 유효성 검증 과정은 다음과 같습니다. 클라이언트(예: 웹 브라우저)는 내장된 신뢰할 수 있는 루트 인증서 저장소를 사용하여 서버가 제시한 인증서의 서명 체인을 검증합니다. 이 체인은 서버 인증서부터 중간 CA 인증서를 거쳐 최상위 루트 CA까지 이어집니다. 각 단계에서 상위 인증서의 공개 키로 하위 인증서의 서명을 검증함으로써, 최종적으로 신뢰할 수 있는 루트 CA로부터 발급되었다는 것을 확인합니다. 또한 인증서의 유효 기간, 도메인명 일치 여부, 취소 상태(CRL 또는 OCSP[5]를 통해 확인)도 검사합니다.

공개키 기반 구조는 이러한 인증서의 생성, 배포, 관리, 폐기까지의 전 과정을 규정하는 프레임워크입니다. 주요 구성 요소는 다음과 같습니다.

이 체계를 통해 클라이언트는 서버의 공개 키를 안전하게 획득하고, 이후 비대칭 암호화를 통해 세션 키를 교환하여 안전한 통신 채널을 수립할 수 있습니다.

기밀성은 SSL/TLS가 제공하는 가장 근본적인 보안 서비스 중 하나이다. 이는 통신 중인 두 당사자 사이에 교환되는 데이터가 제3자에게 노출되지 않도록 보장하는 것을 의미한다. SSL은 이를 위해 대칭키 암호화 방식을 사용하여 실제 데이터를 암호화한다. 핸드셰이크 과정에서 협상된 암호화 스위트에 포함된 대칭키 알고리즘(예: AES, 3DES)과 세션 키를 이용해 애플리케이션 데이터를 암호화한다.

기밀성을 달성하는 과정은 두 단계로 나뉜다. 첫째, 핸드셰이크 프로토콜을 통해 안전하게 공유된 세션 키를 생성한다. 이 키는 클라이언트와 서버만이 알 수 있으며, 공개키 암호화를 통해 교환되거나 디피-헬먼 키 교환과 같은 방식으로 협상된다. 둘째, 이 세션 키를 사용하여 레코드 프로토콜 단계에서 모든 애플리케이션 데이터를 암호화한다. 결과적으로 네트워크를 도청하는 공격자는 암호화된 패킷을 획득하더라도 세션 키 없이는 원본 데이터를 복원할 수 없다.

기밀성은 개인정보나 금융 정보, 로그인 자격 증명과 같은 민감한 데이터를 전송할 때 필수적이다. SSL/TLS가 적용되지 않은 일반 HTTP 연결에서는 이러한 데이터가 평문으로 전송되어 중간자 공격에 취약하다. 따라서 기밀성 보장은 온라인 뱅킹, 전자상거래, 이메일 등 보안이 요구되는 모든 웹 통신의 토대가 된다.

무결성은 전송 중인 데이터가 의도치 않게 변경되거나 변조되지 않았음을 보장하는 보안 소켓 계층의 핵심 기능이다. 이는 메시지 인증 코드를 통해 달성된다. 핸드셰이크 과정에서 협상된 암호화 스위트에 포함된 해시 함수를 사용하여, 전송할 데이터(평문 또는 암호문)로부터 고정 길이의 짧은 요약 값을 생성한다. 이 요약 값은 대칭키 암호로 암호화된 데이터와 함께 수신자에게 전송된다.

수신 측은 동일한 해시 함수와 공유된 비밀 키를 사용하여 수신된 데이터로부터 직접 MAC 값을 다시 계산한다. 이렇게 계산된 값과 전송되어 온 MAC 값을 비교하여 일치 여부를 확인한다. 두 값이 일치하면 데이터가 전송 과정에서 단 한 비트도 변경되지 않았음을 의미한다. 만약 중간자 공격 등으로 데이터가 변조되었다면, 해시 함수의 특성상 전혀 다른 MAC 값이 생성되어 변조 사실이 즉시 드러난다.

초기 SSL 버전에서는 MD5와 같은 취약한 해시 알고리즘이 사용되기도 했으나, 현대의 TLS에서는 SHA-256 또는 그 이상의 강력한 암호화 해시 함수가 표준으로 채택된다. 무결성 검증은 기밀성과 함께 동작하여, 데이터가 암호화되어 내용을 볼 수 없을 뿐만 아니라, 암호화된 상태 그대로 안전하게 도착했는지도 보장한다.

인증은 통신 상대방의 신원을 확인하여 중간자 공격을 방지하는 보안 소켓 계층의 핵심 기능이다. 이 과정은 주로 공개키 기반 구조와 디지털 인증서를 통해 이루어진다. 서버는 클라이언트에게 자신의 공개키와 신원 정보가 포함된 인증서를 제공하며, 이 인증서는 신뢰할 수 있는 제3자인 인증 기관에 의해 서명되어 위변조가 불가능하다.

클라이언트(일반적으로 웹 브라우저)는 서버로부터 받은 인증서를 검증한다. 이 검증 과정에는 인증서의 유효 기간 확인, 발급자(인증 기관)의 신뢰성 확인(클라이언트에 내장된 신뢰할 수 있는 루트 인증서 저장소를 통해), 그리고 인증서의 디지털 서명이 정당한지 검사하는 작업이 포함된다. 이를 통해 클라이언트는 자신이 접속하려는 서버가 실제로 해당 도메인의 합법적인 소유자임을 신뢰할 수 있다.

상호 인증의 경우, 클라이언트도 서버에게 자신의 클라이언트 인증서를 제출해야 한다. 이는 일반적으로 덜 사용되지만, 매우 제한된 사용자 그룹에게만 접근을 허용해야 하는 시스템에서 강력한 보안을 제공한다. 인증 과정의 성공은 이후 안전한 키 교환과 암호화된 통신 세션 수립의 기초가 된다.

SSL 및 그 후속 프로토콜인 TLS는 월드 와이드 웹에서 가장 널리 구현되는 보안 프로토콜이다. 웹 서버와 웹 브라우저 간의 통신을 암호화하여 HTTP를 HTTPS로 전환하는 핵심 기술이다. 웹 서버는 인증서를 설치하고 특정 포트(일반적으로 443번)에서 SSL/TLS 연결을 수신 대기하도록 구성한다. 사용자가 'https://'로 시작하는 URL에 접근하면 브라우저는 서버와 핸드셰이크를 시작하고, 서버의 인증서를 검증한 후 암호화된 세션을 수립한다.

주요 웹 서버 소프트웨어는 모두 SSL/TLS를 지원한다. 아파치 HTTP 서버는 mod_ssl 모듈을, Nginx는 ngx_http_ssl_module을 통해 TLS 기능을 제공한다. 마이크로소프트의 IIS 역시 관리 콘솔을 통해 인증서를 바인딩하고 암호화 스위트를 구성할 수 있다. 이러한 서버들은 지원할 프로토콜 버전(예: TLS 1.2, TLS 1.3)과 암호화 알고리즘 조합을 관리자가 설정할 수 있도록 한다.

한편, 구글 크롬, 모질라 파이어폭스, 마이크로소프트 엣지, 애플 사파리와 같은 현대적인 웹 브라우저들은 강력한 SSL/TLS 구현을 내장하고 있다. 브라우저는 서버의 디지털 인증서가 신뢰할 수 있는 인증 기관에 의해 발급되었는지, 유효 기간이 만료되지 않았는지, 연결된 도메인 이름이 일치하는지 자동으로 검증한다. 검증에 실패하면 사용자에게 보안 경고를 표시한다. 브라우저들은 또한 오래되거나 안전하지 않은 프로토콜 버전과 암호화 스위트를 점차적으로 사용 중단하여 전체 웹 생태계의 보안 수준을 높이는 역할을 한다[8].

웹 표준 기구인 월드 와이드 웹 컨소시엄과 인터넷 엔지니어링 태스크 포스는 프로토콜 자체를 표준화할 뿐만 아니라, 브라우저와 서버의 상호운용성을 보장하고 보안 모범 사례를 장려한다. 최근에는 웹사이트가 HTTPS를 기본으로 사용하도록 강제하는 정책(예: HSTS)이 브라우저와 서버 양쪽에서 널리 채택되고 있다.

SSL/TLS는 월드 와이드 웹의 HTTPS를 넘어 다양한 네트워크 응용 프로그램에서 통신 보안을 제공하는 데 널리 사용된다. 전자 메일 프로토콜인 SMTP, IMAP, POP3는 각각 SMTPS, IMAPS, POP3S와 같은 명칭으로 SSL/TLS를 적용하여 전송 중인 이메일의 기밀성을 보호한다. 가상 사설망 기술인 OpenVPN은 트래픽 터널링을 위해 TLS 프로토콜을 핵심 요소로 활용한다. 또한, 인스턴트 메신저, VoIP 서비스, 그리고 다양한 클라이언트-서버 모델 기반의 엔터프라이즈 애플리케이션도 데이터 암호화와 서버 인증을 위해 SSL/TLS를 통합한다.

인터넷 프로토콜 스위트의 여러 프로토콜도 보안 강화를 위해 SSL/TLS를 채택했다. 예를 들어, LDAP는 LDAPS를 통해, 파일 전송 프로토콜은 FTPS를 통해 암호화된 연결을 제공한다. 시스템 로그 전송을 위한 Syslog 프로토콜에도 TLS를 적용한 보안 버전이 존재한다. 데이터베이스 관리 시스템 역시 MySQL, PostgreSQL 등이 클라이언트와 서버 간의 통신 채널을 암호화할 때 SSL/TLS를 사용한다.

이러한 광범위한 적용은 SSL/TLS가 전송 계층에서 동작하여 상위 계층의 애플리케이션 프로토콜에 독립적으로 보안 서비스를 제공할 수 있기 때문에 가능하다. 개발자는 OpenSSL, GnuTLS와 같은 암호화 라이브러리를 이용해 비교적 쉽게 자신의 애플리케이션에 TLS 지원을 추가할 수 있다. 결과적으로 SSL/TLS는 인터넷을 통한 데이터 교환의 보안을 담보하는 사실상의 표준 기반 기술로 자리 잡았다.

POODLE(Padding Oracle On Downgraded Legacy Encryption)은 2014년 10월 공개된 SSL 3.0 프로토콜의 설계 결함을 악용하는 보안 취약점이다. 이 공격은 공격자가 중간자 위치에서 암호화된 트래픽을 도청하고, 특정 조건 하에서 암호화된 세션 쿠키와 같은 민감한 정보를 한 바이트씩 복구할 수 있게 한다.

공격의 핵심은 블록 암호의 패딩(padding) 방식을 오라클(Oracle)로 사용하는 것이다. SSL 3.0은 CBC 모드를 사용할 때 패딩 바이트의 내용을 검증하지 않는다는 치명적 약점을 가지고 있다. 공격자는 먼저 클라이언트와 서버 간의 연결을 SSL 3.0으로 다운그레이드시킨다. 그 후, 피해자의 암호문 블록을 가로채 서버에 전송하고 서버의 응답(오류 메시지의 유무 또는 지연 시간)을 관찰함으로써 패딩이 정상적인지 여부를 판단하는 '패딩 오라클'을 획득한다. 이 정보를 바탕으로 반복적인 요청을 통해 암호문을 해독한다.

이 취약점에 대한 가장 효과적인 대응책은 서버와 클라이언트 양측에서 SSL 3.0 프로토콜 지원을 완전히 비활성화하는 것이다. 현대적인 브라우저와 웹 서버는 이후 이 프로토콜 지원을 제거하거나 기본적으로 사용하지 않도록 설정했다. 또한, TLS_FALLBACK_SCSV와 같은 메커니즘을 구현하여 프로토콜 다운그레이드 공격 자체를 방지하는 것이 권장된다. POODLE 공격은 오래된 프로토콜의 지속적 사용이 초래할 수 있는 위험을 보여주는 대표적 사례가 되었다.

Heartbleed는 2014년 4월에 공개된 OpenSSL 암호화 라이브러리의 심각한 보안 취약점(CVE-2014-0160)이다. 이 취약점은 TLS/SSL 프로토콜의 하트비트(Heartbeat) 확장 기능 구현에 존재하는 버퍼 오버리드(Buffer Over-read) 결함으로 인해 발생했다. 하트비트 기능은 연결이 활성 상태인지를 확인하기 위해 설계된 유지 메커니즘이지만, 취약한 버전의 OpenSSL에서는 적절한 경계 검사를 수행하지 못했다.

공격자는 악의적으로 조작된 하트비트 요청 패킷을 서버에 전송하여, 서버의 메모리(최대 64KB) 내용을 응답으로 유출시킬 수 있었다. 유출되는 데이터에는 서버의 개인키, 사용자 세션 쿠키 및 암호, 그리고 메모리에 일시적으로 저장된 기타 민감한 정보가 포함될 가능성이 있었다. 이 공격은 암호화된 연결 자체를 뚫는 것이 아니라, 암호화를 제공하는 소프트웨어의 결함을 이용했기 때문에 탐지가 매우 어려웠다.

이 취약점은 OpenSSL 1.0.1부터 1.0.1f 버전까지, 그리고 1.0.2 베타 버전에 존재했다. 당시 인터넷 상의 약 17%(추정)의 웹 서버가 취약한 OpenSSL을 사용하고 있었기 때문에[9], 전 세계적인 보안 위기를 초래했다. 패치는 취약점이 공개된 직후 OpenSSL 1.0.1g 버전에서 제공되었으며, 영향을 받는 모든 시스템 관리자들은 즉시 업데이트를 적용할 것을 권고받았다.

Heartbleed 사건은 오픈 소스 핵심 인프라의 보안 유지 관리와 자금 지원의 중요성을 부각시켰다. 또한, 단일 라이브러리의 결함이 전 세계 인터넷 보안에 미치는 광범위한 영향을 보여주는 상징적인 사례가 되었다. 사고 이후 많은 주요 웹사이트와 서비스 제공자들은 영향을 받은 디지털 인증서를 폐기하고 재발급하는 조치를 취해야 했다.