HTTPS 프로토콜 원리

HTTP는 클라이언트와 서버 간에 데이터를 주고받기 위한 기본적인 프로토콜이다. 그러나 HTTP는 데이터를 평문으로 전송하기 때문에, 네트워크 상에서 패킷을 가로채면 내용이 쉽게 노출될 수 있다. 또한 데이터가 전송 중에 변조되었는지 확인하기 어렵다는 단점이 있다.

이러한 보안 취약점을 해결하기 위해 등장한 것이 HTTPS이다. HTTPS는 HTTP에 SSL 또는 그 후속 프로토콜인 TLS를 결합한 프로토콜이다. 가장 근본적인 차이는 통신 경로를 암호화한다는 점이다. HTTPS를 사용하면 모든 HTTP 요청과 응답이 암호화되어 전송되므로, 제3자가 통신 내용을 엿보거나 변조하는 것을 방지할 수 있다.

두 프로토콜은 사용하는 기본 포트 번호에서도 차이를 보인다. HTTP는 일반적으로 80번 포트를 사용하는 반면, HTTPS는 443번 포트를 사용한다. 이는 서버가 어떤 프로토콜로 통신을 처리할지 구분하는 기준이 된다.

또 다른 핵심 차이는 인증 기능의 유무이다. HTTPS는 서버의 신원을 확인하기 위해 디지털 인증서를 사용한다. 클라이언트는 서버로부터 받은 인증서를 검증하여, 접속하려는 사이트가 진짜 운영자의 서버인지 확인할 수 있다. 이 과정을 통해 피싱 사이트와 같은 위장된 서버로의 접속을 방지할 수 있다. 반면, HTTP는 이러한 서버 인증 메커니즘을 제공하지 않는다.

SSL/TLS 프로토콜은 HTTPS의 핵심 구성 요소로, HTTP 프로토콜에 보안 계층을 추가하는 역할을 담당한다. 이 프로토콜은 클라이언트와 서버 간의 통신을 암호화하고, 데이터 무결성을 보호하며, 서버의 신원을 인증하는 기능을 제공한다. SSL(Secure Sockets Layer)의 후속 버전인 TLS(Transport Layer Security)는 현재 널리 사용되며, 두 용어는 종종 혼용된다.

SSL/TLS는 OSI 모델의 전송 계층과 응용 계층 사이에서 동작한다. 이는 응용 계층 프로토콜(예: HTTP, SMTP, FTP)과 독립적으로 보안 서비스를 제공할 수 있음을 의미한다. 주요 역할은 다음과 같다.

프로토콜은 크게 두 단계로 진행된다. 첫 번째는 SSL/TLS 핸드셰이크 과정으로, 암호화 알고리즘 협상, 서버 인증, 세션 키 교환을 수행한다. 이 과정에서 서버는 디지털 인증서를 클라이언트에 제공하여 자신의 신원을 증명한다. 두 번째 단계는 실제 응용 데이터를 협상된 암호 키로 암호화하여 안전하게 전송하는 단계이다.

SSL/TLS는 다양한 암호화 기술을 조합하여 사용한다. 비대칭키 암호화는 핸드셰이크 초기에 신원 확인과 키 교환을 위해 사용된다. 이후 실제 데이터 암호화에는 효율성이 높은 대칭키 암호화가 사용된다. 또한 해시 함수를 이용한 메시지 인증 코드(MAC)는 데이터 무결성을 검증하는 데 활용된다. 이러한 다층적 접근 방식이 안전한 통신 채널을 구축하는 기반이 된다.

대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 암호화 방식이다. 이 키는 비밀키라고도 불리며, 송신자와 수신자가 사전에 공유해야 한다. 송신자는 이 키를 사용하여 평문을 암호문으로 변환하고, 수신자는 동일한 키를 사용하여 암호문을 원래의 평문으로 되돌린다.

대칭키 암호화 알고리즘은 크게 스트림 암호와 블록 암호로 나뉜다. 스트림 암호는 데이터를 비트나 바이트 단위로 연속적으로 암호화하는 반면, 블록 암호는 고정된 크기의 데이터 블록 단위로 암호화를 수행한다. HTTPS와 SSL/TLS에서 널리 사용되는 AES(Advanced Encryption Standard)는 대표적인 블록 암호 알고리즘이다.

