[TLS v1.3] 2. TLS v1.3 의 장점은 무엇일까? – 2) 보안성향상

2. 보안성 향상

TLS v1.3 의 또 다른 장점은 보안성 향상입니다.

이번 글에서 이야기 할 TLS v1.3 의 보안성 향상은 크게 3가지로, 기밀성 강화, 취약 항목 제거, 보안 기능 추가의 관점입니다.

1) 기밀성 강화 – Handshake 과정 암호화

TLS v1.2 보다 TLS v1.3 의 Handshake 과정이 단축된 점은 앞의 글에서 설명하였습니다. 이와 더불어 TLS v1.3 에서는 Handshake 과정 부터 암호화를 수행하여, 연결 과정에서 노출될 수 있는 중요 정보를 보호합니다.

       Client                                               Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*         -------->
                                                       ServerHello  ^ Key
                                                      + key_share*  | Exch
                                                 + pre_shared_key*  v
                                             {EncryptedExtensions}  ^  Server
                                             {CertificateRequest*}  v  Params
                                                    {Certificate*}  ^
                                              {CertificateVerify*}  | Auth
                                                        {Finished}  v
                                 <--------     [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}                -------->
       [Application Data]        <------->      [Application Data]

[표] 1. TLS v1.3 Handshake 세부 과정(출처: https://tools.ietf.org/html/rfc5246#section-7)

위는 TLS v1.3 의 표준 Draft 문서에서 확인 할 수 있는 Handshake 의 세부 과정입니다. 각 단계에서 Client/Server 가 전달하는 패킷에 포함되는 데이터를 기술하고 있는데 있습니다. 이중 암호화 된 부분은 {} 와 [] 안의 데이터입니다.

  – {} 안의 데이터 : Handshake 전송 키에 의해 암호화가 수행된 데이터

  – [] 안의 데이터 : Application 전송 키에 의해 암호화가 수행된 데이터

[그림] 1. TLS v1.3 Handshake 과정 중 암호화
실제 Handshake 과정의 패킷을 확인 하였을 때에도, Server Hello 과정에서부터 일부 데이터가 암호화 된 것을 확인 할 수 있습니다.

[그림] 2. TLS v1.2 Handshake 수행 중 암호화 미수행
위의 TLS v1.3 의 Server Hello 과정과 동일한 과정의 패킷을 TLS v1.2 에서 확인하면 [그림] 2 와 같습니다.

TLS v1.2 에서는 Handshake 과정 중 암호화가 수행되지 않아, TLS v1.3 에서는 확인할 수 없었던 인증서 정보 등이 패킷을 통해 노출된 것을 볼 수 있습니다.

Handshake 과정이 암호화가 된 경우에는 공격자가 중간에 패킷을 탈취하여 Client/Server 의 인증서 및 주요 정보를 확인하는 것을 방지할 수 있고, Handshake 과정을 변조함으로써 발생할 수 있는 추가 공격을 예방할 수 있습니다.

 

2) 취약 항목 제거

발표되고 사용되는 알고리즘 중 심각한 취약점들이 발표되어 더 이상 사용하면 안되는 알고리즘들이 있습니다. 대표적인 것이 Hash 알고리즘의 하나인 MD5 입니다. 하지만 TLS v1.2 부터 이전 버전들은 아직 취약한 알고리즘들을 지원하고 있고, Default 로 비활성화 되어 있지 설정 변경을 통해 사용하는 것이 가능했습니다.

취약한 사항을 사용하지 않으나, 지원을 하는 것과 애초에 지원을 하지 않는 것은 매우 다른 관점인 듯 합니다. 전자는 기본 룰에 따를 경우에 안전하게 사용 가능하지만, 언제든 설정 변경이 가능하기 때문에 위험을 안고 가는 것과 같습니다. 후자의 경우에는 사용자에게 선택권을 주지 않음으로써 보안을 강화하는 효과가 있습니다.

TLS v1.3 의 경우에도 후자의 방향으로 취약한 보안 사항들을 미지원하는 방향으로 발표되었습니다. 제거되는 주요 사항은 아래와 같습니다.

알고리즘과 기능들은 취약점이 지속적으로 발표되고, 위험이 높기 때문에 제거가 결정된 듯 합니다. 아래에는 주요 취약점 및 공격 방법을 함께 정리하였습니다.

 

