HTTPS - 3. SSL/TLS History and Security

그림으로 살펴보는 포스팅을 시작으로, 3편의 포스팅을 통해 HTTPS에 대해서 알아보겠습니다.

이전 포스팅을 읽어보시지 않으셨다면, 읽어보시는 것을 추천드립니다!

• HTTPS - 1. 그림으로 살펴보는 HTTPS

• HTTPS - 2. HTTPS의 Ciphersuite, Handshake, Key derivation

• HTTPS - 3. SSL/TLS History and Security

들어가며

이번 글에서는 SSL 2.0 ~ TLS 1.3까지의 변화를 간략하게 살펴봅시다!

History & Security

SSL 규약은 처음에 Netscape가 개발하여 2.0버전부터 공식 릴리즈되었습니다. 이후 SSL 2.0의 보안문제들을 개선한 SSL 3.0가 릴리즈되고, TLS  3.0을 기반으로 TLS 1.0이 개발되었습니다.

현재는 TLS 1.2가 가장 많이 사용되고 있으며, 이는 2008년 8월에 표준으로 정의된 것으로 10년정도 되었습니다.

TLS 1.3 규약은 2018년 3월 21일에 무려 28번의 draft를 거치고 최종 확정되었으며, Cloudflare를 비롯해 몇몇 벤더에서는 이미 사용중입니다.

자, 이제 SSL/TLS 각 버전에서 어떤 문제점들이 있었고 어떻게 개선되었는지 알아봅시다.

(위키피디아의 내용을 많이 참조하였습니다.)

SSL 2.0

SSL 2.0은 1995년 2월에 릴리즈되었으며, 2011년 RFC 6176에서 금지되었습니다.

SSL 2.0에서는 여러 문제점들이 있었습니다.

• 메시지 인증에서 사용되는 key과 암호화에 사용되는 key가 동일했습니다.
  → shared secret에서 각 key를 유도(derivation)해서 사용해야 합니다.
• 메시지 인증에 사용되는 MAC이 "MD5(secret prefix + data)" 형태로 생성되어, length extension attack에 취약했습니다.
• handshake시에 방어책이 없어, 중간자에 의한 downgrade attack을 탐지하지 못했습니다.(SSL 3.0에서 explicit closure alert를 이용해 방지)
• TCP 연결 close를 이용해 데이터의 끝을 나타냈기 때문에, 공격자가 TCP FIN을 보냄으로써 truncation attack이 가능했습니다.

SSL 3.0

SSL 3.0은 1996년에 릴리즈되었으며, 2015년 6월에 RFC 7568에서 금지되었습니다.

• 개선된 점
  • SHA-1 기반 암호화를 추가하고 인증서 인증을 지원합니다.
• 문제 점
  • 안전하지 않은 key 유도 과정. master key의 반쪽은 MD5 해쉬함수에 의존하여, 해쉬 충돌(collision)에 안전하지 않습니다.
  • 2014년 발표된 POODLE Attack, RC4
    • SSL 3.0의 Block 암호화 방식의 디자인 결함(Encrypt-and-MAC, padding 무결성 미검증)으로 padding attack에 취약(POODLE attack).
    • RC4

TLS 1.0

TLS 1.0은 SSL 3.0의 업그레이드 버전으로, 1999년 1월 RFC 2246에 정의되었습니다.
PCI Council에서는 2018년 6월 30일 이전에 TLS 1.0에서 TLS 1.1이상의 버전으로 업그레이드 할 것을 제안했습니다.
(PCI DSS 영향을 받는 서비스들은 2018.06.30 이전까지 TLS 1.1 이상(권장 TLS 1.2)의 버전으로 업그레이드 해야 합니다.)

• 개선된 점
  • 시퀀스 번호를 사용해 어플리케이션 레코드들을 넘버링하고, 이 시퀀스 번호를 MAC(메시지 인증코드)에서 사용.
  • 메시지 인증에 HMAC을 사용.(SSL 3.0에서는 다른 해쉬기반의 MAC을 사용했음) → Length extension attack에 안전.
• 문제점
  • TLS 1.0은 SSL 3.0으로 다운 그레이드 할 수 있는 방법이 있었기에, 보안성을 약화시킬 수 있었음

TLS 1.1

TLS 1.1은 2006년 4월 RFC 4346에 정의되었습니다. 

큰 차이점들을 보면,

• CBC 모드 공격에 대한 방어를 추가
  • implicit IV를 explicit IV로 변경(BEAST Attack 방어)
  • 패딩 에러를 처리하는 방법을 변경
• 매개변수들의 IANA 등록 지원

TLS 1.2

TLS 1.2는 2008년 8월 RFC 5246에 정의되었습니다.

큰 차이점들은 봅시다.

• key를 유도할 때 사용되는 PRF(Pseudo Random Function)함수가 TLS 1.1에서는 MD5와 SHA-1 모두 사용(MD5-SHA-1)했지만, TLS 1.2에서는 SHA-256만을 사용.(옵션으로 SHA-256 보다 강한 방식도 선택 가능). TLS 1.1 PRF는 이쪽, TLS 1.2 PRF는 이쪽에서 자세하게 확인 가능.
• Finish 메시지에서도 hash값을 생성할 때 MD5-SHA-1 방식에서 SHA-256 방식으로 변경.(사이즈는 여전히 96bits)
• Authenticated encryption cipher 지원. 주로 AES GCM, CCM mode가 많이 사용됨.

2011년 3월, RFC 6176에서 모든 TLS 버전은 SSL과의 호환성을 제거하도록 재정의 됨.

TLS 1.2 vs 1.3

TLS 1.3의 큰 특징 두 가지는 "강화된 보안"과 "향상된 속도"입니다.

강화된 보안

TLS 1.3에서는 안전하지 않은 암호화 방식들을 과감하게 지원하지 않습니다.

• RSA key transport — Doesn’t provide forward secrecy
• CBC mode ciphers — Responsible for BEAST, and Lucky 13
• RC4 stream cipher — Not secure for use in HTTPS
• SHA-1 hash function — Deprecated in favor of SHA-2
• Arbitrary Diffie-Hellman groups — CVE-2016-0701
• Export ciphers — Responsible for FREAK and LogJa

이외에도, Perfect Forward Secrecy를 지원하는 키 교환방식만을 허용하거나 AEAD 암호화만 허용하는 등의 개선도 있습니다.
이쪽에서 추가적으로 더 확인하실 수 있습니다.

향상된 속도

Handshake 과정이 2-RTT에서 1-RTT로 변경되어 지연(latency)가 줄어들었습니다.

추가적으로, TLS 1.3에서는 이전에 handshake했던 두 대의 컴퓨터가 서로의 정보를 저장한 뒤,
향후 연결에 이전 키를 사용하는 것을 허용하는 0-RTT Resumption을 지원합니다.

출처 : https://en.wikipedia.org/wiki/Cipher_suite#TLS_1.0%E2%80%931.2_handshake

마치며

SSL/TLS 버전별 개선점에 대한 내용을 마지막으로 이번 시리즈를 마칩니다!

읽어주셔서 감사합니다.

Reference

• Wikipedia : Transport Layer Security
  https://en.wikipedia.org/wiki/Transport_Layer_Security
• Introducing TLS 1.3
  https://blog.cloudflare.com/introducing-tls-1-3/
• Cipher suite
  https://en.wikipedia.org/wiki/Cipher_suite#TLS_1.0%E2%80%931.2_handshake