Baek Seung Jin

꾸준히 성장하는 기술블로그

3 minute read

HTTPS란?

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP 프로토콜의 보안 버전으로, 웹 브라우저와 서버 간의 통신을 암호화하여 데이터의 기밀성, 무결성, 인증을 보장합니다. HTTPS는 기존 HTTP 프로토콜에 SSL/TLS(Secure Sockets Layer/Transport Layer Security) 프로토콜을 결합한 형태입니다.

HTTPS는 기본적으로 HTTP와 동일한 요청/응답 메커니즘을 사용하지만, 모든 데이터가 암호화된 상태로 전송됩니다. 표준 HTTP는 포트 80을 사용하는 반면, HTTPS는 기본적으로 포트 443을 사용합니다.


HTTPS가 해결하는 HTTP의 보안 문제

기존 HTTP 프로토콜은 다음과 같은 보안 취약점을 가지고 있습니다.

  1. 도청(Eavesdropping): HTTP 통신은 평문(plaintext)으로 이루어지기 때문에, 네트워크 상에서 패킷을 가로채면 내용을 확인할 수 있습니다.
  2. 변조(Tampering): 중간자(Man-in-the-Middle) 공격을 통해 전송 중인 데이터를 수정할 수 있습니다.
  3. 위장(Spoofing): 공격자가 합법적인 웹사이트인 것처럼 위장하여 사용자의 민감한 정보를 탈취할 수 있습니다.

HTTPS는 이런 문제들을 암호화와 인증을 통해 해결합니다.


SSL/TLS 이해하기

SSL과 TLS의 관계

  • SSL(Secure Sockets Layer): Netscape에서 개발한 최초의 보안 프로토콜로, 버전은 1.0, 2.0, 3.0까지 있습니다.
  • TLS(Transport Layer Security): SSL의 후속 버전으로, IETF에 의해 표준화되었습니다. TLS 1.0은 SSL 3.0의 업그레이드 버전입니다.

현재는 SSL 3.0까지 모두 보안 취약점이 발견되어 사용이 권장되지 않으며, TLS가 표준으로 사용됩니다. 하지만 관행적으로 아직도 “SSL 인증서” 같은 용어가 사용됩니다.

최신 TLS 버전

  • TLS 1.0, 1.1: 더 이상 안전하지 않아 사용이 권장되지 않음
  • TLS 1.2: 널리 사용되는 안전한 버전
  • TLS 1.3(2018년 출시): 가장 최신 버전으로, 핸드셰이크 과정을 간소화하고 보안을 강화함


SSL/TLS가 제공하는 보안 기능

  1. 기밀성(Confidentiality): 대칭 키 암호화를 사용하여 데이터를 암호화함으로써 제3자가 통신 내용을 읽을 수 없게 합니다.
  2. 무결성(Integrity): MAC(Message Authentication Code)을 사용하여 전송 중 데이터 변조를 방지합니다.
  3. 인증(Authentication): 인증서와 공개 키 기반구조(PKI)를 사용하여 서버(경우에 따라 클라이언트)의 신원을 확인합니다.


SSL/TLS 암호화 과정

비대칭 키 암호화와 대칭 키 암호화의 결합

SSL/TLS는 두 가지 암호화 방식을 함께 사용합니다:

  • 비대칭 키 암호화(Asymmetric Encryption): 공개 키와 개인 키 쌍을 사용하며, 핸드셰이크 과정에서 대칭 키를 안전하게 교환하는 데 사용됩니다. 계산 비용이 높지만 보안성이 뛰어납니다.
  • 대칭 키 암호화(Symmetric Encryption): 동일한 키로 암호화와 복호화를 수행하며, 실제 데이터 전송 시 사용됩니다. 계산 비용이 낮고 속도가 빠릅니다.

이 두 방식을 결합함으로써, SSL/TLS는 보안성과 성능 간의 균형을 유지합니다.

TLS 핸드셰이크 과정

TLS 핸드셰이크는 보안 연결을 설정하기 위한 단계로, 다음과 같이 진행됩니다.

image