– 키 교환 알고리즘(Key Exhange)

  • RSA
    • ROCA(CVE-2017-15361) : 특정 소프트웨어 라이브러리를 사용해 개인키/공개키 쌍을 생성 시 공개키를 통해 개인키를 알아낼 수 있는 취약점 (참고 : https://en.wikipedia.org/wiki/ROCA_vulnerability)
    • ROBOT(Return Of Bleichenbacher’s Oracle Threat) Attack : 서버 측 오류 메시지를 통해 개인키를 알아낼 수 있는 공격 ( 참고 : https://robotattack.org/)

 

– 암호화 알고리즘(Encryption algorithms)

  • RC4 (참고 : https://en.wikipediaㅎ.org/wiki/RC4#Security)
    • NOMORE Attack : 암호화된 TLS 패킷을 해독할 수 있는 공격 기법
    • Bar-mitzvah : 취약한 키를 사용하여 암호화한 패킷을 해독할 수 있는 공격 기법
  • 3DES
    • Sweet32 : 64bit 의 블록 암호화 중 CBC 모드를 사용할 경우 collision 이 발생할 수 있어, Birthday 공격을 통해 암호문을 복호화할 수 있는 공격 (참고 : https://sweet32.info/)
  • Camellia
    • CRIME(CVE-2012-4929) : SSL/TLS 통신 과정 중 데이터 압축을 수행하는 경우, 변조된 요청을 보내고 압축된 데이터의 길이 변화를 관찰함으로써 암호화된 쿠키값을 복호화할 수 있는 공격. 쿠키값 내 세션정보를 이용하여, 세션하이재킹을 수행 (참고 : https://en.wikipedia.org/wiki/CRIME)

 

– 일방향 해쉬 알고리즘(Cryptographic Hash algorithms)

  • MD5 & SHA-1
    • SHAttered : 구글이 발표한 해쉬 충돌. 동일한 SHA-1 해쉬 값을 가지고 있으나 다른 내용의 PDF 생성이 가능함을 시연 (참고 : https://shattered.io/)
    • SLOTH(CVE-2015-7575) : TLSv1.2 통신 중 강제로 MD5 알고리즘을 사용하도록 다운그레이드 할 수 있는 공격(참고 : https://access.redhat.com/articles/2112261)

 

– Cihper Modes

 

– 그 외 제거 사항

 

3) 보안 기능 변경

보안성 강화를 위해 1) 기밀성 강화와 2) 취약 항목 제거 이외에 용어 및 기술을 새롭게 정리하고, 기능들을 강화하는 방식으로 여러 가지 작업이 수행되었습니다.

 

– Cipher Suites 재정의 : Cipher Suites 를 정의하는 요소 간략화와 지원 Cipher Suites 축소

  • Cipher Suites 표기 방식 변경
    • 기존의 Cipher Suites 표기 방식 : [프로토콜] + [키교환 알고리즘] + [인증 알고리즘] + [AEAD Cipher 모드] + [PRF 해시 알고리즘]
      • 예시) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    •  TLS v1.3 Cipher Suites 표기 방식 : [프로토콜] + [AEAD Cipher Mode] + [HKDF 해시 알고리즘]
      • 예시) TLS_AES_128_GCM_SHA256
  • 지원 Cipher Suites 축소
    • TLS v1.1 이하 버전의 지원 Cipher Suites : 319개
    • TLS v1.2 지원 Cipher Suites : 37개
    • TLS v1.3 지원 Cipher Suites : 5개
      • TLS_AES_128_GCM_SHA256
      • TLS_AES_256_GCM_SHA384
      • TLS_CHACHA20_POLY1305_SHA256
      • TLS_AES_128_CCM_SHA256
      • TLS_AES_128_CCM_8_SHA256

 

– HKDF를 이용한 키 생성

  • HKDF : HMAC-based Extract-and-Expand Key Derivation Function (참고 : https://tools.ietf.org/html/rfc5869)
    • 기존 PRF 알고리즘을 이용하여 생성되던 키를 HMAC 알고리즘을 통해 캡슐화
    • PRF 구성 요소 중 일부를 HMAC 알고리즘으로 해쉬값으로 생성하고, 기존의 PRF 키와 해쉬값을 합쳐 키를 생성
    • 키에 포함된 해쉬값을 통해 키의 무결성 검증 가능
  • HMAC 알고리즘은 TLS v1.3 에서 명시한 알고리즘 중 사용 : SHA256 혹은 SHA384

 

– PSK 공유

  • PSKPre-Shared Key : 동일한 클라이언트와 서버가 연결을 재수행할 때 사용하기 위해 미리 공유한 키
    • 동일한 연결을 수행 시, 데이터를 바로 전달하는 방식의 0-RTT 를 가능하게 함
    • Full handshake 과정에서 발생하는 비용을 경감

 

–  호환성Compatibiltiy 제공 시 다운그레이드downgrade 공격 보호

다운그레이드 공격은 공격자가 네트워크 스푸핑Spoofing 등을 통해 클라이언트와 서버 사이의 중간자 역할MITM을 수행할 때, 취약한 SSL/TLS 버전이 통신에 사용되도록 패킷을 조작하는 공격 방법입니다.

보통은 SSL v3로 다운그레이드를 많이 수행하는데, 공격이 성공 후 SSL v3가 가지고 있는 취약점을 이용해 추가 공격을 수행한 후 서버의 개인키 등을 복호화 할 수 있기 때문입니다.

다운그레이드 공격은 공격자가 MITMMan-in-the-Middle 공격을 성공한 후, 클라이언트와 서버가 제공하는 SSL/TLS 버전과 상관없이 일어날 수 있습니다. 이 때 TLS v1.3 과 이전 버전의 가장 큰 차이점은 다운그레이드 공격의 탐지 여부입니다.

TLS v1.2 과 그 이전 버전에서는 다운그레이드 여부를 확인할 수 있는 방법이 없었습니다. TLS v1.3에서는 랜덤한 값을 삽입하고, 버전 협의Negotiation 과정에 따라 랜덤한 값 중 일부를 수정하고 패킷 내 포함된 MAC 값을 이용하여 무결성 검증을 수행하는 것으로 다운그레이드를 방지할 수 있습니다.

 

TLS v1.3이 제공하는 여러 기능 및 정의 사항 중 장점이 될 수 있는 사항 위주로 정리해보았습니다. 크게 가용성과 보안성 향상의 관점에서 v1.3의 업데이트 작업을 정리할 수 있었습니다.

 

TLS v1.3 포스팅 시리즈

[TLS v1.3] 1. 들어가기 전, HTTPS 와 TLS 는 무엇인가?

[TLS v1.3] 2. TLS v1.3 의 장점은 무엇일까? – 1) 연결속도향상

[TLS v1.3] 2. TLS v1.3 의 장점은 무엇일까? – 2) 보안성향상

Leave a Reply

avatar
  Subscribe  
Notify of