길리랩blog

SSL/TLS 보안 통신과 인증서 설정 가이드

SSL/TLS의 핸드셰이크, 인증서와 암호 스위트, 웹 서버 설정 및 주요 취약점 대응을 정리한 보안 통신 가이드

2026-08-14 · 최초 발행 2025-06-28

HTTPS 통신은 TLS 연결에서 시작된다

SSL(Secure Socket Layer)과 TLS(Transport Layer Security)는 인터넷을 오가는 데이터를 암호화하는 프로토콜이다. 사용자와 서버 사이의 통신이 제3자에게 도청되거나 변조되는 일을 막기 위해 쓰이며, 웹 브라우징뿐 아니라 이메일, 인스턴트 메시징, VoIP에도 적용된다.

SSL은 현재 더 이상 사용되지 않고 TLS가 이를 대체했다. 다만 업계에서는 여전히 SSL 인증서, SSL 설정처럼 SSL이라는 표현이 널리 남아 있다.

SSL에서 TLS로 이어진 변화

SSL/TLS는 보안 결함을 보완하며 발전해 왔다.

  • 1994년: Netscape에서 SSL 1.0 개발, 내부적으로만 사용
  • 1995년: SSL 2.0 공개, 심각한 보안 결함 발견
  • 1996년: SSL 3.0 출시, 주요 보안 개선
  • 1999년: IETF(Internet Engineering Task Force)에서 SSL 3.0 기반의 TLS 1.0 표준화
  • 2006년: TLS 1.1 발표, CBC 공격 방어 개선
  • 2008년: TLS 1.2 발표, SHA-256 지원 및 AEAD 암호화
  • 2018년: TLS 1.3 발표, 핸드셰이크 과정 간소화와 보안 강화

인증과 키 교환 뒤에 암호화된 세션이 열린다

TLS 연결은 클라이언트와 서버가 지원 가능한 암호화 방식을 협상하고, 서버 신원을 확인한 뒤 키를 교환하는 과정으로 시작한다.

⤢✕ServerClientServerClient보안 통신 시작Client Hello (지원하는 암호화 알고리즘, 랜덤 데이터)Server Hello (선택된 암호화 알고리즘, 랜덤 데이터)서버 인증서 전송Server Hello Done인증서 검증키 교환 정보 전송Finished (암호화된 메시지)Finished (암호화된 메시지)

TLS 1.3에서는 이 교환 절차가 줄어든다. 클라이언트는 처음 요청에서 지원 암호화 방식과 키 공유 파라미터를 전달하고, 서버는 응답에서 인증서와 키 교환 정보, Finished 메시지를 함께 보낸다.

⤢✕ServerClientServerClient보안 통신 시작 (1-RTT)Client Hello (지원 암호화, 키 공유 파라미터)Server Hello, 인증서, 키 교환 정보, FinishedFinished

연결을 구성하는 인증서와 암호 체계

X.509 기반 디지털 인증서는 서버의 신원을 확인하고 공개키를 전달한다. 인증서는 CA(Certificate Authority)가 발급하고 서명하며, 인증서 체인을 통해 신뢰 구조를 형성한다.

TLS는 역할에 따라 다른 암호 기술을 사용한다.

  • 대칭키 암호화: AES, ChaCha20 등으로 실제 데이터를 암호화
  • 비대칭키 암호화: RSA, ECDHE, DHE 등으로 키 교환
  • 해시 함수: SHA-256, SHA-384 등으로 무결성 확인

암호 스위트(Cipher Suite)는 TLS 연결에 적용할 알고리즘의 조합이다. 예를 들어 TLS_AES_256_GCM_SHA384는 TLS 프로토콜, AES_256_GCM 대칭 암호화 알고리즘, SHA384 해시 함수를 나타낸다.

인증서 검증 범위와 보호 대상

인증서는 검증 수준에 따라 DV, OV, EV로 나뉜다.

DV(Domain Validation) 인증서는 도메인 소유권만 확인한다. 발급 과정이 빠르고 비용이 저렴해 개인 블로그나 소규모 웹사이트에 적합하다.

OV(Organization Validation) 인증서는 도메인 소유권과 조직 존재 여부를 확인한다. 중간 수준의 신뢰성을 제공하며, 기업 웹사이트나 중요도가 낮은 전자상거래에 적합하다.

EV(Extended Validation) 인증서는 가장 엄격한 검증 과정을 거친다. 구형 브라우저에서는 주소창에 조직명이 표시됐으며, 은행·금융기관·대규모 전자상거래에 적합하다.

보호 범위도 선택 기준이다. 단일 도메인 인증서는 하나의 도메인만 보호하고, 와일드카드 인증서는 주 도메인과 서브도메인(*.example.com)을 보호한다. 멀티 도메인 인증서(SAN)는 서로 다른 여러 도메인을 보호한다.

Apache와 Nginx에서 TLS를 적용하는 방법