대칭키 암호화의 주요 장점은 처리 속도가 매우 빠르다는 점이다. 비대칭키 암호화에 비해 계산 부하가 적어 대량의 데이터를 효율적으로 암호화할 수 있다. 따라서 SSL/TLS 핸드셰이크 과정에서 비대칭키 암호화를 통해 안전하게 교환한 후, 실제 데이터 통신 단계에서는 이 키를 기반으로 한 대칭키 암호화를 사용한다.

그러나 대칭키 암호화는 키 배분 문제라는 근본적인 단점을 가진다. 통신 당사자들이 사전에 비밀키를 안전하게 공유해야 하며, 키가 노출되면 모든 통신 내용이 위험에 빠진다. 또한 많은 사용자와 통신할 경우, 각 통신 쌍마다 별도의 키를 관리해야 하므로 키 관리가 복잡해진다.

비대칭키 암호화는 공개키 암호화라고도 불리며, 암호화와 복호화에 서로 다른 두 개의 키 쌍을 사용하는 방식을 말한다. 이 두 키는 수학적으로 밀접하게 연관되어 있지만, 하나로부터 다른 하나를 추론하는 것은 현실적으로 불가능하도록 설계되었다. 한 쌍의 키는 공개적으로 배포되는 공개키이고, 다른 하나는 소유자만이 비밀로 보관하는 개인키이다.

공개키로 암호화된 데이터는 오직 그에 대응하는 개인키로만 복호화할 수 있다. 반대로, 개인키로 서명(암호화)한 데이터는 대응하는 공개키로 검증(복호화)하여 서명자의 신원을 확인할 수 있다. 이 방식의 핵심 장점은 키 배포 문제를 해결한다는 점이다. 통신 상대방에게 비밀키를 안전하게 전달할 필요 없이, 공개키는 누구에게나 공개해도 안전하다.

HTTPS의 핵심 프로토콜인 SSL/TLS에서 비대칭키 암호화는 핵심적인 두 가지 역할을 수행한다. 첫째, SSL/TLS 핸드셰이크 과정 초기에 서버의 신원을 디지털 인증서를 통해 인증하는 데 사용된다. 둘째, 이후 실제 데이터 암호화에 사용될 대칭키를 안전하게 교환하는 데 활용된다. 대칭키 암호화에 비해 연산 부하가 크기 때문에, 비대칭키 암호화는 일반적으로 대량의 데이터 암호화가 아닌 초기 키 교환과 인증 단계에만 사용된다.

주요 비대칭키 암호화 알고리즘으로는 RSA, 디피-헬먼 키 교환(DH), 타원곡선 암호(ECC) 등이 있다. 특히 타원곡선 암호는 동일한 수준의 보안을 제공하면서 더 짧은 키 길이와 더 빠른 연산 속도를 제공하여 최신 TLS 1.3 프로토콜에서 선호되는 방식이다.

해시 함수는 임의의 길이를 가진 데이터를 고정된 길이의 해시 값으로 변환하는 단방향 함수이다. 이 변환 과정은 매우 빠르게 수행되지만, 해시 값으로부터 원본 데이터를 역산하는 것은 계산상 불가능에 가깝다. SSL/TLS 프로토콜에서 해시 함수는 주로 데이터의 무결성을 보장하고 디지털 서명을 생성하는 데 핵심적인 역할을 한다.

해시 함수는 몇 가지 중요한 암호학적 성질을 만족해야 한다. 첫째, 원상 저항성으로, 주어진 해시 값에 대해 그 값을 생성하는 원본 입력값을 찾는 것이 어려워야 한다. 둘째, 제2 원상 저항성으로, 주어진 입력값과 그 해시 값이 있을 때, 동일한 해시 값을 생성하는 다른 입력값을 찾는 것이 어려워야 한다. 셋째, 충돌 저항성으로, 서로 다른 두 입력값이 동일한 해시 값을 생성하는 경우(충돌)를 찾는 것이 어려워야 한다. TLS에서는 SHA-256이나 SHA-384 같은 SHA-2 계열의 해시 함수가 널리 사용된다.

