Post

Everything about TLS

Posted Updated
By Hyoeun Choi
17 min read
Everything about TLS

Everything About TLS (Transport Layer Security)

SSL or TLS?

  • Secure Socket Layer (SSL) was developed by Netscape in the early 1990s to secure web communications.
  • It was later standardized by the Internet Engineering Task Force (IETF) and renamed to Transport Layer Security (TLS).
  • TLS 1.0 emerged after SSL 3.0, and has since evolved to TLS 1.3.
  • Many people still use the term “SSL,” but technically, TLS is the more accurate term.

Key Functions of TLS

TLS provides three core security functions:

  1. Authentication: Verifying that the communication partner is a trusted entity
  2. Encryption: Protecting data from being read by third parties
  3. Integrity: Ensuring data hasn’t been modified during transmission

TLS Handshake Process

TLS connections are established through a complex process called a “handshake.”

TLS 1.2 Handshake in Detail

  1. Client Hello: The client initiates the connection to the server, sending information about supported cipher suites and TLS versions.
  2. Server Hello: The server selects the strongest encryption algorithm from the client’s proposals and sends its certificate.
  3. Certificate Verification: The client verifies that the server’s certificate is signed by a trusted Certificate Authority (CA).
  4. Key Exchange: The client sends information encrypted with the server’s public key to generate a session key for symmetric encryption.
  5. Session Key Generation: Both sides generate the same session key based on the agreed information.
  6. Encrypted Communication: Once the handshake is complete, encrypted communication begins using the session key.

TLS 1.3 Handshake Improvements

  • TLS 1.3 reduced the handshake to 1-RTT (Round Trip Time).
  • It removed weak encryption algorithms and only supports safer algorithms.
  • It introduced 0-RTT resumption to reconnect more quickly with previously connected servers.

PKI (Public Key Infrastructure)

PKI is a set of policies, procedures, hardware, software, and people needed to create, manage, distribute, use, store, and revoke digital certificates.

Key Components of PKI

  1. Certificate Authority (CA): A trusted third party that issues and validates digital certificates.
  2. Registration Authority (RA): Verifies certificate requests on behalf of the CA.
  3. Certificate Repository: Stores issued certificates and lists of revoked certificates.
  4. Certificate Revocation List (CRL): List of certificates that have been revoked before their expiration date.
  5. Certificate Policy: Set of rules governing certificate issuance, use, and management.

Digital Certificate Components

Digital certificates following the X.509 standard include:

  • Certificate version
  • Serial number
  • Signature algorithm identifier
  • Issuer name
  • Validity period
  • Subject (owner) name
  • Subject’s public key information
  • Issuer unique identifier
  • Subject unique identifier
  • Extension fields
  • Digital signature of the certification authority

HTTPS (HTTP Secure)

HTTPS combines the HTTP protocol with TLS (or SSL).

HTTPS Characteristics

  • Encrypts all communication between web browsers and web servers.
  • URLs start with “https://” and are usually indicated by a lock icon in most browsers.
  • Uses port 443 by default (HTTP uses port 80).
  • Protects user personal information, login credentials, payment information, etc.

Implementing HTTPS

  1. Obtaining a Certificate: Purchase an SSL/TLS certificate from a trusted CA or obtain one through a free CA like Let’s Encrypt.
  2. Server Configuration: Install the certificate on your web server (Apache, Nginx, etc.) and enable HTTPS.
  3. Redirecting from HTTP to HTTPS: Configure all HTTP traffic to redirect to HTTPS.
  4. Implementing HSTS (HTTP Strict Transport Security): Force browsers to always connect to your site via HTTPS.

mTLS (Mutual TLS)

mTLS is a two-way authentication method where both client and server authenticate each other.

Regular TLS vs. mTLS

  • Regular TLS: The client only verifies the server’s identity (one-way authentication).
  • mTLS: Both client and server verify each other’s identity (two-way authentication).

mTLS Use Cases

  • Microservices architecture
  • API security
  • Zero-trust networks
  • IoT device communication
  • Financial transaction systems

Implementing mTLS

  1. Issue certificates to both client and server
  2. Enable client certificate verification in server configuration
  3. Install certificates and private keys in client applications
  4. Configure trusted CA lists

SSL Certificate Pinning

