SSL/TLS는 인터넷 통신의 보안을 담당하는 핵심 프로토콜이다. 이 기술은 클라이언트와 서버 사이에 전송되는 데이터를 암호화하여 도청이나 변조를 방지한다. 주로 웹 브라우징, 이메일, 인스턴트 메시징 등 다양한 애플리케이션에서 사용되며, 웹에서는 HTTPS 프로토콜의 기반이 된다.
SSL/TLS의 핵심 기능은 크게 세 가지로 구분된다. 첫째는 암호화로, 제3자가 통신 내용을 알아볼 수 없도록 한다. 둘째는 무결성 검증으로, 데이터가 전송 중에 변경되지 않았음을 보장한다. 셋째는 인증으로, 통신 상대방이 자신이 주장하는 주체임을 확인한다. 이 인증 과정은 디지털 인증서를 통해 이루어진다.
이 프로토콜은 웹의 신뢰성과 프라이버시를 보호하는 데 필수적이다. 온라인 뱅킹, 전자 상거래, 개인정보 처리 등 민감한 정보를 다루는 모든 웹사이트는 SSL/TLS를 적용해야 한다. 최근에는 검색 엔진의 SEO 평가 요소로도 작용하며, 보안 표준으로 자리 잡았다.
SSL/TLS의 적용은 단순히 보안을 강화하는 것을 넘어, 사용자 신뢰를 구축하고 법적 규정 준수를 돕는다. 따라서 현대 웹 개발과 시스템 운영에서 이 인증서와 프로토콜에 대한 이해는 필수적이다.
SSL은 넷스케이프 커뮤니케이션스가 1990년대 중반에 개발한 보안 프로토콜이다. 이 프로토콜은 클라이언트와 서버 간의 통신을 암호화하여 도청과 변조를 방지하는 것을 목표로 했다. 이후 IETF에 의해 표준화되면서 TLS라는 이름으로 발전하게 되었다. 일반적으로 SSL과 TLS를 혼용하여 부르지만, 기술적으로는 TLS가 SSL의 후속 버전이다. SSL 3.0 이후의 모든 공식 버전은 TLS 1.0, 1.1, 1.2, 1.3으로 명명된다.
이 프로토콜들의 핵심 목적은 기밀성, 무결성, 인증을 제공하는 것이다. 기밀성은 대칭키 암호화를 통해 데이터를 제3자가 읽을 수 없게 만든다. 무결성은 메시지 인증 코드를 통해 전송 중 데이터가 변조되지 않았음을 보장한다. 인증은 공개키 인프라와 X.509 인증서를 사용하여 통신 상대방의 신원을 확인한다.
핸드셰이크 프로토콜은 SSL/TLS 연결이 시작될 때 실행되는 초기 협상 과정이다. 이 과정에서 클라이언트와 서버는 사용할 암호 스위트를 협상하고, 서버의 신원을 인증서로 확인하며, 세션에 사용할 대칭키를 안전하게 생성하고 교환한다. 핸드셰이크가 성공적으로 완료되면, 실제 데이터 전송은 생성된 대칭키로 암호화되어 레코드 프로토콜을 통해 이루어진다.
핸드셰이크의 주요 단계는 다음과 같다.
1. 클라이언트가 지원하는 프로토콜 버전과 암호 스위트 목록을 서버에 전송한다.
2. 서버는 인증서와 선택한 암호 스위트로 응답한다.
3. 클라이언트는 인증서를 검증하고, 프리마스터 시크릿을 생성하여 서버의 공개키로 암호화해 전송한다.
4. 양측은 프리마스터 시크릿으로부터 동일한 마스터 시크릿과 세션 키를 도출한다.
5. 핸드셰이크 완료 메시지를 교환하며 암호화된 통신 채널이 수립된다.
SSL은 1990년대 초 넷스케이프 커뮤니케이션스에 의해 개발된 최초의 널리 채택된 인터넷 보안 프로토콜이다. SSL 1.0은 공개되지 않았으며, SSL 2.0(1995년)과 SSL 3.0(1996년)이 실제 표준으로 자리 잡았다. SSL은 웹 브라우저와 서버 간의 통신을 암호화하여 데이터의 기밀성과 무결성을 보장하는 데 목적이 있었다.
1999년, 인터넷 엔지니어링 태스크 포스는 SSL 3.0을 기반으로 공개 표준 프로토콜인 TLS 1.0을 발표하였다. 이는 SSL과의 호환성을 유지하면서도 보다 표준화된 개방형 프로토콜로 전환하는 중요한 계기가 되었다. 기술적으로 TLS는 SSL과 유사한 구조를 가지지만, 암호화 알고리즘과 핸드셰이크 과정에서 차이를 보인다. 일반적으로 "SSL/TLS"로 병칭되지만, 현대의 보안 프로토콜은 사실상 TLS를 의미한다.
이후 보안 요구사항의 진화와 발견된 취약점에 대응하여 TLS는 지속적으로 개정되었다. TLS 1.1(2006년)과 TLS 1.2(2008년)는 각각 암호 블록 체인 모드와 새로운 암호화 스위트를 도입하여 보안을 강화했다. 특히 2018년에 표준화된 TLS 1.3은 핸드셰이크 과정을 단순화하고 레거시 암호화 방식을 제거하여 속도와 보안을 획기적으로 개선한 버전이다.
버전 | 공개 연도 | 주요 특징 및 비고 |
|---|---|---|
SSL 2.0 | 1995 | 넷스케이프가 개발. 현재는 심각한 취약점으로 인해 사용 중단됨. |
SSL 3.0 | 1996 | SSL 2.0의 취약점 보완. POODLE 공격[1]으로 인해 현재는 사용 권장되지 않음. |
TLS 1.0 | 1999 | IETF 표준(RFC 2246). SSL 3.0을 기반으로 하지만 호환되지 않음. |
TLS 1.1 | 2006 | CBC 모드에 대한 보호 강화(RFC 4346). |
TLS 1.2 | 2008 | 현대 암호화 알고리즘 지원 강화(RFC 5246). 오랫동안 사실상의 표준. |
TLS 1.3 | 2018 | 핸드셰이크 지연 감소, 보안성 극대화(RFC 8446). 현재 권장 버전. |
결과적으로 SSL은 역사적인 용어가 되었으며, 모든 현대적이고 안전한 구현은 TLS를 사용한다. 그러나 여전히 많은 시스템과 문서에서 익숙한 명칭인 "SSL"을 사용하여 TLS를 지칭하는 경우가 흔하다.
핸드셰이크 프로토콜은 SSL/TLS 연결이 수립되기 전에 클라이언트와 서버 간에 수행되는 일련의 협상 과정이다. 이 프로토콜의 핵심 역할은 보안 매개변수를 협상하고, 서버를 인증하며, 세션 키를 안전하게 생성하여 이후의 실제 데이터 암호화 통신에 사용할 대칭키를 공유하는 것이다. 핸드셰이크가 완료되면, 협상된 암호 스위트와 생성된 세션 키를 바탕으로 안전한 애플리케이션 계층 데이터 전송이 시작된다.
전형적인 핸드셰이크 과정은 다음과 같은 주요 단계로 구성된다. 먼저, 클라이언트는 ClientHello 메시지를 보내 지원하는 TLS 버전, 암호 스위트 목록, 클라이언트 무작위 값 등을 서버에 알린다. 서버는 ServerHello 메시지로 협상된 버전과 암호 스위트, 서버 무작위 값을 응답한다. 이어서 서버는 자신의 X.509 디지털 인증서를 Certificate 메시지로 전송하고, 필요에 따라 클라이언트 인증을 요청할 수 있다. 서버는 ServerHelloDone 메시지로 이 단계를 마친다.
단계 | 송신자 | 주요 메시지 | 목적 |
|---|---|---|---|
1 | 클라이언트 | ClientHello | 프로토콜 버전, 암호 스위트, 무작위 값 전송 |
2 | 서버 | ServerHello | 협상 결과 통보, 서버 무작위 값 전송 |
3 | 서버 | Certificate | 서버의 공개키가 포함된 인증서 전송 |
4 | 서버 | ServerKeyExchange[2] | 키 교환에 필요한 추가 데이터 전송 |
5 | 서버 | ServerHelloDone | 서버 메시지 전송 완료 신호 |
이후 클라이언트는 서버 인증서를 검증하고, ClientKeyExchange 메시지를 생성한다. 이 메시지에는 미리 마스터 시크릿을 생성하여 서버의 공개키로 암호화한 데이터나, 디피-헬먼 키 교환을 위한 공개 매개변수가 담긴다. 양측은 이 교환된 정보와 앞서 주고받은 무작위 값들을 이용하여 동일한 마스터 시크릿을 도출한다. 마지막으로, 이 마스터 시크릿으로부터 실제 데이터 암호화에 사용될 세션 키를 생성하고, ChangeCipherSpec과 Finished 메시지를 교환하여 핸드셰이크가 무결하게 완료되었음을 확인한다. 이 과정을 통해 도청과 변조로부터 보호되는 안전한 통신 채널이 확립된다.
인증서는 발급 대상과 검증 수준에 따라 도메인 유효성 인증서(DV), 조직 유효성 인증서(OV), 확장 유효성 인증서(EV)로 구분된다. DV 인증서는 도메인 소유권만을 빠르게 검증하며, 가장 저렴하고 발급이 간편하다. OV 인증서는 도메인 소유권에 더해 법인 등 조직의 실체를 추가로 확인한다. EV 인증서는 가장 엄격한 검증 절차를 거쳐 조직의 법적·물리적 존재를 확인하며, 브라우저 주소창에 회사명이 녹색으로 표시되는 것이 특징이다[3].
인증서는 단일 파일이 아닌 계층적 신뢰 구조, 즉 인증서 체인으로 구성된다. 최상위에는 신뢰의 근원인 루트 인증서(Root CA)가 위치하며, 주요 운영체제와 브라우저에 미리 내장되어 있다. 실제 서버에 설치되는 것은 리프 인증서(Leaf Certificate) 또는 최종 사용자 인증서이다. 이 둘을 연결하는 중간 계층의 중간 인증서(Intermediate Certificate)는 루트 CA의 개인키를 보호하기 위해 사용되며, 체인의 무결성을 보장하는 역할을 한다.
인증서의 형식과 내용은 X.509 표준에 의해 정의된다. 이 표준은 인증서의 버전, 일련번호, 서명 알고리즘, 발급자, 유효기간, 주체(소유자), 공개키 정보 등을 포함하는 구조를 명시한다. 이러한 데이터는 주로 PEM (Privacy-Enhanced Mail)이나 DER (Distinguished Encoding Rules) 형식으로 인코딩되어 저장 및 교환된다. PEM 형식은 BASE64로 인코딩된 텍스트 파일이며 -----BEGIN CERTIFICATE----- 헤더로 시작하는 반면, DER 형식은 바이너리 파일이다.
인증서 유형 | 검증 대상 | 일반적 용도 | 브라우저 표시 |
|---|---|---|---|
DV | 도메인 소유권 | 개인 블로그, 소규모 사이트 | 자물쇠 아이콘 |
OV | 도메인 + 조직 실체 | 기업 공식 사이트 | 자물쇠 아이콘 |
EV | 도메인 + 조직 실체 (강화된 검증) | 금융, 전자상거래 사이트 | 자물쇠 아이콘 + 조직명 (과거) |
도메인 유효성 인증서, 조직 유효성 인증서, 확장 유효성 인증서는 검증 수준과 제공하는 신뢰 정보에 따라 구분된다. 이들은 모두 X.509 표준을 따르며, 공인 인증기관이 발급한다. 검증 과정의 엄격함과 비용, 발급 소요 시간이 각기 다르다.
가장 기본적인 형태인 DV 인증서는 신청자가 특정 도메인 이름의 관리 권한을 가지고 있는지만 확인한다. 일반적으로 도메인의 WHOIS 이메일 주소로 확인 메일을 보내거나, 특정 DNS 레코드를 추가하는 방식으로 검증이 이루어진다. 발급이 빠르고 비용이 저렴하여 개인 블로그나 소규모 사이트에 널리 사용된다. 그러나 이 인증서는 도메인 소유권만을 증명할 뿐, 해당 도메인을 운영하는 조직의 실체에 대한 정보는 제공하지 않는다.
조직의 실체를 추가로 확인하는 OV 인증서는 도메인 소유권 검증에 더해, 신청 기업의 법적 등록 정보(상호, 주소 등)를 공인된 제3자 데이터베이스를 통해 검증한다. 이 과정은 수시간에서 수일이 소요될 수 있다. 인증서 내부에는 해당 조직 정보가 포함되어 있어, 사용자가 인증서 세부 정보를 확인하면 웹사이트를 운영하는 법인을 알 수 있다. 일반적인 기업 웹사이트나 전자상거래 플랫폼에서 주로 사용된다.
가장 높은 수준의 검증을 거치는 EV 인증서는 OV의 모든 검증 단계를 포함하며, 기업의 법적·물리적 실존 여부를 더욱 엄격하게 조사한다. 이는 정부 기관의 사업자 등록 정보, 전화번호 확인, 그리고 신청 담당자의 직위와 권한에 대한 확인 절차를 포함할 수 있다. 발급에는 보통 수일에서 수주가 걸린다. 이 인증서의 가장 큰 특징은 주요 웹 브라우저의 주소창에서 기업 이름을 녹색으로 직접 표시해 준다는 점이다[4]. 금융 기관이나 대형 온라인 결제 서비스와 같이 높은 신뢰가 요구되는 곳에서 사용된다.
검증 유형 | 검증 대상 | 발급 소요 시간 | 주소창 표시 | 주요 사용처 |
|---|---|---|---|---|
DV | 도메인 소유권 | 수분~수시간 | 자물쇠 아이콘 | 개인 사이트, 블로그, 테스트 환경 |
OV | 도메인 소유권 + 조직 실체 | 수시간~수일 | 자물쇠 아이콘 | 일반 기업 웹사이트, 전자상거래 |
EV | 도메인 소유권 + 조직 실체 (강화된 검증) | 수일~수주 | 자물쇠 아이콘 + 기업 이름 | 금융기관, 결제 게이트웨이, 대기업 포털 |
인증서 체인은 신뢰를 전달하는 계층적 구조로, 최종 사용자에게 제공되는 서버 인증서부터 최상위 루트 인증서까지 연결된 일련의 디지털 인증서를 의미한다. 이 체인은 클라이언트(예: 웹 브라우저)가 서버의 신원을 검증할 때, 알려지고 신뢰받는 루트 인증서로부터 시작하여 최종 서버 인증서까지의 신뢰 경로를 확인하는 데 사용된다.
체인은 일반적으로 세 가지 계층으로 구성된다. 최상위에는 루트 인증서가 위치한다. 이 인증서는 공인 인증기관(CA) 자체를 인증하는 자가 서명된 인증서로, 주요 웹 브라우저와 운영체제에 미리 내장되어 있다. 루트 CA는 직접 최종 인증서를 발급하기보다는, 중간 인증서 발급 권한을 위임하는 것이 일반적이다. 중간 계층에는 하나 이상의 중간 인증서(Intermediate Certificate)가 존재한다. 이 인증서는 루트 CA에 의해 서명받아 발급되며, 실제 최종 서버 인증서를 발급하는 역할을 한다. 이렇게 중간 계층을 두는 주된 목적은 보안을 강화하기 위함이다. 루트 인증서를 오프라인 상태로 안전하게 보관할 수 있으며, 중간 인증서가 유출되거나 취소되어도 루트 인증서 전체를 교체하지 않고 해당 중간 인증서만 무효화할 수 있다. 체인의 마지막에는 리프 인증서(Leaf Certificate) 또는 최종 인증서라고 불리는 서버 인증서가 있다. 이 인증서는 도메인 이름과 공개키 등을 포함하며, 중간 인증서에 의해 서명되어 발급된다. 웹 서버에 설치되어 클라이언트와의 통신에 직접 사용되는 것이 바로 이 인증서이다.
신뢰 검증 과정에서 클라이언트는 서버로부터 받은 리프 인증서와 함께 필요한 중간 인증서들을 받는다. 클라이언트는 내장된 루트 인증서 저장소를 이용해, 리프 인증서의 서명을 체인을 따라 거슬러 올라가 최종적으로 신뢰할 수 있는 루트 인증서까지 연결되는지 확인한다. 모든 인증서의 서명이 유효하고, 체인이 완전하게 연결될 때만 서버의 신원이 신뢰받은 것으로 판단된다. 따라서 웹 서버를 구성할 때는 리프 인증서뿐만 아니라 관련 중간 인증서들을 올바르게 함께 제공하여 체인을 완성하는 것이 필수적이다.
계층 | 인증서 명칭 | 발급 주체 | 주요 역할 및 특징 |
|---|---|---|---|
1 | 루트 인증서 (Root) | 루트 CA (자가 서명) | 신뢰의 근원. 브라우저/OS에 내장됨. 주로 오프라인 보관. |
2 | 중간 인증서 (Intermediate) | 루트 CA (또는 상위 중간 CA) | 리프 인증서 발급을 위임받음. 루트 인증서의 보안을 강화하는 계층. |
3 | 리프 인증서 (Leaf) | 중간 CA | 최종 서버에 설치되는 인증서. 도메인 이름, 공개키 등을 포함. |
X.509는 공개키 인프라(PKI)와 인증서의 형식, 구조를 정의하는 국제 표준이다. ITU-T(국제전기통신연합 전기통신표준화부문)에서 제정한 표준으로, 디지털 인증서의 핵심적인 틀을 제공한다. 이 표준은 인증서가 포함해야 할 정보 항목, 데이터 구조, 인코딩 규칙 등을 명시하여, 서로 다른 시스템 간에 상호 운용성을 보장한다.
X.509 인증서의 구조는 ASN.1(Abstract Syntax Notation One)이라는 추상 문법 표기법으로 정의된다. ASN.1은 데이터 구조를 플랫폼에 독립적인 방식으로 기술하는 언어이다. 이렇게 정의된 구조는 실제로 파일로 저장되거나 전송될 때 특정 인코딩 규칙을 통해 바이너리 또는 텍스트 형식으로 변환된다. 주요 인코딩 형식으로는 DER(Distinguished Encoding Rules)과 PEM(Privacy-Enhanced Mail)이 있다. DER은 바이너리 형식으로, 암호화 작업에 주로 사용되는 정규화된 단일 인코딩이다. PEM은 DER 형식을 Base64로 인코딩하고, "-----BEGIN CERTIFICATE-----"와 "-----END CERTIFICATE-----" 같은 헤더와 푸터로 감싼 텍스트 형식이다. PEM 형식은 텍스트 편집기로 읽을 수 있어 구성 파일에 넣기 편리하다.
형식 | 설명 | 주요 특징 | 파일 확장자 예시 |
|---|---|---|---|
Distinguished Encoding Rules. ASN.1 구조를 인코딩하는 규칙. | 바이너리 형식. 정규화된 단일 표현. 주로 Windows 시스템이나 Java 환경에서 사용. |
| |
Privacy-Enhanced Mail. DER 형식을 Base64로 인코딩한 텍스트 형식. | 텍스트 형식. 헤더/푸터 라인이 있음. 구성 파일에 삽입하기 쉬움. |
| |
PKCS#7 / P7B | 공개키 암호 표준 #7. 인증서 체인을 포함할 수 있는 컨테이너 형식. | 주로 Windows와 Java 키 저장소에서 인증서 체인 교환에 사용. |
|
PKCS#12 / PFX | 공개키 암호 표준 #12. 개인키와 인증서 체인을 함께 패키징하는 형식. | 암호로 보호됨. 주로 인증서 백업이나 특정 플랫폼으로 가져오기에 사용. |
|
인증서 내부에는 버전, 일련번호, 서명 알고리즘, 발급자, 유효기간, 주체(소유자), 주체의 공개키 정보, 확장 필드 등이 포함된다. 특히 확장 필드는 인증서의 용도(서버 인증, 클라이언트 인증, 코드 서명 등), 대체 주체 이름(SAN, Subject Alternative Name), CRL(인증서 폐기 목록) 배포 지점, OCSP(온라인 인증서 상태 프로토콜) 응답자 주소 등 중요한 추가 정보를 담는다. 이러한 표준화된 구조 덕분에 브라우저, 운영체제, 웹 서버 등 다양한 소프트웨어가 전 세계의 인증서를 일관되게 해석하고 검증할 수 있다.
SSL/TLS 프로토콜의 핵심은 데이터를 암호화하여 전송하는 것이며, 이를 위해 대칭키 암호화와 비대칭키 암호화가 조합되어 사용된다. 대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 방식으로, AES나 ChaCha20 같은 알고리즘이 이에 해당한다. 이 방식은 처리 속도가 매우 빠르지만, 통신을 시작하기 전에 안전하게 키를 교환해야 하는 문제가 있다. 반면 비대칭키 암호화는 공개키와 개인키라는 한 쌍의 키를 사용한다. 공개키로 암호화한 데이터는 오직 짝이 되는 개인키로만 복호화할 수 있으며, RSA와 ECDSA가 대표적인 알고리즘이다. 이 방식은 키 교환 문제를 해결하고 디지털 서명을 가능하게 하지만, 계산이 복잡하여 속도가 느리다는 단점이 있다.
실제 SSL/TLS 연결에서는 두 방식을 혼용한다. 먼저 비대칭키 암호화를 통해 안전하게 대칭키를 교환한 후, 이후의 모든 데이터 통신은 빠른 대칭키 암호화로 진행한다. 이 초기 키 교환 과정을 담당하는 메커니즘을 키 교환 알고리즘이라고 한다. 역사적으로 가장 널리 사용된 키 교환 방식은 RSA를 이용한 것이었다. 클라이언트가 생성한 대칭키(세션 키)를 서버의 공개키로 암호화하여 전송하면, 서버만이 자신의 개인키로 이를 복호화하여 키를 얻을 수 있었다.
보다 현대적인 키 교환 방식으로는 디피-헬먼 키 교환(Diffie-Hellman Key Exchange)이 있다. 이 방식은 통신 당사자 각자가 공개값과 비밀값을 조합하여 계산을 수행하고, 공개값만을 교환함으로써 제3자는 알 수 없는 공유 비밀키를 생성할 수 있게 한다. 이 원리는 이산 로그 문제의 계산적 난해함에 기반한다. 디피-헬먼의 변종인 ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)는 타원곡선 암호(ECC)를 적용하여 더 짧은 키 길이로 동일한 수준의 보안을 제공하며, 매 세션마다 일회성 키를 사용하는 일회용 디피-헬먼(DHE) 특성을 결합했다. 이 '일회용' 특성은 향후 개인키가 유출되더라도 과거의 통신 세션을 복호화할 수 없는 전방향 비밀성(Forward Secrecy)을 보장하는 데 결정적이다.
알고리즘 유형 | 대표 예시 | 주요 용도 | 특징 |
|---|---|---|---|
비대칭키 (공개키) | RSA, ECDSA | 키 교환, 디지털 서명 | 키 쌍(공개키/개인키) 사용. 속도 느림. |
대칭키 | AES-256, ChaCha20 | 세션 데이터 암호화 | 단일 키 사용. 속도 매우 빠름. |
키 교환 | RSA, ECDHE, DHE | 세션 키 공유 안전화 | 대칭키를 안전하게 교환하는 메커니즘. |
결론적으로, TLS 핸드셰이크는 RSA나 ECDHE 같은 키 교환 알고리즘을 통해 세션 키를 협상하고, 서버의 신원은 RSA 또는 ECDSA 서명으로 검증한다. 협상이 완료되면, 실제 데이터는 AES 등의 대칭키 알고리즘으로 암호화되어 전송된다. 최신 프로토콜인 TLS 1.3에서는 보안과 성능을 고려하여 대부분의 키 교환이 ECDHE 방식을 사용하도록 강제하며, RSA를 통한 키 교환은 제거되었다.
대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 방식이다. AES와 ChaCha20이 대표적인 알고리즘이다. 이 방식은 계산 부하가 적어 대량의 데이터를 빠르게 암호화하는 데 적합하지만, 통신 당사자 간에 사전에 키를 안전하게 공유해야 하는 '키 배분 문제'가 존재한다.
반면 비대칭키 암호화는 공개키와 개인키라는 한 쌍의 키를 사용한다. 공개키로 암호화한 데이터는 반드시 그에 대응하는 개인키로만 복호화할 수 있다. RSA와 타원곡선 암호화(ECDSA)가 이에 속한다. 키를 사전에 공유할 필요가 없어 안전한 키 교환을 가능하게 하지만, 계산이 복잡하여 대칭키 방식에 비해 속도가 느리다는 단점이 있다.
SSL/TLS 프로토콜은 이 두 방식을 조합하여 효율성과 보안성을 모두 확보한다. 핸드셰이크 단계에서는 비대칭키 암호화를 사용하여 상대방의 신원을 확인하고, 이후 실제 데이터 통신에 사용할 세션 키(대칭키)를 안전하게 협상한다. 데이터 전송 단계에서는 협상된 세션 키를 이용한 대칭키 암호화로 효율적인 통신을 수행한다.
특성 | 대칭키 암호화 | 비대칭키 암호화 |
|---|---|---|
키 사용 | 동일한 키로 암호화/복호화 | 공개키와 개인키 쌍 사용 |
속도 | 빠름 | 상대적으로 느림 |
주요 용도 | 대량 데이터 암호화 | 키 교환, 디지털 서명 |
대표 알고리즘 | AES, ChaCha20 | RSA, ECDSA |
키 관리 | 키 배분 문제 존재 | 공개키는 자유롭게 배포 가능 |
RSA는 공개 키 암호 시스템의 대표적인 알고리즘으로, 큰 소수의 곱셈은 쉽지만 그 인수분해는 어렵다는 수학적 원리에 기반한다. 이 알고리즘은 SSL/TLS 핸드셰이크에서 서버 인증과 키 교환을 모두 처리하는 데 오랫동안 사용되었다. 클라이언트는 서버의 공개 키로 암호화된 프리마스터 시크릿을 전송하고, 서버는 자신의 개인 키로 이를 복호화하여 세션 키를 도출한다. 그러나 RSA 키 길이가 증가함에 따라 계산 부하가 커지고, 향후 양자 컴퓨터의 위협에 취약할 수 있다는 점이 지적된다.
ECDSA는 타원곡선 암호를 기반으로 한 디지털 서명 알고리즘이다. RSA에 비해 훨씬 짧은 키 길이로 동등한 수준의 보안 강도를 제공한다는 장점이 있다[5]. 이로 인해 계산 자원이 제한된 환경에서 성능과 효율성이 뛰어나다. TLS에서 ECDSA는 주로 서버 인증을 위한 인증서 서명 알고리즘으로 사용된다. 서버는 ECDSA 개인 키로 핸드셰이크 메시지에 서명하고, 클라이언트는 해당 공개 키를 통해 서명의 진위를 검증한다.
Diffie-Hellman 키 교환은 완전히 다른 접근법을 제공한다. 이 방법은 두 당사자가 비밀리에 정보를 교환하여 공유 비밀 키를 생성할 수 있게 하며, 이 과정에서 생성된 키는 직접 전송되지 않는다. 전방향 비밀성을 보장하는 데 핵심적인 역할을 한다[6]. 전통적인 Diffie-Hellman은 큰 소수 모듈러 연산을 사용하지만, 타원곡선 디피-헬만은 ECDSA와 같은 타원곡선 이론을 적용하여 더 높은 효율성을 제공한다. 현대 TLS 1.3에서는 RSA를 이용한 키 교환이 제거되고, ECDHE와 같은 에피머럴 디피-헬만 방식이 표준이 되었다.
알고리즘 | 주요 용도 | 보안 강점 | 주요 고려사항 |
|---|---|---|---|
인증, 키 교환 | 검증된 안전성, 널리 호환됨 | 긴 키 길이 필요, 계산 부하 큼, 전방향 비밀성 제공 안 함 | |
디지털 서명 (인증) | 짧은 키 길이, 높은 효율성 | 특정 타원곡선의 안전성에 의존 | |
Diffie-Hellman (DH/ECDHE) | 키 교환 | 전방향 비밀성 제공 | 순수 DH는 인증 기능 없음, 인증서와 결합 필요 |
TLS 1.2와 TLS 1.3은 보안과 성능 측면에서 중요한 차이를 보인다. TLS 1.3은 설계부터 보안을 강화하여 여러 취약점을 제거했다. 가장 큰 변화는 핸드셰이크 과정의 단순화와 속도 향상이다. TLS 1.2에서는 지원 가능한 암호화 방식(암호 스위트)을 협상하기 위해 여러 번의 왕복이 필요했지만, TLS 1.3에서는 클라이언트가 첫 메시지에서 사용할 키 교환 매개변수를 이미 제안한다. 이를 통해 핸드셰이크를 1-RTT(한 번의 왕복)로 완료할 수 있으며, 세션 재개를 사용하면 0-RTT로 연결을 재개할 수 있어 지연 시간이 크게 줄어든다.
암호화 방식 측면에서 TLS 1.3은 안전하지 않다고 판단된 오래된 알고리즘을 대거 제거했다. RSA 키 교환은 제거되어 모든 키 교환이 에피머럴 방식으로 이루어진다. 또한 정적 RSA와 디피-헬먼을 통한 암호화는 더 이상 사용되지 않는다. 허용되는 대칭키 암호화 방식도 AES와 ChaCha20 등 강력한 알고리즘으로 제한되며, SHA-256 또는 SHA-384를 해시 함수로 사용해야 한다.
특성 | TLS 1.2 | TLS 1.3 |
|---|---|---|
핸드셰이크 기본 RTT | 2-RTT | 1-RTT (0-RTT 가능) |
지원 암호 스위트 | 수십 가지 (일부 취약) | 5개 미만의 강력한 스위트 |
키 교환 방식 | RSA, (EC)DH 지원 | (EC)DH만 지원 (RSA 키 교환 제거) |
암호화 시작 시점 | 핸드셰이크 완료 후 | 핸드셰이크 초기부터 (암호화된 확장) |
과거 프로토콜 버전과 구현체에서는 여러 치명적인 취약점이 발견되었다. SSL 3.0의 POODLE 공격은 패딩 오라클을 이용해 암호화된 데이터를 해독할 수 있었다. 하트블리드 버그는 OpenSSL 라이브러리의 하트비트 확장 구현 오류로, 서버의 메모리 내용을 유출시켰다. 이러한 취약점들은 프로토콜 자체의 결함(SSL 3.0)이나 구현상의 결함(OpenSSL)으로 인해 발생했으며, 대응으로 취약한 프로토콜 사용 중지와 소프트웨어의 신속한 패치가 필수적이었다. TLS 1.3은 이러한 과거의 취약점을 교훈 삼아 설계되어, 프로토콜 복잡성을 줄이고 암호화 원칙을 강화함으로써 공격 면적을 최소화한다.
TLS 1.2는 2008년에 표준화되어 10년 이상 인터넷 보안의 핵심 프로토콜로 자리 잡았다. 그러나 시간이 지남에 따라 설계상의 복잡성과 새로운 공격 기법에 대한 대응 필요성이 제기되었다. 이를 해결하고 현대적인 보안 요구사항을 반영하기 위해 2018년에 TLS 1.3이 표준으로 발표되었다. TLS 1.3은 이전 버전과의 호환성을 일부 포기하는 대신, 보안을 강화하고 성능을 획기적으로 개선하는 데 초점을 맞췄다.
가장 두드러진 변화는 핸드셰이크 과정의 단순화와 속도 향상이다. TLS 1.2에서는 지원 가능한 암호화 스위트와 키 교환 방법을 협상하기 위해 여러 번의 왕복(Round-Trip)이 필요했다. TLS 1.3은 핸드셰이크를 최대 한 번의 왕복(1-RTT)으로 줄였으며, 사전 공유 키(PSK)를 사용하는 경우에는 왕복 없이(0-RTT) 연결을 재개할 수 있다. 이는 연결 지연 시간을 크게 단축시킨다. 또한, RSA와 같은 정적 키 교환 방식을 제거하고 Diffie-Hellman Ephemeral (DHE)이나 Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)과 같은 완전 순방향 비밀성(Perfect Forward Secrecy)을 제공하는 방식만을 필수로 지원한다.
보안 측면에서는 취약한 암호화 알고리즘과 기능을 대거 제거했다. 다음 표는 주요 제거 항목을 보여준다.
제거된 암호화 스위트/기능 | 제거 이유 |
|---|---|
RSA 키 교환 | 순방향 비밀성 부재 |
CBC 모드 암호화 | 패딩 오라클 공격(예: POODLE) 취약성 |
RC4 스트림 암호 | 취약한 알고리즘 |
SHA-1 해시 함수 | 충돌 공격 취약성 |
데이터 압축(Compression) | CRIME 공격 등 정보 유출 취약성 |
재협상(Renegotiation) | 특정 공격 경로 |
또한, 핸드셰이크 과정에서 교환되는 메시지가 모두 암호화되어, 서버 인증서와 같은 민감한 정보가 평문으로 노출되는 것을 방지한다. 이는 패시브 모니터링을 통한 사용자 추적을 어렵게 만든다. TLS 1.3은 설계 자체가 더 간결하고 강력하여, 과거 TLS 1.2에서 발생했던 Heartbleed, POODLE 등과 같은 프로토콜 수준의 취약점 발생 가능성을 현저히 낮춘다.
TLS와 그 전신인 SSL 프로토콜은 역사적으로 여러 심각한 취약점이 발견되어 왔으며, 이는 프로토콜의 지속적인 진화와 보안 강화의 주요 동력이 되었다.
대표적인 취약점으로는 POODLE 공격과 Heartbleed 버그가 있다. POODLE(Padding Oracle On Downgraded Legacy Encryption)은 2014년 공개된 공격으로, SSL 3.0 프로토콜의 설계 결함을 악용한다. 공격자는 클라이언트와 서버 간 통신을 SSL 3.0으로 강제로 다운그레이드시킨 후, 블록 암호의 패딩 방식을 오라클로 이용하여 평문을 한 바이트씩 추출할 수 있다. 이에 대한 근본적인 대응은 서버와 클라이언트 양측에서 오래된 SSL 3.0 프로토콜 지원을 완전히 비활성화하는 것이다. Heartbleed 버그는 동일한 해에 발견된 OpenSSL 암호화 라이브러리의 심각한 구현상 결함이다. 이는 TLS/SSL의 하트비트 확장 기능을 처리하는 코드에 존재하는 버퍼 오버리드 취약점으로, 공격자가 서버의 메모리 내용을 최대 64KB씩 읽어들일 수 있게 하여 개인 키, 세션 쿠키, 사용자 비밀번호 등 민감한 정보가 유출될 위험이 있었다. 대응책은 영향을 받는 OpenSSL 버전(1.0.1 ~ 1.0.1f)을 즉시 최신 패치 버전으로 업그레이드하고, 손상 가능성이 있는 인증서를 폐기하고 재발급하는 것이었다.
이 외에도 주요 취약점과 대응 조치는 다음과 같이 정리할 수 있다.
취약점 명 | 공개 연도 | 영향 대상 | 설명 | 주요 대응 조치 |
|---|---|---|---|---|
2011 | TLS 1.0 및 이전 | CBC 모드에서의 초기화 벡터 예측 공격 | TLS 1.1/1.2로 업그레이드, RC4 사용 (후속 취약점으로 권장되지 않음) | |
2012 | TLS 압축 사용 시 | 데이터 압축을 이용한 정보 유출 공격 | TLS 계층에서 데이터 압축 기능 비활성화 | |
2013 | HTTP 응답 압축 사용 시 | HTTP 수준 압축을 이용한 CRIME 유사 공격 | HTTP 응답 압축 비활성화 또는 CSRF 토큰 마스킹 | |
2015 | 수출용 암호화 제한 지원 서버 | 수출용 약한 RSA 키를 강제로 사용하게 하는 공격 | 서버측에서 수출 등급 암호 스위트 지원 제거 | |
2015 | Diffie-Hellman 키 교환 사용 시 | 512비트 수출 등급 DH 그룹을 이용한 공격 | 1024비트 이상의 강한 DH 그룹 사용, 최신 프로토콜 지원 |
이러한 취약점들의 지속적인 발견은 TLS 1.3 프로토콜 설계에 직접적인 영향을 미쳤다. TLS 1.3에서는 보안에 취약한 것으로 알려진 기능들(압축, 정적 RSA 키 교환, 수출 등급 암호 스위트, RC4, SHA-1 등)이 대거 제거되었으며, 핸드셰이크 과정이 더 간소화되고 안전해졌다. 현대적인 보안 모범 사례는 가능한 한 최신 버전의 TLS 1.3을 사용하고, 오래된 프로토콜 버전과 취약한 암호 스위트를 비활성화하며, 관련 소프트웨어와 라이브러리를 정기적으로 최신 상태로 유지하는 것이다.
인증서 발급은 신뢰할 수 있는 제3자인 공인 인증기관에 의해 이루어진다. 인증서 발급을 요청하는 개체(예: 웹 서버 운영자)는 먼저 비밀키와 공개키 쌍을 생성하고, 공개키와 서버 정보(도메인 이름, 조직 정보 등)를 포함한 인증서 서명 요청을 생성한다. 이 CSR을 선택한 CA에 제출하면, CA는 요청자의 신원과 도메인 소유권을 검증한 후 자신의 개인키로 CSR에 서명하여 최종 SSL-TLS 인증서를 발급한다.
CA의 신뢰성은 브라우저와 운영체제에 내장된 루트 인증서 저장소에 의해 보장된다. 주요 CA로는 DigiCert, Sectigo, GlobalSign 등이 있다. 인증서는 일반적으로 1년 또는 90일(자동화된 인증서의 경우)의 유효 기간을 가지며, 만료 전에 갱신 과정을 거쳐야 지속적인 서비스가 가능하다.
2015년 출범한 Let's Encrypt는 무료로 도메인 검증 인증서를 발급해주는 비영리 CA이다. ACME 프로토콜을 사용하여 인증서 발급, 갱신, 해지 과정을 완전히 자동화했다. 이를 통해 소규모 웹사이트나 개발자도 쉽게 HTTPS를 적용할 수 있게 되었으며, 웹 전반의 보안 수준 향상에 기여했다. Let's Encrypt 인증서의 유효 기간은 90일로 설정되어 자동 갱신이 권장된다.
인증서 관리는 발급 이후의 중요한 작업이다. 주요 관리 항목은 다음과 같다.
관리 항목 | 설명 |
|---|---|
갱신 | 유효 기간 만료 전에 새로운 인증서로 교체하는 과정이다. 자동화 도구(예: Certbot)를 사용하는 것이 일반적이다. |
해지 | 인증서가 만료 전에 무효화되어야 할 때(예: 개인키 유출) 수행한다. 인증서 해지 목록이나 온라인 인증서 상태 프로토콜을 통해 상태를 공개한다. |
모니터링 | 인증서의 만료일, 호스트명 일치 여부, 해지 상태 등을 지속적으로 점검한다. |
키 교체 | 주기적으로 새로운 키 쌍을 생성하고 인증서를 재발급받아 보안 강도를 유지한다. |
공인 인증기관은 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제3자 기관이다. 이 기관들은 공개 키 기반 구조의 핵심 요소로, 웹사이트나 서비스의 신원을 검증하고 그에 대한 공개 키의 소유권을 보증하는 역할을 한다. 브라우저와 운영체제는 주요 CA의 루트 인증서 목록을 미리 내장하고 있어, 해당 CA가 서명한 인증서를 자동으로 신뢰한다. CA는 신청자의 도메인 소유권, 조직 정보, 법적 실체 등을 검증한 후 인증서를 발급한다.
인증서 서명 요청은 인증서 발급을 위해 CA에 제출하는 데이터 구조이다. CSR은 주로 PEM이나 DER 형식으로 생성되며, 다음의 핵심 정보를 포함한다.
구성 요소 | 설명 |
|---|---|
공개 키 | |
주체 정보 | 인증서에 들어갈 일반 이름(도메인), 조직, 지역 등의 정보를 담는다. |
서명 | CSR 자체의 무결성을 보장하기 위해, 포함된 정보를 개인 키로 서명한 값이다. |
CSR 생성 과정은 서버의 개인 키와 공개 키 쌍을 생성하는 것으로 시작한다. 이후 openssl 등의 도구를 사용해 공개 키와 주체 정보를 묶고, 개인 키로 이 묶음에 서명하여 CSR 파일을 만든다. 이 CSR 파일을 CA에 제출하면, CA는 검증 절차를 거친 후 CSR에 담긴 정보와 유효기간 등을 결합하여 최종 X.509 인증서를 생성하고 서명한다. 발급받은 인증서는 서버에 설치되어 TLS 핸드셰이크 과정에서 사용된다.
CA의 신뢰 체계는 엄격한 운영 규정과 정기적인 감사를 통해 유지된다. 만약 CA의 개인 키가 유출되거나 잘못된 인증서를 발급하는 등 신뢰를 훼손하는 사건이 발생하면, 해당 CA의 루트 인증서는 주요 소프트웨어 벤더에 의해 신뢰 목록에서 제거될 수 있다[7]. 이로 인해 해당 CA가 발급한 모든 인증서의 신뢰성이 상실된다.
Let's Encrypt는 2016년 출범한 비영리 인증 기관이다. 이 기관의 주요 목표는 무료로 도메인 유효성 인증서를 자동화된 방식으로 제공하여 월드 와이드 웹 전반의 암호화 통신 보급을 촉진하는 것이다. 기존 상용 공인 인증기관의 인증서 발급 과정이 복잡하고 비용이 발생하는 점을 해결하기 위해 등장했다. Let's Encrypt는 ISRG가 운영하며, ACME 프로토콜을 통해 인증서 발급과 갱신을 완전히 자동화한다.
인증서 발급 및 갱신 과정은 ACME 프로토콜을 구현한 클라이언트 도구(예: Certbot)를 사용하여 관리한다. 기본적인 흐름은 다음과 같다.
1. 클라이언트는 서버에 인증서 서명 요청을 생성하고 Let's Encrypt에 계정을 등록한다.
2. Let's Encrypt는 도메인 소유권을 확인하기 위해 하나 이상의 챌린지를 제시한다. 가장 일반적인 것은 HTTP-01 챌린지로, 클라이언트가 특정 토큰 값을 웹 서버의 정해진 경로에 배치하도록 요구한다.
3. 클라이언트가 챌린지를 통과하면 Let's Encrypt는 인증서를 발급하고, 클라이언트는 이를 웹 서버에 설치한다.
4. 발급된 인증서의 유효 기간은 90일로, 만료되기 전에 자동으로 같은 과정을 반복하여 갱신한다.
이 자동화 접근 방식은 몇 가지 중요한 이점을 제공한다. 첫째, 인증서 만료로 인한 서비스 중단 위험을 크게 줄인다. 둘째, 관리 부담을 최소화하여 소규모 사이트나 개발자도 쉽게 TLS를 도입할 수 있게 한다. Let's Encrypt가 발급하는 인증서는 DV 인증서에 해당하며, 널리 호환되는 ISRG Root X1 루트 인증서에 연결되어 있다.
항목 | 설명 |
|---|---|
발급 기관 | ISRG(Internet Security Research Group) |
인증서 종류 | |
유효 기간 | 90일 |
핵심 프로토콜 | |
대표 클라이언트 | |
루트 인증서 |
자동 갱신은 일반적으로 cron 작업이나 시스템 타이머를 통해 설정된다. Certbot은 certbot renew 명령어를 주기적으로 실행하여 만료가 임박한 인증서를 갱신하고, 필요한 경우 웹 서버를 재시작하여 새 인증서를 적용한다. 이 구조는 데브옵스 관행과 잘 통합되어 지속적인 보안 유지 관리가 가능하게 한다.
웹 서버에 SSL/TLS를 적용하기 위해서는 서버 소프트웨어에 맞는 설정이 필요하다. 아파치 HTTP 서버에서는 mod_ssl 모듈을 활성화하고, 인증서 파일과 개인 키 파일의 경로를 SSLCertificateFile, SSLCertificateKeyFile 지시어로 지정한다. Nginx에서는 ssl_certificate와 ssl_certificateKey 지시어를 사용하여 비슷한 설정을 한다. 또한, 보안 수준을 높이기 위해 오래된 프로토콜 버전(SSL 2.0, 3.0, TLS 1.0)을 비활성화하고 강력한 암호 스위트만 사용하도록 구성하는 것이 일반적이다.
TLS 핸드셰이크는 네트워크 지연과 서버 부하를 유발할 수 있다. 이를 완화하기 위한 주요 성능 최적화 기법으로 세션 재개(Session Resumption)가 있다. 이는 한 번 연결을 설정한 클라이언트와 서버가 나중에 다시 연결할 때 이전 세션 정보를 재사용하여 핸드셰이크 과정을 생략하는 기술이다. TLS 1.2에서는 세션 아이디(Session ID)나 세션 티켓(Session Ticket) 방식을, TLS 1.3에서는 보다 효율적인 PSK(Pre-Shared Key) 모드로 구현된다.
인증서 상태 확인 과정의 지연을 줄이기 위해 OCSP 스테이플링(OCSP Stapling)이 널리 사용된다. 일반적으로 클라이언트는 인증서가 폐기되지 않았는지 확인하기 위해 인증 기관(CA)의 OCSP 서버에 추가 요청을 보내야 한다. OCSP 스테이플링을 설정하면 웹 서버가 주기적으로 CA로부터 OCSP 응답을 받아 캐시하고, TLS 핸드셰이크 시 클라이언트에게 이 응답을 함께 제공한다. 이로 인클라이언트의 별도 확인 요청이 불필요해져 연결 설정 시간이 단축되고, 클라이언트의 프라이버시가 향상된다[8].
최적화 기법 | 설명 | 주요 이점 |
|---|---|---|
이전 핸드셰이크 세션 정보를 재사용 | 핸드셰이크 라운드트립 감소, 서버 CPU 부하 절감 | |
서버가 인증서 상태 확인 응답(OCSP)을 클라이언트에게 직접 제공 | 클라이언트의 추가 조회 제거, 연결 설정 가속화 및 프라이버시 보호 | |
False Start / 0-RTT | 핸드셰이크 완료 전에 애플리케이션 데이터 전송 시작 | 사용자 체감 지연 시간 감소 (주의: 0-RTT는 재전송 공격 위험 존재) |
웹 서버에서 SSL/TLS를 적용하려면 서버 소프트웨어별로 설정 파일을 구성해야 한다. Apache HTTP Server에서는 일반적으로 httpd.conf 또는 가상 호스트 설정 파일 내 SSLEngine on 지시어를 사용하여 SSL/TLS를 활성화한다. 주요 설정 항목으로는 SSL 인증서 파일(SSLCertificateFile), 개인 키 파일(SSLCertificateKeyFile), 그리고 중간 인증서 체인 파일(SSLCertificateChainFile 또는 SSLCACertificateFile)의 경로를 지정하는 것이 포함된다. Nginx에서는 서버 블록(server) 설정 내에서 listen 443 ssl; 지시어로 SSL/TLS 연결을 수신하고, ssl_certificate 지시어에 인증서 파일(일반적으로 중간 인증서가 포함된 파일) 경로를, ssl_certificate_key 지시어에 개인 키 파일 경로를 명시한다.
보안 강화를 위해 특정 암호화 알고리즘과 프로토콜 버전을 명시적으로 지정하는 것이 좋다. 예를 들어, 오래된 SSL 버전을 비활성화하고 강력한 암호 스위트만을 허용하도록 구성할 수 있다. Apache에서는 SSLProtocol과 SSLCipherSuite 지시어를, Nginx에서는 ssl_protocols와 ssl_ciphers 지시어를 사용한다. HTTP Strict Transport Security (HSTS) 헤더를 추가하여 브라우저가 항상 HTTPS를 사용하도록 강제하는 설정도 보안을 크게 향상시킨다.
설정 항목 | Apache 예시 지시어 | Nginx 예시 지시어 |
|---|---|---|
SSL/TLS 활성화 |
|
|
인증서 파일 |
|
|
개인 키 파일 |
|
|
허용 프로토콜 |
|
|
암호 스위트 |
|
|
HSTS 헤더 |
|
|
설정 적용 후에는 구문 오류를 확인하기 위해 apachectl configtest (Apache) 또는 nginx -t (Nginx) 명령어로 테스트를 수행해야 한다. 이후 웹 서버를 재시작하면 새로운 SSL/TLS 설정이 적용된다. 올바른 인증서 체인 구성과 강력한 보안 설정은 사용자 통신의 기밀성과 무결성을 보장하는 핵심 단계이다.
웹 서버의 SSL/TLS 성능을 최적화하기 위해 세션 재개(Session Resumption)와 OCSP 스테이플링(OCSP Stapling) 기법이 널리 사용된다. 이들은 핸드셰이크 과정의 오버헤드를 줄여 지연 시간을 단축하고, 사용자 경험을 개선하는 데 목적이 있다.
세션 재개는 한 번 완료된 핸드셰이크 정보를 재사용하여 후속 연결을 빠르게 설정하는 메커니즘이다. 주로 두 가지 방식으로 구현된다. 첫째, 세션 ID(Session ID) 방식은 서버가 생성한 세션 식별자를 클라이언트와 공유하여 저장해두고, 재연결 시 이를 제시하는 방법이다. 둘째, 세션 티켓(Session Ticket) 방식은 서버가 암호화된 상태 정보(티켓)를 클라이언트에게 발급하고, 클라이언트가 이 티켓을 재연결 시 제출하는 방법이다. TLS 1.3에서는 이 개념이 사전 공유 키(PSK, Pre-Shared Key)로 진화하여 보안과 효율성을 동시에 높였다.
OCSP 스테이플링은 인증서 폐기 상태 확인 과정의 지연과 프라이버시 문제를 해결한다. 일반적으로 클라이언트는 인증서의 유효성을 확인하기 위해 발급 기관(CA)의 온라인 인증서 상태 프로토콜(OCSP) 서버에 별도로 문의해야 한다. 이는 추가적인 외부 연결로 인한 지연과 사용자의 탐색 이력이 CA에 노출될 수 있는 문제를 야기한다. OCSP 스테이플링은 웹 서버가 주기적으로 CA의 OCSP 응답(서명된 인증서 상태 확인서)을 받아 저장해두고, TLS 핸드셰이크 시 클라이언트에게 이 응답을 함께 제공('스테이플'함)하는 방식이다. 이를 통해 클라이언트의 별도 확인 요청이 불필요해져 연결 설정 시간이 단축되고, 프라이버시가 보호된다.
이러한 최적화 기법의 적용 효과는 다음과 같이 요약할 수 있다.
최적화 기법 | 주요 목적 | 동작 방식 | 이점 |
|---|---|---|---|
세션 재개 | 핸드셰이크 오버헤드 감소 | 세션 ID 또는 세션 티켓을 이용한 이전 세션 정보 재사용 | 후속 연결 설정 지연 감소, 서버 부하 경감 |
OCSP 스테이플링 | 인증서 상태 확인 지연 및 프라이버시 문제 해결 | 서버가 CA로부터 미리 받은 OCSP 응답을 핸드셰이크 시 클라이언트에 제공 | 클라이언트의 외부 확인 요청 제거, 연결 속도 향상, 사용자 프라이버시 보호 |
이 기법들은 Apache HTTP Server나 Nginx와 같은 주요 웹 서버 소프트웨어에서 설정을 통해 활성화할 수 있다. 적절히 구성하면 보안 수준을 유지하면서도 HTTPS 연결의 성능을 현저히 개선할 수 있다.