SSL/TLS 핸드셰이크 과정과 실제 데이터 전송에서 해시 함수는 다양한 방식으로 활용된다. 핸드셰이크 메시지의 무결성을 검증하기 위해 Finished 메시지에 해시 값을 포함시킨다. 또한, HMAC이라는 기술을 통해 메시지 인증 코드를 생성하여 전송 중인 데이터가 변조되지 않았음을 보장한다. 이는 대칭키 암호화와 결합되어 데이터의 기밀성과 무결성을 동시에 제공하는 암호 스위트의 구성 요소로 작동한다.

SSL/TLS 핸드셰이크 과정의 첫 번째 단계는 ClientHello와 ServerHello 메시지 교환이다. 이 단계에서 클라이언트와 서버는 서로의 암호화 능력을 확인하고, 이후 통신에 사용할 보안 매개변수를 협상한다.

클라이언트가 연결을 시작하면 먼저 ClientHello 메시지를 서버로 보낸다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 지원하는 암호 스위트 목록, 클라이언트가 생성한 무작위 데이터(클라이언트 랜덤), 그리고 선택적으로 세션 ID나 서버 이름 표시(SNI)와 같은 정보가 포함된다. 암호 스위트는 사용할 키 교환 알고리즘, 데이터 암호화 알고리즘, 메시지 인증 코드 알고리즘 등의 조합을 정의한다.

서버는 ClientHello 메시지를 받고, 자신이 지원하는 가장 강력한 공통 보안 설정을 선택하여 응답한다. 서버는 ServerHello 메시지를 클라이언트에게 보내는데, 여기에는 협상된 TLS 버전, 선택된 암호 스위트, 서버가 생성한 무작위 데이터(서버 랜덤), 그리고 필요시 재개할 세션 ID가 포함된다. 이 선택은 클라이언트가 제안한 목록 중에서 이루어지며, 서버의 정책과 보안 설정에 따라 결정된다.

이 두 메시지의 교환을 통해 양측은 이후 통신에 사용할 보안 프로토콜의 기본 틀을 확립한다. 교환된 랜덤 값은 이후 마스터 시크릿 및 세션 키 생성의 중요한 입력값으로 사용된다. 협상이 성공하면 다음 단계인 인증서 검증 및 키 교환으로 진행되지만, 서버가 클라이언트가 제안한 암호 스위트를 하나도 지원하지 않으면 핸드셰이크는 실패하게 된다.

클라이언트가 서버의 디지털 인증서를 수신하면, 신뢰할 수 있는 인증 기관(CA)에 의해 서명되었는지 검증하는 과정이 시작됩니다. 클라이언트(주로 웹 브라우저)는 내장된 신뢰할 수 있는 루트 인증서 저장소를 확인하여, 서버 인증서의 발급자 체인을 따라 올라가 최종적으로 알려진 루트 CA에 도달하는지 확인합니다. 이 과정에서 인증서의 유효 기간, 도메인 이름(CN 또는 SAN), 그리고 서명의 무결성도 검사합니다. 검증이 실패하면 사용자에게 보안 경고를 표시합니다.

검증이 성공하면, 키 교환 단계로 넘어갑니다. 클라이언트는 서버 인증서에 포함된 서버의 공개키를 사용하여, 이후 통신에 사용할 대칭키인 '프리마스터 시크릿'을 암호화하여 서버로 전송합니다. 이때 사용되는 키 교환 알고리즘은 핸드셰이크 초기에 협상된 것을 따릅니다. 역사적으로는 RSA 암호화가 일반적이었으나, 최신 TLS에서는 디피-헬만 키 교환 또는 그 변형인 ECDHE(Elliptic Curve Diffie-Hellman Ephemeral) 방식이 더 선호됩니다. ECDHE는 전방향 비밀성을 제공하여, 향후 서버의 개인키가 유출되더라도 과거의 통신 세션을 복호화할 수 없게 만듭니다.

서버는 자신의 개인키로 암호화된 프리마스터 시크릿을 복호화합니다. 이제 클라이언트와 서버 양측은 공유된 프리마스터 시크릿과 핸드셰이크 과정에서 교환된 클라이언트/서버 랜덤 값을 입력으로 사용하여, 실제 데이터 암호화와 무결성 검증에 사용될 동일한 세션 키 세트를 도출합니다. 이 키 교환과 생성 과정이 완료되면, 핸드셰이크의 최종 단계로 넘어가 양측이 준비가 되었음을 암호화된 'Finished' 메시지로 확인합니다.