Certificate pinning is a security technique that restricts client applications to trust only specific certificates or public keys.

Purpose of Certificate Pinning

  • Prevent man-in-the-middle (MITM) attacks
  • Reduce risk from CA compromises
  • Provide an additional security layer for the trust chain

Implementing Certificate Pinning

In Mobile Apps

Android:

1
2
3
4
5
6
7
8
9
10
11

public class MyPinningTrustManager implements X509TrustManager {
    private static final String[] PINS = new String[] {
        "sha256/base64encodedpinhash="
    };
    
    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // Certificate chain validation and pin verification logic
    }
    // Other required methods...
}

iOS (Swift):

1
2
3
4
5

let serverTrustPolicy = ServerTrustPolicy.pinCertificates(
    certificates: serverCertificates,
    validateCertificateChain: true,
    validateHost: true
)

In Web Browsers (HPKP - HTTP Public Key Pinning)

1
2
3

Public-Key-Pins: pin-sha256="base64encodedpin="; 
                 pin-sha256="backupbase64encodedpin="; 
                 max-age=5184000; includeSubDomains
  • Note: HPKP is no longer supported in most browsers due to security risks and is being replaced by Expect-CT header and Certificate Transparency.

TLS Security Best Practices

Server-Side Best Practices

  1. Use the Latest TLS Version: TLS 1.2 or above (preferably TLS 1.3)
  2. Allow Only Secure Cipher Suites:
    1
2
3
4

    ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
  3. Support Perfect Forward Secrecy (PFS): Use ECDHE or DHE key exchange mechanisms
  4. Enable OCSP Stapling: Increase certificate status checking efficiency
  5. Use Strong DH Parameters: Minimum 2048-bit DH groups
  6. Implement HTTP Strict Transport Security (HSTS)

Client-Side Best Practices

  1. Thoroughly validate certificate validity
  2. Check Certificate Transparency (CT) logs
  3. Implement certificate pinning when necessary
  4. Use secure TLS libraries and keep them updated

TLS Vulnerabilities and Attacks

Major TLS Vulnerabilities

  1. BEAST (Browser Exploit Against SSL/TLS): Attack exploiting weaknesses in CBC mode
  2. POODLE (Padding Oracle On Downgraded Legacy Encryption): Padding vulnerability in SSL 3.0
  3. Heartbleed: Serious memory leak vulnerability in OpenSSL
  4. FREAK (Factoring RSA Export Keys): Attack forcing the use of weak “export-grade” encryption
  5. Logjam: Attack on weak Diffie-Hellman key exchange parameters
  6. DROWN (Decrypting RSA with Obsolete and Weakened eNcryption): Attack leveraging SSLv2 vulnerabilities

Defense Strategies

  1. Keep server and client software up to date
  2. Disable vulnerable protocols (SSLv3, TLS 1.0, TLS 1.1)
  3. Discontinue cipher suites with known vulnerabilities
  4. Regularly audit and test TLS configurations (using tools like SSL Labs)

References

TLS(Transport Layer Security)의 모든 것

SSL 혹은 TLS?

  • Secure Socket Layer(SSL)은 1990년대 초반 넷스케이프에서 웹 통신 보안을 위해 개발되었습니다.
  • 이후 IETF(Internet Engineering Task Force)에서 표준화 과정을 거쳐 Transport Layer Security(TLS)로 명명되었습니다.
  • SSL 3.0 이후 TLS 1.0이 등장했으며, 현재는 TLS 1.3까지 발전했습니다.
  • 많은 사람들이 여전히 “SSL”이라는 용어를 사용하지만, 기술적으로는 TLS가 정확한 명칭입니다.

TLS의 주요 기능

TLS는 다음 세 가지 핵심 보안 기능을 제공합니다:

  1. 인증(Authentication): 통신 상대방이 신뢰할 수 있는 상대인지 확인
  2. 암호화(Encryption): 데이터를 제3자가 읽을 수 없도록 보호
  3. 무결성(Integrity): 전송 중 데이터가 변조되지 않았음을 보장

TLS 핸드셰이크 과정

TLS 연결은 “핸드셰이크”라는 복잡한 과정을 통해 설정됩니다.