TLS 1.2 핸드셰이크

  1. ClientHello:
    • 클라이언트가 서버에 연결을 시도하며 지원하는 암호화 알고리즘(cipher suite) 목록, 랜덤 데이터(client random), 세션 ID 등을 전송합니다.
  2. ServerHello:
    • 서버가 클라이언트의 제안 중에서 가장 강력한 암호화 알고리즘을 선택하고, 자신의 랜덤 데이터(server random)를 전송합니다.
  3. Certificate:
    • 서버가 자신의 SSL/TLS 인증서를 클라이언트에게 전송합니다.
    • 이 인증서에는 서버의 공개 키와 CA(Certificate Authority)의 디지털 서명이 포함되어 있습니다.
  4. ServerKeyExchange (필요한 경우):
    • 일부 암호화 알고리즘에서 서버가 추가적인 키 교환 정보를 전송합니다.
  5. CertificateRequest (선택적):
    • 서버가 클라이언트 인증서를 요청할 수 있습니다(상호 인증).
  6. ServerHelloDone:
    • 서버가 자신의 초기 메시지 전송을 완료했음을 알립니다.
  7. ClientKeyExchange:
    • 클라이언트가 pre-master secret을 생성하고, 서버의 공개 키로 암호화하여 전송합니다.
    • 클라이언트와 서버는 client random, server random, pre-master secret을 사용하여 각각 동일한 master secret을 생성합니다.
    • 이 master secret에서 세션 키(대칭 키)가 파생됩니다.
  8. ChangeCipherSpec:
    • 클라이언트가 이제부터 합의된 대칭 키로 암호화된 메시지를 보낼 것임을 알립니다.
  9. Finished:
    • 클라이언트가 지금까지의 핸드셰이크 메시지의 해시를 암호화하여 전송합니다.
  10. ChangeCipherSpec:
    • 서버도 대칭 키 암호화로 전환함을 알립니다.
  11. Finished:
    • 서버가 핸드셰이크 메시지의 해시를 암호화하여 전송합니다.
    • 클라이언트와 서버가 이 해시를 확인하여 핸드셰이크의 무결성을 검증합니다.

이제 통신 채널이 수립되어, 애플리케이션 데이터를 암호화하여 주고받을 수 있습니다.

TLS 1.3 핸드셰이크 (간소화된 최신 버전)

TLS 1.3에서는 핸드셰이크 과정이 1-RTT(Round Trip Time)로 단축되었습니다:

  1. ClientHello:
    • 클라이언트가 자신의 암호화 알고리즘 목록뿐만 아니라, 가능한 키 교환 매개변수를 포함한 “키 공유(key share)” 정보도 함께 전송합니다.
  2. ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished:
    • 서버가 한 번에 모든 응답을 보냅니다.
    • 이미 클라이언트의 키 공유 정보를 받았기 때문에, 바로 키를 계산하고 통신을 시작할 수 있습니다.
  3. Finished:
    • 클라이언트가 확인 메시지를 보내고 애플리케이션 데이터 교환을 시작합니다.

TLS 1.3은 보안이 낮은 알고리즘을 제거하고, 핸드셰이크 과정을 간소화하여 더 빠르고 안전한 연결을 제공합니다.


SSL/TLS 인증서의 구조

SSL/TLS 인증서는 아래와 같은 정보를 포함합니다.

  • 웹사이트 도메인 이름(Common Name)
  • 인증서 소유자 정보
  • 발급 기관(CA) 정보
  • 발급 일자와 만료 일자
  • 공개 키
  • 디지털 서명
  • 확장 필드(SAN, 키 사용 등)

인증서 검증 과정

브라우저가 서버의 인증서를 검증하는 과정은 다음과 같습니다.

  1. 인증서의 디지털 서명을 발급 CA의 공개 키로 검증
  2. 인증서의 만료 여부 확인
  3. 인증서가 해지되었는지 확인
  4. 도메인 이름과 인증서의 “웹사이트 도메인 이름(Common Name)” 또는 “SAN(Subject Alternative Name)” 일치 여부 확인
  5. 인증서 체인 검증


서버 개발시 HTTPS 적용하기

웹 서버(Nginx, Apache 등)에서 HTTPS를 적용하려면 다음이 필요합니다.

  1. 인증서 취득:
    • Let’s Encrypt와 같은 무료 CA 또는 상용 CA에서 인증서 발급
    • 자체 서명된 인증서(개발 환경용)
  2. 서버 구성: 
    # Nginx 예시
server {
    listen         443 ssl;
    server_name    example.com;
       
    ssl_certificate      /path/to/certificate.crt;
    ssl_certificate_key  /path/to/private.key;
       
    ssl_protocols        TLSv1.2 TLSv1.3;
    ssl_ciphers          HIGH:!aNULL:!MD5;
       
    # ... 나머지 구성
}
  3. HTTP에서 HTTPS로 리다이렉션: 
    server {
    listen       80;
    server_name  example.com;
    return       301 https://$host$request_uri;
}

일반적인 HTTPS 문제 해결법

  1. 인증서와 도메인 불일치:
    • 인증서의 CN/SAN이 실제 접속 도메인과 일치하지 않는 경우
    • 해결: 올바른 도메인에 대한 인증서 발급 또는 SAN에 필요한 도메인 추가
  2. 인증서 만료:
    • 해결: 자동 갱신 설정
  3. 혼합 콘텐츠(Mixed Content) 경고:
    • HTTPS 페이지 내에 HTTP 리소스 포함 시 발생
    • 해결: 모든 리소스를 HTTPS로 제공

Leave a comment

You may also enjoy