SSL/TLS 핸드셰이크의 핵심 단계인 키 교환이 완료되면, 클라이언트와 서버는 모두 마스터 시크릿을 공유하게 된다. 이 마스터 시크릿은 양측에서 동일한 알고리즘을 사용하여 일련의 세션 키를 생성하는 데 사용되는 기반 데이터이다. 생성된 세션 키는 실제 데이터 암호화와 무결성 검증에 사용된다.

세션 키는 일반적으로 다음과 같은 목적으로 생성된다.

* 암호화 키: 대칭키 암호화 알고리즘(예: AES, ChaCha20)에서 데이터를 암호화하고 복호화하는 데 사용된다.

* 인증 키: 메시지 인증 코드(MAC)를 생성하여 전송된 데이터의 무결성(변조 여부)을 검증하는 데 사용된다.

세션 키 생성이 완료되면, 클라이언트와 서버는 서로에게 "Change Cipher Spec" 메시지를 보낸다. 이 메시지는 "지금부터 협상된 암호 스위트와 생성된 세션 키를 사용하여 통신을 시작한다"는 신호이다. 이어서 "Finished" 메시지를 교환한다. 이 메시지는 핸드셰이크 과정 전체의 무결성을 검증하는 데 사용되며, 협상된 키로 암호화되어 전송된다. 상대방이 이 메시지를 정상적으로 복호화하고 검증하면, 핸드셰이크는 성공적으로 완료된 것이다.

이 시점부터 애플리케이션 데이터(예: HTTP 요청과 응답)의 전송이 시작된다. 모든 데이터는 세션 키를 사용한 대칭키 암호화로 보호되며, 각 데이터 기록에는 무결성을 보장하기 위해 MAC이 첨부된다. 이렇게 설정된 보안 채널은 연결이 유지되는 동안, 또는 협상된 세션 만료 시간까지 지속된다.

디지털 인증서는 공개 키 기반 구조(PKI)의 핵심 요소로, 특정 공개 키가 특정 주체(예: 웹사이트 도메인)에 속한다는 것을 신뢰할 수 있는 제삼자인 인증 기관(CA)이 보증하는 전자 문서이다. 인증서는 X.509라는 국제 표준 형식을 따르며, 크게 인증서 정보 자체와 이를 발급한 CA의 디지털 서명으로 구성된다.

인증서 정보에는 다음과 같은 주요 필드가 포함된다.

확장 필드 중 대체 이름(SAN)은 특히 중요한데, 하나의 인증서로 여러 도메인이나 서브도메인을 보호할 수 있게 해준다[4]. 인증서의 무결성과 진위는 CA의 디지털 서명으로 보장된다. CA는 인증서 정보를 해시 함수로 요약한 후, 자신의 비밀 키로 이 해시값을 암호화하여 서명을 생성한다. 클라이언트는 CA의 공개 키를 사용해 이 서명을 검증함으로써 인증서 내용이 위변조되지 않았음을 확인한다.

인증 기관(CA, Certificate Authority)은 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제3자 기관이다. 이 기관의 핵심 역할은 공개키 암호화 시스템에서 웹사이트 서버의 신원을 검증하고, 그 신원에 대한 보증을 제공하는 것이다. 사용자가 HTTPS로 접속한 웹사이트가 진짜 해당 사이트의 소유자임을 확인할 수 있도록, CA는 서버의 공개키와 서버 정보를 자신의 개인키로 서명하여 인증서를 생성하여 발급한다.

인증 기관의 주요 기능은 다음과 같다.

CA는 계층적 구조로 운영된다. 최상위에 위치한 루트 CA는 자신을 스스로 신뢰하며, 그 아래 중간 CA를 인증한다. 중간 CA는 실제 최종 사용자나 서버에 대한 인증서를 발급하는 역할을 담당한다. 이 계층 구조는 루트 CA의 개인키를 오프라인으로 안전하게 보관하면서도 대량의 인증서 발급 업무를 효율적으로 처리할 수 있게 한다.

브라우저와 운영체제는 주요 CA들의 루트 인증서 목록을 미리 내장하고 있다. 사용자가 HTTPS 사이트에 접속하면, 브라우저는 서버로부터 받은 인증서가 신뢰할 수 있는 CA로부터 서명되었는지, 그리고 유효한지 이 체인을 따라 검증한다. 이 과정에서 CA의 역할은 절대적이며, 만약 CA가 잘못되거나 해킹당하면 전체 신뢰 체계가 위협받게 된다[5].