TLS 1.2 핸드셰이크 상세 과정

  1. Client Hello: 클라이언트가 서버에 연결을 시작하며 지원하는 암호화 알고리즘(cipher suites)과 TLS 버전 정보를 전송합니다.
  2. Server Hello: 서버는 클라이언트의 제안 중에서 가장 강력한 암호화 알고리즘을 선택하고 자신의 인증서를 전송합니다.
  3. 인증서 확인: 클라이언트는 서버의 인증서가 신뢰할 수 있는 인증 기관(CA)에 의해 서명되었는지 확인합니다.
  4. 키 교환: 클라이언트는 대칭 키 암호화에 사용할 세션 키를 생성하기 위한 정보를 서버의 공개 키로 암호화하여 전송합니다.
  5. 세션 키 생성: 양측은 합의된 정보를 바탕으로 동일한 세션 키를 생성합니다.
  6. 암호화 통신 시작: 핸드셰이크가 완료되면 세션 키를 사용한 암호화 통신이 시작됩니다.

TLS 1.3 핸드셰이크 개선사항

  • TLS 1.3은 핸드셰이크를 1-RTT(Round Trip Time)로 단축했습니다.
  • 약한 암호화 알고리즘을 제거하고 더 안전한 알고리즘만 지원합니다.
  • 0-RTT 재연결 기능을 통해 이전에 연결했던 서버와 더 빠르게 재연결할 수 있습니다.

PKI(Public Key Infrastructure)

PKI는 디지털 인증서를 생성, 관리, 배포, 사용, 저장 및 폐기하기 위한 정책, 절차, 하드웨어, 소프트웨어 및 사람들의 집합입니다.

PKI의 주요 구성 요소

  1. 인증 기관(Certificate Authority, CA): 디지털 인증서를 발급하고 인증하는 신뢰할 수 있는 제3자입니다.
  2. 등록 기관(Registration Authority, RA): CA를 대신하여 인증서 요청을 검증합니다.
  3. 인증서 저장소(Certificate Repository): 발급된 인증서와 해지된 인증서 목록을 저장합니다.
  4. 인증서 해지 목록(Certificate Revocation List, CRL): 유효기간이 만료되기 전에 해지된 인증서 목록입니다.
  5. 인증서 정책(Certificate Policy): 인증서 발급, 사용 및 관리에 관한 규칙 집합입니다.

디지털 인증서의 구성

X.509 표준을 따르는 디지털 인증서는 다음 정보를 포함합니다:

  • 인증서 버전
  • 일련번호
  • 서명 알고리즘 식별자
  • 발급자 이름
  • 유효 기간
  • 주체(소유자) 이름
  • 주체의 공개 키 정보
  • 발급자 고유 식별자
  • 주체 고유 식별자
  • 확장 필드
  • 인증 기관의 디지털 서명

HTTPS(HTTP Secure)

HTTPS는 HTTP 프로토콜에 TLS(또는 SSL)를 결합한 것입니다.

HTTPS의 특징

  • 웹 브라우저와 웹 서버 간의 모든 통신을 암호화합니다.
  • URL이 “https://”로 시작하며, 대부분의 브라우저에서 잠금 아이콘으로 표시됩니다.
  • 기본적으로 포트 443을 사용합니다(HTTP는 포트 80).
  • 사용자 개인정보, 로그인 자격 증명, 결제 정보 등을 보호합니다.

HTTPS 구현 방법

  1. 인증서 획득: 신뢰할 수 있는 CA로부터 SSL/TLS 인증서를 구매하거나 Let’s Encrypt와 같은 무료 CA를 통해 인증서를 발급받습니다.
  2. 서버 구성: 웹 서버(Apache, Nginx 등)에 인증서를 설치하고 HTTPS를 활성화합니다.
  3. HTTP에서 HTTPS로 리디렉션: 모든 HTTP 트래픽을 HTTPS로 리디렉션하도록 설정합니다.
  4. HSTS(HTTP Strict Transport Security) 구현: 브라우저가 항상 HTTPS를 통해 사이트에 연결하도록 강제합니다.

mTLS(Mutual TLS)

mTLS는 클라이언트와 서버 모두가 서로를 인증하는 양방향 인증 방식입니다.

