SSL이 90년대 후반에 TLS로 이름이 변경된 이유

 (tim.dierks.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1990년대 중반 브라우저 전쟁 속에서 Netscape의 SSL과 Microsoft의 PCT가 갈라질 가능성이 커지자, 업계는 이를 하나의 공개 표준으로 묶으려 했음
  • 초기 SSL은 결함으로 출시되지 못했고, 첫 실사용 버전인 SSL 2도 몇 년간 쓰였지만 암호학적·실용적 한계를 안고 있었음
  • Microsoft의 PCT는 SSL 2를 바탕으로 IE와 IIS에 맞춘 자체 확장이었고, Netscape는 표준 주도권을 잃지 않기 위해 SSL 3.0으로 대응함
  • Netscape와 Microsoft는 IETF의 공개 표준화 절차에 합의했지만, IETF가 Netscape 프로토콜을 그대로 추인하는 모양은 피해야 했음
  • 결국 SSL 3.0에는 일부 변경이 들어가고 이름도 바뀌었으며, TLS 1.0은 사실상 SSL 3.1에 가까운 형태로 출발함

브라우저 전쟁 속 SSL과 PCT

  • 1990년대 중반 Netscape와 Microsoft의 브라우저 경쟁은 보안 프로토콜 표준화에도 영향을 줌
  • Netscape는 SSL 프로토콜을 개발함
    • 초기 버전은 암호학적 결함으로 빠르게 깨졌고 출시되지 않음
    • 첫 프로덕션 버전은 SSL 2였으며 몇 년간 사용됨
    • SSL 2에는 암호학적·실용적 결함이 있었지만, 즉시 교체해야 할 정도로 극적인 위기는 아니었음
  • Microsoft는 SSL 2를 수정하고 자체 추가사항을 넣어 PCT를 정의함
    • PCT는 SSL 2에서 파생된 프로토콜임
    • 지원 범위는 IE와 IIS에 한정됨
  • Netscape도 SSL 2의 문제를 고치려 했지만, Microsoft가 표준의 리더십이나 소유권을 가져가는 상황은 원하지 않았음
    • 그 결과 더 큰 변경을 담은 SSL 3.0을 개발함

IETF 표준화와 TLS라는 이름

  • 업계와 커뮤니티의 여러 사람들은 프로토콜이 포크되는 상황을 피하려 함
  • Consensus Development는 Netscape와 Microsoft 대표들이 만나는 회의를 주최함
    • Tim Dierks는 당시 Christopher Allen과 함께 Consensus Development에서 일함
    • 그는 Netscape 계약으로 SSL 3.0 참조 구현을 작성함
    • 회의에는 Bruce Schneier가 참석했고, SSL 3 프로토콜을 설계한 Paul Kocher도 아마 참석했으며, Microsoft는 Barbara Fox가 대표함
  • 협상 결과 Microsoft와 Netscape는 IETF가 프로토콜을 넘겨받아 공개 절차로 표준화하는 데 동의함
    • 이 과정은 Tim Dierks가 RFC를 편집하는 결과로 이어짐
  • 표준화 과정에서 SSL 3.0에는 일부 변경이 들어감
    • IETF가 Netscape의 프로토콜을 단순히 추인하는 것처럼 보이지 않게 하려는 목적이 있었음
    • 같은 이유로 프로토콜 이름도 바뀜
  • 이렇게 탄생한 TLS 1.0은 실제로는 SSL 3.1에 가까운 버전이었음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 버전 번호가 프로토콜 차이를 잘 드러내지 않아서 더 헷갈림
    SSLv2는 널리 배포된 첫 SSL이지만 문제가 많았고, SSLv3는 거의 새 프로토콜이었음
    TLS 1.0은 SSLv3와 비슷하지만 IETF 표준화 과정에서 약간 고쳤고, TLS 1.1은 블록 암호 사용 방식 문제를 고친 아주 작은 개정판임
    TLS 1.2는 MD5와 SHA-1 약점에 대응해 새 해시와 AES-GCM 같은 AEAD 암호군을 추가한 중간 규모 개정이고, TLS 1.3은 TLS 1.2 이전 요소를 일부 재사용하지만 대부분 새 프로토콜에 가까움
    이 프로토콜들은 모두 버전을 자동 협상할 수 있게 설계되어, 클라이언트와 서버가 연결성을 잃지 않고 독립적으로 업그레이드할 수 있었음

    • TLS 1.0은 “확장” 개념으로 모듈성을 도입했으니 사소한 진화라고 보기 어려움
      그중 하나가 서버 간 동기화된 상태 저장 없이 서버 측 세션 재개를 가능하게 한 세션 티켓이고, 또 하나가 서버가 둘 이상의 인증서를 쓸 수 있게 한 Server Name Indication임
    • 자동 버전 협상은 수십 년간 여러 다운그레이드 공격도 가능하게 만들었음
    • TLS 1.0이 아니라 그냥 TLS v4.0이라고 불렀어야 했음
      이후 버전을 v1.1, v1.2, v1.3으로 만든 건 버전 번호를 리셋한 게 객관적으로 틀렸다는 걸 인정하지 않으려는 고집처럼도 보임
    • 그래도 최소한 연도 번호로 버전 붙이진 않았음

  • 당시 Microsoft는 완전히 다른 짐승이었으니, SSL/TLS 명칭 혼란이 그렇게 이상하게 느껴지진 않음
    그 시절의 M$는 모든 걸 장악하려 했고, 오픈 소스 인터넷 기술을 늦추려는 시도를 2010년대 초까지도 멈추지 않았다고 봄
    Java Applet을 죽이는 데 성공했고, JavaScript와 CSS 전반도 여러 해 뒤처지게 만들었다고 생각함
    2000년대 초 회사에서 IE의 최신 “기술”을 지원하라고 압박했지만, 핵심 JS 버그가 고쳐지자 곧바로 Mozilla 3.0을 지원하기 시작했고, 나중에 Fortune 500 회사가 내부 앱에서 Mozilla/Firefox를 일반화되기 훨씬 전부터 쓰게 되면서 좋은 결정이 됨

    • Java Applet을 죽인 건 Microsoft가 아니라고 봄
      IE에서는 항상 동작했고, 그게 Microsoft가 영향을 줄 수 있는 거의 유일한 경로였음
      Applet은 “Java는 느리다”의 대표 사례가 되면서 실패했는데, 일반적으로는 꼭 맞는 말이 아니어도 Applet에는 다운로드 대기와 JVM 시작 대기 때문에 맞는 말이었음
      결국 HTML/JS가 예전엔 Applet이 필요하던 동적 기능을 더 잘하게 됐고, HTML로 부족한 나머지 영역은 Flash가 가져가면서 사라짐
    • Applet은 여러 이유로 죽었음
      사소한 애니메이션 하나에도 JRE 시작 시간이 말도 안 되게 길었고, 당시 기준으로 메모리 요구량과 충돌도 심했으며, Java 플랫폼 초기 릴리스의 호환성 문제도 이상했음
      CA 인증서를 받을 수 있는 행위자는 선할 것이라는 가정에 기반한 보안 모델도 우스웠고, IE뿐 아니라 브라우저 전반의 샌드박스 기술도 미성숙했음
    • “M$”라는 별명은 요즘이 더 어울린다고 봄
    • Microsoft는 홍보 부서가 좋아진 것 말고는 그렇게 많이 변하지 않았음
    • Amazon에는 https://github.com/aws/s2n-tls도 있었음
      s2n에는 기대가 컸지만, AWS 밖에서는 크게 자리 잡지 못한 것처럼 보임

  • TLS와 SSL을 강하게 구분하는 사람은 그 차이를 알고 있고 상대도 알아야 한다고 보는 셈이지만, 실무적으로는 .doc와 .docx 차이와 비슷함
    근본적으로 다르지만 일반 사용자에게는 상호 교환적으로 보이고, 현장에서는 대체로 HTTPS가 동작하는지에 관심이 있을 뿐 내부 동작에는 크게 신경 쓰지 않음

    • 일반 사용자에게 TLSv1.0이 SSLv2/SSLv3보다 새롭고 더 낫다고 설명하는 게 주된 어려움이었음
      숫자가 더 크면 더 좋다고 생각하는 사람들과 꽤 많이 논의했던 기억이 있음
    • SSL이 폐기된 지 오래됐는데도 사람들은 여전히 암호화된 네트워크 트래픽을 뜻하는 이름으로 SSL을 씀
      현대적인 암호화 네트워크 트래픽은 모두 TLS라고 부르고, 진짜 레거시 시스템 때문에 SSL을 쓸 때만 SSL이라고 하면 훨씬 쉬울 것임

  • 방금 내 머리가 무의식적으로 SSL과 TLS를 구분하기 어려워했다는 걸 깨달음
    20년이 지나서야 왜 그랬는지 알게 됨

    • 나도 마찬가지임
      이 업계 15년 만에야 ssl과 tls가 같은 거라는 걸 제대로 깨달아서 바보가 된 느낌임
    • 2010년쯤 알게 됐지만 그전엔 나도 몰랐음
      계기는 Java에서 오늘날 TLSv1.3을 쓰더라도 암호화 연결을 시작할 때 여전히 SSLSocket을 쓴다는 점이었음

  • “Transport Layer Security”가 이름으로는 더 낫긴 함
    “TLS”라고 말하는 것도 좋고, S가 두 번 이어지는 SSL은 뱀처럼 들림

    • 문제는 TLS가 이미 thread local storage의 약자로 널리 쓰이고 있었다는 점임
      Transport Layer Security는 1999년에 시작된 것으로 널리 문서화되어 있고, “Thread Local Storage”는 적어도 1996년까지 거슬러 올라가는 자료가 있음
      당시에는 Microsoft 쪽, 어쩌면 IBM/OS/2 쪽에서 더 흔한 용어였고, Pthreads와 Unix 전반에서는 “thread-specific data”라고 부르는 경향이 있었음
      2001년 Itanium ABI 문서가 더 넓은 Unix 세계에 이 용어를 퍼뜨렸을 수도 있지만, Sun도 Solaris와 Java 쪽에서 이전부터 이 용어를 썼던 듯함
    • 오히려 SSL이 더 잘 맞는 이름이라고 봄
      이론상 TLS는 IPSec처럼 임의의 프로토콜을 위에 얹을 수 있는 전송 계층 보안 메커니즘일 수 있지만, 실제로는 거의 TCP 소켓에 묶여 있음
      UDP 변형인 DTLS나 QUIC도 TLS 명세의 일부는 아니고, Linux의 커널 TLS나 Windows의 비슷한 인프라도 있지만 소켓 플래그 하나로 TLS를 켜는 수준으로 쉽진 않음
    • “SSL”은 세 글자 사이에서 혀 위치가 거의 안 바뀌어서 “TLS”보다 발음하기 쉬움
    • 가장 좋은 이름은 처음 나와서 굳어진 이름임

  • 누군가에게 웹사이트에 안전하게 접속해야 한다고 말할 때, 또는 TLS/SSL이라는 용어를 쓸 만한 상황에서 보통 무엇이라고 말하는지 궁금함

    1. SSL이라고 하는지 TLS라고 하는지
    2. 나이가 어떻게 되는지, 또는 1999년 이전부터 일했는지
    • 보통 SSL이라고 말함
      오랫동안 TLS가 “같은 것”인지도 몰랐고, 이제 알아도 10번 중 9번은 여전히 SSL이라고 함
      38세이고 2011년에 일을 시작했지만, 네트워크 프로그래밍은 2004~2005년쯤 처음 해봤음
      방금 다른 화면을 보니 몇 분 전에 if 문을 추가한 함수도 sslCertNotBefore라는 이름을 쓰고 있었음
      프로그래머가 보통 TLS를 직접 다루지 않는다는 점도 문제의 일부 같음
      HTTPS 연결에서 자세한 인증서 정보를 추출하는 시스템을 만들었는데, Java 표준 라이브러리에서 필요한 정보를 끌어내는 일이 꽤 고생스러웠음
      자동으로 보이지 않게 처리되면 실수하기는 어렵지만, TLS가 실제로 어떻게 동작하는지에 대한 깊은 이해가 퍼지는 데는 블랙박스화가 별로 도움이 되지 않음
    • 대부분이 SSL이라고 부르는 이유는 보안 통신을 다루는 라이브러리 이름에 SSL이 들어가기 때문인 듯함
      가장 지배적인 OpenSSL을 비롯해 BoringSSL, LibreSSL, wolfSSL 등이 있음
      TLS가 이름에 들어간 라이브러리로는 GnuTLS, mbedTLS, s2n-tls, RustTLS가 있지만 상대적으로 덜 쓰임
    • 보통 SSL이라고 말함
      더 정확한 TLS보다 이해될 가능성이 높고, 실제 SSL 3.0을 쓰는 사람은 이제 없기 때문임
      OpenSSL 같은 고전적인 라이브러리 이름에도 SSL이 들어감
      다만 1990년대 암호 전쟁 시절에 SSL을 배웠고, 제대로 된 SSL 암호화를 쓰려면 “US only” Netscape 버전을 구해야 했던 시절의 습관일 수도 있음
    • 보통 “https”라고 말함
      일반인도 그 뜻을 아는 경우가 있기 때문임
    • 요즘은 점점 “TLS”라고 더 말하지만, 불과 1~2년 전까지만 해도 거의 항상 “SSL”이라고 했음
      그래도 가끔 SSL이 튀어나옴
      51세이고 90년대 중반에 IT 일을 시작함

  • TLS 1.0이 SSL 3.0보다 꽤 큰 개선을 담고 있지 않았나 싶음
    글만 보면 그냥 다르게 보이려고 몇 가지만 고친 것처럼 보임

    • 주된 차이는 패딩에 있음
      POODLE 공격이 SSL3에만 영향이 있고 TLS1.0에는 없다고 사전 공개됐을 때, 그 정보만으로도 패딩 오라클일 것이라고 예측할 수 있었음
      둘은 꽤 비슷하고 몇 가지 “버그 수정”이 들어갔다고 보는 게 공정함
      오래전 일이라 몇 가지를 잊었을 수도 있고, SSL3와 TLS1.0은 항상 같이 구현했기 때문에 세부사항을 놓쳤을 수도 있음
    • 변경은 작았고, 다른 어떤 버전 개정보다도 작았음
      대체로 IETF가 SSL 3.0 프로토콜을 그대로 승인하지 않고 자기 영역 표시를 한 것에 가까웠음
    • 의미 있는 변화와 개선은 분명 있었지만, SSL 3.0처럼 완전한 재설계는 아니었음

  • 관련 글로 1996년 1월 Dr. Dobb's Journal의 “Randomness and the Netscape Browser”가 있음
    https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
    1996년에 쓰인 글인데, 사용된 언어가 오늘날 출판물과 이미 꽤 다르게 느껴져서 나이 든 느낌이 듦

    • 어떤 출판물을 보느냐에 따라 다름
      1996년에도 그랬듯이, 오늘날 LWN 글 [1] 같은 건 꽤 비슷한 문체로 읽힘
      다만 조금 더 일반 독자를 겨냥해서 약간 덜 딱딱할 수는 있음
      [1] https://lwn.net/
    • 그 글의 저자들은 그 보안 문제를 찾아서 New York Times 표지에도 실렸음: https://www.nytimes.com/2012/02/15/technology/researchers-fi...

  • Eric Rescorla의 “SSL and TLS: Designing and Building Secure Systems”가 TLS의 역사와 지금까지 오게 된 과정을 이해하는 데 정말 유용했던 기억이 있음
    2001년에 나온 책인데, 이후 CVE가 된 몇몇 문제를 이미 경고했고 중고로 몇 달러에 구할 수도 있음

  • 2014년쯤에는 SSL 2.0이 심각하게 결함 있다는 합의가 아주 확고했다고 봄
    핸드셰이크조차 제대로 인증되지 않았음

답변달기