인증서 검증 체인은 최종 사용자에게 제공되는 서버 인증서가 신뢰할 수 있는 루트 인증 기관으로부터 발급되었음을 계층적으로 증명하는 구조이다. 이 체인은 일반적으로 세 단계로 구성된다. 최상위에는 신뢰의 근간이 되는 루트 CA의 루트 인증서가 위치한다. 중간에는 루트 CA가 직접 서명한 중간 인증 기관의 인증서가 있으며, 최하위에는 중간 CA가 서명한 최종 서버의 도메인 인증서가 위치한다. 클라이언트(예: 웹 브라우저)는 서버로부터 받은 인증서와 함께 중간 인증서 체인을 제공받아, 최종 인증서의 서명을 루트 인증서까지 거슬러 올라가 검증한다.

검증 과정은 다음과 같이 진행된다. 먼저, 클라이언트는 서버 인증서에 포함된 발급자 정보를 확인하고, 제공받은 중간 인증서 중 해당 발급자의 공개키를 사용해 서버 인증서의 서명을 검증한다. 그런 다음, 중간 인증서의 발급자를 확인하고, 클라이언트에 내장된 루트 인증서 저장소에서 해당 루트 CA의 인증서를 찾아, 루트 CA의 공개키로 중간 인증서의 서명을 검증한다. 이 과정에서 모든 서명 검증이 성공하고, 각 인증서의 유효기간과 도메인 이름 등이 정상적이면 인증서 체인의 신뢰성이 확립된다.

이 체인 구조의 핵심 장점은 루트 CA의 개인키를 빈번히 사용하지 않고도 안전하게 대량의 인증서를 발급할 수 있다는 점이다. 루트 키는 오프라인으로 보호되며, 중간 CA를 통해 발급 업무를 위임한다. 만약 중간 CA의 키가 유출되더라도 해당 중간 인증서만 인증서 폐지 목록에 등록하거나 무효화하면 되므로, 전체 루트 신뢰 체계를 교체하는 것보다 훨씬 효율적으로 위험을 관리할 수 있다.

HTTPS는 SSL/TLS 프로토콜을 통해 데이터의 기밀성을 보장한다. 기밀성은 통신 내용이 오직 의도된 수신자만 이해할 수 있도록 보호하는 것을 의미한다. 즉, 전송 중인 데이터가 제삼자에게 도청되거나 노출되더라도 그 내용을 알아볼 수 없게 만드는 것이 핵심 목표이다. 이를 위해 대칭키 암호화 방식이 실제 데이터 암호화에 사용된다.

데이터 암호화는 SSL/TLS 핸드셰이크 과정에서 협상된 세션 키를 바탕으로 이루어진다. 핸드셰이크가 완료되면, 클라이언트와 서버는 동일한 세션 키를 공유하게 된다. 이후 모든 HTTP 메시지(헤더와 본문 포함)는 이 세션 키를 이용한 대칭키 암호 알고리즘(예: AES, ChaCha20)으로 암호화되어 전송된다. 대칭키 암호화는 암호화와 복호화에 같은 키를 사용하며, 처리 속도가 빠르기 때문에 대량의 데이터를 실시간으로 안전하게 교환하는 데 적합하다.

기밀성 보장의 효과는 네트워크 경로상의 모든 구간에서 적용된다. 데이터가 사용자의 브라우저를 떠나 웹 서버에 도달하기까지 거치는 라우터, 프록시 서버, ISP 등에서 패킷이 가로채인다 하더라도, 세션 키를 모르는 공격자는 암호문을 원래의 평문으로 복원할 수 없다. 이는 로그인 자격증명, 결제 정보, 개인 메시지, 검색 기록 등 모든 민감한 정보가 안전하게 보호됨을 의미한다.

따라서 HTTPS의 기밀성은 온라인 뱅킹, 전자상거래, 이메일 서비스와 같이 프라이버시가 중요한 모든 웹 통신의 필수적인 기반이 된다. 단, 이 보호는 전송 중인 데이터에만 적용되며, 클라이언트 또는 서버 측에 저장된 데이터의 보안(예: 데이터베이스 해킹)까지는 보장하지 않는다는 점을 유의해야 한다.