일반 TLS vs mTLS

  • 일반 TLS: 클라이언트가 서버의 신원만 확인합니다(단방향 인증).
  • mTLS: 클라이언트와 서버가 모두 상대방의 신원을 확인합니다(양방향 인증).

mTLS의 사용 사례

  • 마이크로서비스 아키텍처
  • API 보안
  • 제로 트러스트 네트워크
  • IoT 장치 통신
  • 금융 거래 시스템

mTLS 구현 방법

  1. 클라이언트와 서버 모두에 인증서 발급
  2. 서버 구성에서 클라이언트 인증서 확인 활성화
  3. 클라이언트 애플리케이션에 인증서 및 개인 키 설치
  4. 신뢰할 수 있는 CA 목록 구성

SSL Certificate Pinning

인증서 핀닝은 클라이언트 애플리케이션이 특정 인증서나 공개 키만 신뢰하도록 하는 보안 기법입니다.

인증서 핀닝의 목적

  • 중간자 공격(MITM) 방지
  • CA 손상 위험 감소
  • 신뢰 체인에 대한 추가 보안 계층 제공

인증서 핀닝 구현 방법

모바일 앱에서의 구현

Android:

1
2
3
4
5
6
7
8
9
10
11

public class MyPinningTrustManager implements X509TrustManager {
    private static final String[] PINS = new String[] {
        "sha256/base64encodedpinhash="
    };
    
    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        // 인증서 체인 검증 및 핀 확인 로직
    }
    // 기타 필요한 메서드들...
}

iOS (Swift):

1
2
3
4
5

let serverTrustPolicy = ServerTrustPolicy.pinCertificates(
    certificates: serverCertificates,
    validateCertificateChain: true,
    validateHost: true
)

웹 브라우저에서의 구현 (HPKP - HTTP Public Key Pinning)

1
2
3

Public-Key-Pins: pin-sha256="base64encodedpin="; 
                 pin-sha256="backupbase64encodedpin="; 
                 max-age=5184000; includeSubDomains
  • 참고: HPKP는 보안 위험으로 인해 대부분의 브라우저에서 더 이상 지원되지 않으며, Expect-CT 헤더와 Certificate Transparency로 대체되고 있습니다.

TLS 보안 모범 사례

서버 측 모범 사례

  1. 최신 TLS 버전 사용: TLS 1.2 이상 사용 (가능하면 TLS 1.3)
  2. 안전한 암호 제품군만 허용:
    1
2
3
4

    ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
  3. Perfect Forward Secrecy(PFS) 지원: ECDHE 또는 DHE 키 교환 메커니즘 사용
  4. OCSP Stapling 활성화: 인증서 상태 확인 효율성 증가
  5. 강력한 DH 매개변수 사용: 최소 2048비트 DH 그룹 사용
  6. HTTP Strict Transport Security(HSTS) 구현

클라이언트 측 모범 사례

  1. 인증서 유효성 철저히 검증
  2. 인증서 투명성(CT) 로그 확인
  3. 필요한 경우 인증서 핀닝 구현
  4. 안전한 TLS 라이브러리 사용 및 최신 상태 유지

TLS 취약점 및 공격

주요 TLS 취약점

  1. BEAST (Browser Exploit Against SSL/TLS): CBC 모드의 약점을 이용한 공격
  2. POODLE (Padding Oracle On Downgraded Legacy Encryption): SSL 3.0의 패딩 취약점
  3. Heartbleed: OpenSSL의 심각한 메모리 누수 취약점
  4. FREAK (Factoring RSA Export Keys): 약한 “수출용” 암호화 강제 사용 공격
  5. Logjam: 약한 Diffie-Hellman 키 교환 매개변수 공격
  6. DROWN (Decrypting RSA with Obsolete and Weakened eNcryption): SSLv2 취약점을 이용한 공격

방어 전략

  1. 서버와 클라이언트 소프트웨어를 최신 상태로 유지
  2. 취약한 프로토콜(SSLv3, TLS 1.0, TLS 1.1) 비활성화
  3. 알려진 취약점이 있는 암호 제품군 사용 중지
  4. TLS 구성을 정기적으로 감사 및 테스트 (SSL Labs 등의 도구 활용)

참고 자료

Cybersecurity, Network Security
TLS
This post is licensed under CC BY 4.0 by the author.