SSL/TLS — 정의, 프로토콜 및 암호화 작동 원리

SSL/TLS란?

SSL(Secure Sockets Layer)은 1995년 Netscape가 웹 트래픽을 보호하기 위해 개발한 프로토콜입니다. 첫 번째 버전인 SSL 1.0은 공개적으로 출시된 적이 없으며, SSL 2.0(1995)과 SSL 3.0(1996)은 2000년대 초까지 사용되었지만 심각한 취약점을 포함하고 있었습니다. SSL의 뒤를 이어 TLS(Transport Layer Security)가 등장했습니다. 이는 IETF가 표준화한 개선된 버전입니다. TLS 1.0(1999)은 SSL 3.0을 기반으로 했지만, 이후 버전인 TLS 1.1(2006), TLS 1.2(2008), TLS 1.3(2018)은 점차 원래 아키텍처에서 벗어나 새로운 암호화 알고리즘을 추가하고 취약점을 수정했습니다. 오늘날 SSL은 구식으로 간주되며 모든 최신 시스템은 TLS를 사용하지만, 두 프로토콜 모두 관성적으로 SSL/TLS로 함께 언급되는 경우가 많습니다.

프로토콜의 역사

SSL/TLS의 역사는 초기 웹에서 안전한 데이터 전송의 필요성에서 시작되었습니다. 1994년 Netscape는 Navigator 브라우저용 SSL 1.0을 개발했지만 심각한 보안 문제로 인해 공개되지 않았습니다. SSL 2.0은 1995년에 출시되어 실제로 사용되었지만 수많은 취약점을 포함하고 있었습니다: 중간자 공격에 대한 보호 부족, 취약한 암호화 알고리즘, 자르기 공격에 대한 취약성 등이 있습니다. SSL 3.0(1996)은 대부분의 문제를 해결했지만 2014년까지 POODLE 취약점이 발견되었고, 이후 IETF는 모든 SSL 버전을 공식적으로 구식으로 선언했습니다. TLS 1.0~1.3은 암호화 강도, 성능 및 개인정보 보호를 점진적으로 개선했으며, TLS 1.3은 핸드셰이크를 2회 왕복에서 1회로 줄여 불안정한 연결을 가진 모바일 애플리케이션에 매우 중요합니다.

SSL/TLS 핸드셰이크 작동 방식

핸드셰이크는 클라이언트와 서버 간의 보안 연결을 설정하는 프로세스입니다. 이는 여러 순차적 단계로 구성되며, 동안 양측이 프로토콜 버전에 동의하고, 암호화 알고리즘을 선택하고, 키를 교환하고, 서로를 인증합니다. TLS 1.3에서는 핸드셰이크가 단 한 번의 네트워크 왕복(1-RTT)만 필요하지만, TLS 1.2에서는 두 번(2-RTT)이 필요했습니다.

첫 번째 단계는 클라이언트가 ClientHello를 보내는 것입니다. 이는 지원되는 TLS 버전, 암호 제품군 및 난수 목록을 포함하는 메시지입니다. 서버는 선택된 버전과 암호, X.509 인증서 및 디지털 서명이 포함된 ServerHello로 응답합니다. 클라이언트는 인증 기관(CA) 체인을 통해 인증서를 확인하고, 세션 키를 생성하여 인증서의 서버 공개 키로 암호화하여 보냅니다. 서버의 확인 후 안전한 데이터 전송이 시작됩니다. 전체 핸드셰이크는 최신 기기에서 1~3밀리초가 소요되어 사용자가 인지할 수 없습니다.

X.509 인증서 및 신뢰 체인

TLS 인증의 기반은 X.509 형식의 인증서를 기반으로 구축된 공개 키 기반(PKI)입니다. 각 인증서에는 도메인 이름(Common Name 또는 Subject Alternative Name), 서버의 공개 키, 발급자 이름(인증 기관), 만료 날짜 및 CA의 디지털 서명이 포함됩니다. 클라이언트는 신뢰 체인을 따라 서버 인증서를 확인합니다: 서버 인증서에서 운영 체제에 내장된 루트 CA까지입니다. Android 기기에서는 루트 인증서가 시스템 키스토어에 저장되며 Google Play Services를 통해 업데이트됩니다. iOS에서는 iOS 업데이트를 통해 업데이트됩니다. 체인의 연결이 끊어지면(만료된 인증서, 도메인 불일치, 알 수 없는 CA) 클라이언트는 연결을 종료합니다. 자체 서명된 인증서(개발에 사용)의 경우 명시적 신뢰가 필요합니다. Android에서는 Network Security Config를 통해, iOS에서는 Info.plist의 NSExceptionDomains를 통해 이루어집니다. 인증서 체인 검증 프로세스에는 CRL(인증서 폐기 목록) 또는 OCSP(온라인 인증서 상태 프로토콜)를 통한 폐기 상태 확인도 포함되지만, 모바일 기기에서는 연결 속도를 높이기 위해 OCSP 요청이 생략되는 경우가 많습니다. 이는 아키텍트가 고려해야 할 보안과 성능 간의 절충점입니다.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()