HTTPS는 SSL/TLS 프로토콜을 통해 데이터의 무결성을 보장한다. 무결성이란 전송 중인 데이터가 의도하지 않게 변경되거나 손상되지 않았음을 의미한다. 즉, 송신자가 보낸 데이터가 수신자에게 그대로 도착했는지 확인할 수 있어야 한다.

이를 위해 해시 함수와 메시지 인증 코드(MAC)가 사용된다. 송신 측에서는 전송할 평문 데이터에 대해 해시 함수를 적용하여 고정된 길이의 해시 값(다이제스트)을 생성한다. 이 해시 값은 세션 키와 함께 MAC 알고리즘을 통해 계산되어 메시지에 첨부된다. 수신 측에서는 동일한 세션 키와 알고리즘을 사용하여 도착한 데이터의 MAC 값을 다시 계산하고, 전송받은 MAC 값과 비교한다. 두 값이 일치하면 데이터가 중간에 변조되지 않았음을 신뢰할 수 있다.

이 메커니즘은 데이터의 일부가 변경되면 해시 값이 완전히 달라지는 해시 함수의 특성[6]에 기반한다. 따라서 중간에서 데이터를 가로채 변조하려는 시도는 수신 측의 검증 단계에서 반드시 드러난다. 이는 중간자 공격(MITM)으로 인한 데이터 변조를 방지하는 핵심 기능이다.

HTTPS는 통신 상대방의 신원을 확인하여 중간자 공격을 방지하는 인증 기능을 제공한다. 이는 디지털 인증서를 통해 이루어진다. 웹 서버는 신뢰할 수 있는 제3자인 인증 기관(CA)으로부터 서버의 공개키와 신원 정보가 포함된 인증서를 발급받는다. 클라이언트(예: 웹 브라우저)는 서버로부터 전달받은 이 인증서를 미리 내장된 CA의 공개키를 사용해 검증한다. 검증이 성공하면, 해당 서버가 인증서에 명시된 도메인의 합법적인 소유자임을 신뢰할 수 있게 된다.

인증 과정은 SSL/TLS 핸드셰이크 초기 단계에서 이루어진다. 서버는 ServerHello 메시지 이후 자신의 인증서를 클라이언트에 전송한다. 클라이언트는 인증서의 유효 기간, 발급자, 도메인 이름(Common Name 또는 Subject Alternative Name) 등을 확인하고, 인증서 서명이 신뢰하는 CA로부터 생성된 것인지 검증 체인을 따라 확인한다[7]. 이를 통해 가짜 서버가 아닌 진짜 서버와 통신하고 있음을 보장받는다.

인증 보장의 핵심은 공개키 기반 구조(PKI)에 있다. CA는 서버의 공개키와 정보를 자신의 비밀키로 서명하여 인증서를 생성한다. 클라이언트는 CA의 공개키로 이 서명을 검증할 수 있으므로, 인증서 내용이 CA에 의해 보증되었다고 믿을 수 있다. 결과적으로, 클라이언트는 검증된 서버의 공개키를 안전하게 얻고, 이를 이용해 비대칭키 암호화 방식으로 세션 키를 교환하여 이후 모든 통신의 기밀성과 무결성도 함께 확보한다.

웹 서버에 HTTPS를 설정하는 과정은 주로 디지털 인증서를 획득하고 서버 소프트웨어에 적용하는 것을 중심으로 이루어진다. 일반적인 절차는 다음과 같다.

먼저, 신뢰할 수 있는 인증 기관(CA)로부터 서버 인증서를 발급받아야 한다. 이 과정에서 인증서 서명 요청(CSR) 파일을 생성해야 한다. CSR에는 서버의 공개 키와 웹사이트 도메인명, 조직 정보 등이 포함된다. 인증 기관은 이 CSR을 검증한 후 서버 인증서를 발급한다. 인증서는 유료로 구매하거나 Let's Encrypt와 같은 무료 CA를 통해 발급받을 수 있다.

발급받은 인증서와 개인 키 파일을 웹 서버 소프트웨어에 설정한다. 널리 사용되는 아파치 HTTP 서버와 Nginx의 설정 방법은 다음과 같다.