Apache에서는 인증서와 개인키, CA 체인을 지정하고 취약한 프로토콜을 제외하는 방식으로 구성할 수 있다.

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /path/to/certificate.crt
    SSLCertificateKeyFile /path/to/private.key
    SSLCertificateChainFile /path/to/ca-chain.crt

    # 보안 강화 설정
    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder on
    SSLCompression off
    SSLSessionTickets off
</VirtualHost>

Nginx에서는 TLS 프로토콜 범위, 인증서 파일, 세션 관련 설정을 함께 지정한다.

server {
    listen 443 ssl;
    server_name example.com;
    root /var/www/html;

    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;
    ssl_trusted_certificate /path/to/ca-chain.crt;

    # 보안 강화 설정
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
}

HTTP 요청은 HTTPS로 일관되게 전환해야 한다.

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Let's Encrypt 인증서는 Certbot으로 발급하고 갱신 여부를 확인할 수 있다.

# Certbot 설치
apt-get install certbot python3-certbot-nginx

# Nginx 웹 서버용 인증서 발급 및 자동 설정
certbot --nginx -d example.com -d www.example.com

# 인증서 자동 갱신 확인
certbot renew --dry-run

보안 헤더와 암호 스위트 점검

HSTS(HTTP Strict Transport Security)는 브라우저가 HTTPS만 사용하도록 지시한다.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

인증서 투명성(Certificate Transparency)은 SSL/TLS 인증서를 공개 로그에 기록해 잘못 발급된 인증서를 감지하는 데 도움을 준다.

Expect-CT: max-age=86400, enforce, report-uri="https://example.com/report"

TLS 1.2에서 사용할 수 있는 권장 암호 스위트는 다음과 같다. TLS 1.3은 안전한 암호 스위트만 정의되어 있다.

# 권장 암호 스위트 (TLS 1.2)
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305

# TLS 1.3은 안전한 암호 스위트만 정의되어 있음

설정 상태는 SSL Labs Server Test, Mozilla Observatory, 명령줄 기반 분석 도구인 testssl.sh로 확인할 수 있다.

레거시 프로토콜과 압축 기능에서 발생한 취약점

POODLE(Padding Oracle On Downgraded Legacy Encryption)은 SSL 3.0의 취약점이다. 공격자가 SSL 3.0으로 다운그레이드를 유도한 뒤 암호화된 정보를 탈취할 수 있으므로 SSL 3.0을 비활성화한다.

BEAST(Browser Exploit Against SSL/TLS)는 TLS 1.0의 CBC 모드 취약점이며, TLS 1.1 이상 사용으로 대응한다.

HEARTBLEED는 2014년 발견된 OpenSSL의 심각한 취약점으로 서버 메모리 정보 유출이 가능하다. OpenSSL 업데이트와 인증서 재발급이 대응 방법이다.

BREACH와 CRIME은 HTTP 압축과 관련된 취약점이다. 민감한 콘텐츠의 압축을 비활성화해 대응한다.

TLS 1.3이 바꾼 연결 조건

TLS 1.3은 핸드셰이크를 단순화해 RTT를 줄였고, 반복 접속의 속도를 높이는 0-RTT 재연결을 지원한다. RC4, DES, 3DES, MD5 등 취약한 암호화 알고리즘을 제거했으며, 서버 인증서를 제외한 모든 핸드셰이크 메시지를 암호화한다. 정방향 비밀성(Forward Secrecy)도 기본 지원한다.

금융권 정책에 나타나는 운영 기준

대형 은행 'A'는 고객 신뢰 확보를 위한 EV 인증서와 HSM에 저장된 키를 사용하는 이중 인증서 구조를 구현했다. 암호화 설정에서는 TLS 1.2 이상만 허용하고 최신 암호 스위트만 사용하며, OCSP Stapling을 활성화해 인증서 상태를 실시간으로 확인한다.

추가 보안 헤더는 다음과 같이 구성했다.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src https:; script-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

운영 과정에서는 분기별 SSL/TLS 설정 검토, 침투 테스트, 인증서 만료 자동 모니터링을 수행한다.

암호 전환과 인증서 자동화의 방향

TLS 1.3은 더 빠른 핸드셰이크와 향상된 보안성을 바탕으로 표준화와 보급이 확대되고 있으며, 레거시 시스템 호환성 문제 해결이 과제로 남아 있다.

양자 내성 암호화(Quantum-Resistant Cryptography)는 양자 컴퓨터 위협에 대비한 새로운 암호화 알고리즘 개발과 NIST 표준화 진행으로 이어지고 있다. 암호화 애질리티(Crypto Agility)는 취약점이 발견됐을 때 암호화 알고리즘을 빠르게 교체할 수 있는 구조를 뜻한다.

인증서 자동화 표준도 ACME 프로토콜 확장과 인증서 수명 단축(90일 → 30일)의 방향으로 발전하고 있다. TLS 운영은 최신 버전을 적용하는 데서 끝나지 않는다. 보안과 성능의 균형을 고려해 설정하고, 인증서와 프로토콜, 암호 스위트를 정기적으로 검토·갱신해야 한다.

SSL/TLSHTTPS인증서암호화정보보안