설정 적용 후, 서버를 재시작하고 https://를 통해 접속이 정상적으로 이루어지는지 확인해야 한다. 또한, HTTP Strict Transport Security(HSTS) 헤더를 설정하여 브라우저가 강제적으로 HTTPS로만 접속하도록 유도하거나, TLS 프로토콜 버전과 암호 스위트를 최신 보안 권고에 맞게 구성하는 추가 보안 설정을 적용하는 것이 일반적이다.

인증서 발급은 일반적으로 인증 기관을 통해 이루어진다. 웹사이트 운영자는 먼저 공개키와 개인키 쌍을 생성하고, CSR을 생성하여 신원 정보와 공개키를 포함시킨다. 이 CSR을 선택한 CA에 제출하면, CA는 신청자의 도메인 소유권을 검증한 후 디지털 인증서를 발급한다. 검증 수준에 따라 DV, OV, EV 인증서로 구분된다.

발급된 인증서는 웹 서버(아파치, Nginx 등)에 설치되어야 한다. 설정 과정은 서버 소프트웨어에 따라 다르지만, 일반적으로 개인키 파일과 인증서 파일(및 필요한 경우 중간 인증서 체인 파일)의 경로를 서버 설정 파일에 지정한다. 이후 서버를 재시작하면 HTTPS 연결이 활성화된다.

인증서는 유효 기간이 있으며, 보통 1년에서 최대 13개월[8] 동안 유효하다. 만료되기 전에 갱신 과정을 거쳐야 한다. 갱신은 새로운 키 쌍을 생성하여 새 CSR을 만들거나, 기존 키를 재사용하여 인증서 갱신 요청을 할 수 있다. 많은 CA와 호스팅 제공업체는 만료 알림과 자동 갱신 서비스를 제공하여 갱신 과정을 단순화한다. 또한 Let's Encrypt와 같은 무료 CA는 ACME 프로토콜을 사용하여 인증서 발급과 갱신을 완전히 자동화한다.

중간자 공격은 통신 경로 상에 침입자가 위치하여 송신자와 수신자 사이의 통신을 가로채거나 변조하는 공격 방식이다. HTTPS는 SSL/TLS 프로토콜을 통해 이러한 공격을 방어하도록 설계되었지만, 구현상의 결함이나 잘못된 설정, 인증서 검증 실패 시에는 여전히 위험에 노출될 수 있다.

공격자는 주로 다음과 같은 방법으로 HTTPS 연결을 대상으로 중간자 공격을 시도한다. 첫째, 사용자가 공용 와이파이와 같은 불안전한 네트워크에 접속했을 때, 공격자가 자신을 프록시 서버로 위장하여 트래픽을 중간에서 릴레이한다. 둘째, 사용자의 장치에 악성 소프트웨어를 설치하여 신뢰할 수 있는 인증 기관(CA)의 루트 인증서를 추가하거나, 로컬에서 통신을 가로채는 방법을 사용한다. 셋째, 디지털 인증서를 위조하거나 도난당한 인증서를 이용하여 서버를 사칭한다.

HTTPS가 중간자 공격에 취약해지는 주요 상황은 다음과 같다. 사용자가 브라우저의 인증서 경고를 무시하고 불완전한 연결을 진행하는 경우가 가장 흔하다. 또한, 서버가 오래되거나 취약한 SSL/TLS 버전(예: SSL 2.0/3.0, TLS 1.0)이나 취약한 암호화 스위트를 지원할 때 공격에 이용될 수 있다. 인증서 검증 과정에서 문제가 발생하는 경우도 있는데, 예를 들어 인증서가 만료되었거나, 신뢰할 수 없는 CA에서 발급되었거나, 도메인 이름이 일치하지 않는 경우이다.

이러한 위험을 완화하기 위해, 서버 관리자는 최신 TLS 버전을 사용하고 강력한 암호화 스위트를 구성해야 한다. 사용자는 브라우저의 보안 경고를 절대 무시하지 말고, 공용 네트워크에서는 VPN을 사용하는 것이 좋다. 또한, 웹사이트는 HSTS 헤더를 설정하여 브라우저가 항상 안전한 연결을 사용하도록 강제할 수 있다.

디지털 인증서 체계는 HTTPS 보안의 핵심이지만, 여러 취약점과 공격 벡터가 존재한다. 가장 대표적인 문제는 인증 기관의 신뢰성 문제이다. 수백 개의 CA 중 하나라도 보안이 취약하거나 악의적으로 행동하면, 합법적인 사이트를 사칭하는 위조 인증서를 발급할 수 있다[12]. 또한, CA가 실수로 도메인 소유권 확인을 제대로 수행하지 않고 인증서를 발급하는 경우도 있다.

특정 암호화 알고리즘의 취약점 발견은 해당 알고리즘으로 서명된 인증서 전체의 신뢰를 떨어뜨린다. 과거 MD5 해시 함수의 충돌 취약점을 이용해 위조 루트 인증서를 생성한 사례가 있다[13]. SHA-1 알고리즘도 유사한 이유로 단계적으로 폐지되었다. 인증서의 유효기간이 길어서 키가 노출되었을 때 대응이 느려지는 문제, 그리고 폐기된 인증서를 실시간으로 확인하는 CRL이나 OCSP 프로토콜의 성능 및 프라이버시 문제도 지적받는다.

이러한 취약점을 완화하기 위해 인증서 투명성 같은 감사 로그 시스템이 도입되었으며, 인증서의 유효기간은 짧아지는 추세이다. 또한, 브라우저와 운영체제는 신뢰할 수 있는 루트 인증서 목록을 엄격하게 관리하고, 문제가 발견된 CA를 신뢰 목록에서 제거하는 조치를 취한다.

TLS 1.3은 TLS 1.2에 비해 보안성과 성능을 크게 향상시킨 주요 업데이트이다. 가장 큰 변화는 암호화 방식의 간소화와 불필요한 기능 제거로, 공격 표면을 줄이는 데 중점을 두었다. 이전 버전에서 지원되던 RC4, SHA-1, CBC 모드 암호화 등 안전하지 않거나 오래된 암호화 알고리즘 대부분이 제거되었다. 대신 AEAD 암호화 방식을 사용하는 AES-GCM과 ChaCha20-Poly1305 같은 현대적이고 안전한 알고리즘만이 필수로 지원된다.

핸드셰이크 과정이 단축되어 연결 설정 시간이 줄어들었다. TLS 1.3 핸드셰이크는 기본적으로 1-RTT(Round Trip Time)로 완료되며, 0-RTT 모드를 통해 이전에 방문한 사이트에 대한 재연결 시 지연을 더욱 줄일 수 있다. 또한 키 교환 메커니즘이 디피-헬만 키 교환에 집중되었고, RSA를 이용한 키 교환은 보안상의 이유로 제거되었다. 이로 인해 전달 비밀성이 기본적으로 보장된다.

보안 측면에서도 중요한 개선이 이루어졌다. 핸드셰이크 과정 중 교환되는 메시지가 모두 암호화되어, 이전 버전에서 가능했는 패딩 오라클 공격 같은 위협을 차단한다. 인증서와 관련된 확장 기능도 개선되어 불필요한 정보 노출을 최소화한다. 이러한 변화들은 TLS 1.3이 더 빠르고, 더 강력한 보안을 제공하는 프로토콜로 자리매김하도록 했다.

HTTP/3은 HTTP 프로토콜의 세 번째 주요 버전으로, 기존 TCP 기반의 HTTP/2와 달리 QUIC 프로토콜을 전송 계층으로 사용한다. 이 변화의 핵심 목표는 연결 설정 지연과 패킷 손실에 따른 성능 저하를 줄이는 것이다. QUIC은 UDP 위에 구축되어, TCP의 핸드셰이크 과정을 통합하고 개선함으로써 연결 시작 속도를 크게 단축한다.

HTTP/3과 QUIC의 주요 특징은 다음과 같다.

QUIC 연결은 연결 식별자(Connection ID)를 사용하여 관리된다. 이는 클라이언트의 네트워크 주소가 변경되더라도(예: Wi-Fi에서 셀룰러로 전환) 연결을 유지할 수 있게 해주며, 이동 중인 사용자에게 유리하다. 또한, 모든 QUIC 패킷은 기본적으로 암호화되어 있어, 전송 계층에서의 메타데이터 조차도 중간자에 의해 쉽게 관찰되거나 조작되지 않도록 한다.

이 프로토콜은 아직 보급 단계에 있지만, 주요 CDN 업체와 웹 브라우저에서 점차 지원을 확대하고 있다. HTTP/3은 HTTPS의 보안 모델을 유지하면서, 특히 불안정한 네트워크 환경에서의 웹 경험을 개선할 것으로 기대된다.