SSL이 90년대 후반에 TLS로 이름이 변경된 이유
(tim.dierks.org)- 1990년대 중반의 Netscape와 Microsoft의 브라우저 경쟁 속에서 SSL 프로토콜이 등장함
- SSL 2는 암호학적 및 실용적 결함이 있었고, 이를 토대로 Microsoft는 PCT 프로토콜을 도입함
- Netscape는 대응책으로 SSL 3.0을 개발해 주도권을 확보하려고 시도함
- 업계와 커뮤니티에서는 브라우저 간 호환성 유지를 희망해 IETF에 표준화 역할을 위임함
- 이 과정에서 프로토콜 이름이 TLS 1.0으로 변경되어 현재까지 이어짐
배경: 브라우저 경쟁과 보안 프로토콜의 탄생
- 1990년대 중반에는 Netscape와 Microsoft가 브라우저 시장에서 극심한 경쟁 구도를 형성함
- 경쟁 과정에서 Netscape가 SSL 프로토콜을 개발하게 되었음
SSL 2 및 문제점
- 최초 버전의 SSL은 암호학적 결함으로 곧바로 무력화되어 출시되지 않았음
- 실제로 배포된 SSL 2는 몇 년간 사용되었으나, 여러 암호학적 및 실용적 결함이 있었음
- 이 결함은 즉각적인 치명적 위기는 아니었으나, 개선의 필요성이 지속적으로 제기됨
Microsoft의 대응: PCT 프로토콜
- 경쟁 심화 속에서 Microsoft는 SSL 2에 자체적 기능을 추가해 PCT라는 프로토콜을 도입함
- PCT는 Internet Explorer(IE) 와 IIS에서만 지원되었음
Netscape의 새 전략: SSL 3.0
- Netscape 역시 SSL 2의 문제점을 개선하고자 했으나, Microsoft가 주도권을 잡는 것을 원치 않았음
- 이에 SSL 3.0을 개발, 기존과 뚜렷이 구분되는 변화를 추구함
브라우저 업계 표준화 협상
- 업계와 커뮤니티 구성원들은 프로토콜이 양분되는 것을 원하지 않았음(포크 현상 방지)
- Consensus Development(글쓴이가 근무한 곳)에서 Netscape와 Microsoft 대표자 회의를 주도함
- 이 회의에는 Bruce Schneier(유명해지기 전 시점), Paul Kocher(SSL 3 설계자), Barbara Fox(Microsoft 대표) 등이 참석함
IETF의 표준화 및 명칭 변경
- 넷스케이프와 마이크로소프트 모두 IETF(Internet Engineering Task Force) 가 프로토콜의 표준화 과정을 주도하는 데 합의함
- 글쓴이는 IETF 표준 문서(RFC) 편집을 담당함
- 정치적 타협의 일환으로, SSL 3.0에 일부 변경을 가하고 이름도 새롭게 지정해야 했음(기존 프로토콜을 IETF가 ‘무조건 승인’하는 인상을 피하기 위함)
- 결과적으로 TLS 1.0이라는 명칭이 탄생했으며, 실제로는 SSL 3.1에 해당하는 프로토콜임
맺음말
- 지금 돌아보면, 이 모든 명칭 및 표준화 논의 과정이 다소 우스꽝스럽게 느껴짐
Hacker News 의견
-
버전 번호만 봐서는 프로토콜이 얼마나 달라졌는지 제대로 알기 힘든 혼동스러운 상황 설명 SSLv2가 최초로 널리 쓰인 SSL 버전이지만 여러 문제점 존재 SSLv3는 거의 완전히 새롭게 만들어진 프로토콜 TLS 1.0은 SSLv3와 매우 비슷하지만 IETF 표준화 과정에서 몇 가지 소폭 개정 진행 TLS 1.1은 TLS 1.0에서 블록 암호 사용 방식의 문제를 해결하기 위한 소규모 수정 버전 TLS 1.2는 암호 기술 발전에 맞춰 중간 크기의 수정이 이뤄진 버전 최신 해시 지원(MD5와 SHA-1 취약점 대응), AEAD 암호군(AES-GCM 등) 지원 추가 TLS 1.3은 대부분 새로 만들어진 프로토콜이나, TLS 1.2 이하 특징 일부 접목 각 프로토콜은 자동 버전 협상 기능을 설계해 클라이언트와 서버가 독립적으로 업그레이드하는 데 연결성 손실이 없도록 함
-
당시 Microsoft는 지금과 완전히 다른 회사라는 점 감안하면 요즘 기준으로도 전혀 이상하지 않은 느낌 당시 'M$'는 오픈소스 인터넷 기술을 견제하기 위해 모든 수단을 동원했고 2010년대 초반까지도 이러한 태도 지속 Java Applets는 이를 통해 발전하지 못하고 시장에서 퇴출되는 데 일조했다는 생각 JavaScript와 CSS의 발전도 수년간 더뎠던 느낌 회사에서 IE의 최신 기술 지원을 강요했지만, 나는 대신 Mozilla 3.0을 선택했고 JS 버그 고친 이후부터 엔터프라이즈 SPA 개발에 Mozilla 적용 Fortune 500 기업에서도 이후 내부 앱에 Mozilla/Firefox 도입이 확대됐고, 결과적으로 좋은 선택이었던 기억
- 그 시절을 생각하면 'M$'라는 별명이 지금도 어울린다고 생각
-
차기 버전 이름, 다시 SSL로 돌려도 무방하지 않을지 의견 여전히 모든 사람이 'SSL' 명칭을 사용하고 있다는 점에서 계속 사용해도 무방하다고 주장
-
실제로 "TLS" 명칭도 이미 다양한 곳에서 쓰이고 있다는 점 언급 설정 및 함수 시그니처 등 업데이트는 굉장히 번거로운 일이라는 점에서 고민
-
이런 의견은 아무에게도 아이디어를 주고 싶지 않음 강조
-
-
누군가에게 웹사이트 접속을 안전하게 하라고 안내할 때(즉, TLS/SSL용어를 쓸 때), 나는 보통 어떤 명칭을 사용하는지 질문 또한 나이가 몇 살이며 1999년 이전에 일했는지 궁금하다고 덧붙임 내 답도 곧 달 것이라고 안내
-
나는 SSL이라고 답함(27세) 한편 코드 상에는
tls
를 사용하고, 문서에서는 혼동 방지를 위해 SSL/TLS 표기 선호 -
- SSL이라고 말함 오랜 시간 TLS가 "같은 것"이라는 사실도 잘 몰랐다가 알아도 여전히 10번 중 9번은 SSL이라고 함 2. 38세(2011년부터 일했지만 네트워크 프로그래밍은 2004~2005년부터) 방금 전 작업한 코드 화면을 보니 함수 이름에도 sslCertNotBefore 등으로 SSL이 박혀 있음 일반적으로 프로그래머는 TLS를 직접 다루지 않기 때문이 아닐까 생각 내 코드 역시 HTTPS에서 인증서 정보를 파싱해야 해서 꽤 번거로운 작업이었음 모두 자동화, 추상화된 덕에 실수 없이 처리할 수 있지만, TLS 작동 원리에 대한 깊은 이해에는 오히려 방해 요소가 되는 측면 존재
-
대부분 사람들이 OpenSSL처럼 ssl이란 이름이 들어간 라이브러리로 안전한 통신 구현을 하고 있어서 SSL 명칭을 많이 쓰는 경향 OpenSSL 외에도 BoringSSL, LibreSSL, wolfSSL 등 라이브러리 존재 TLS 이름이 붙은 라이브러리는 덜 유명함 대표적으로 GnuTLS, mbedTLS, s2n-tls, RustTLS 등이 있음
-
SSL이라는 용어를 사용하는 주된 이유는 SSL이 더 잘 통하는 것 같기 때문 엄밀하게는 TLS가 맞지만(실제로 SSL 3.0은 아무도 안 씀), 대표 라이브러리에도 SSL이라는 용어가 남아 있어서 계속 사용 중 실제로 90년대 암호 전쟁 시기에 SSL명칭을 배웠고, 그 당시 제대로 된 SSL 암호화를 위해선 넷스케이프("US only" 버전)을 불법 다운로드해야 했던 기억 때문에 그냥 익숙함에 사용하는 느낌
-
난 보통 "https"라고 말함 일반인도 의미를 대략 이해하는 경우가 있어서 선호
-
-
오히려 SSL과 TLS 용어를 무의식적으로 제대로 구분 못 하고 있었음을 처음 깨달음 20년 만에 진짜 이유를 알게 되어 신기한 기분
- 똑같은 느낌 업계에서 15년 일했는데 이제서야 SSL과 TLS가 실질적으로 같은 것임을 알게 된 기분
-
"Transport Layer Security"는 확실히 더 나은 명칭이라는 생각 TLS라는 말도 선호함 연달아 두 번 S발음 내면 뱀처럼 들려서 재미있게 느껴지기도 함
-
하지만 TLS는 이미 "Thread Local Storage" 용어에서도 널리 쓰이고 있음 Transport Layer Security가 1999년부터 공식적으로 쓰였지만, Thread Local Storage는 MS나 IBM 개발 환경 등에서 1996년 이전부터 존재 Unix 업계에선 pthread가 1995년 등장할 때부터 thread-specific data란 용어를 더 선호해온 측면도 있음 2001년 Itanium ABI 문서 영향으로 "TLS"가 더 널리 퍼진 배경도 있을 것 같고, Sun Microsystems도 이미 사용 중이었을 수 있음 혹시 누군가 OS/2 매뉴얼 소장 중이라면 참고자료 공유 바람
-
내 생각엔 오히려 SSL이 더 어울리는 명칭인 듯 이론적으로 TLS가 여러 계층에서 동작하는 일반적인 보안 수단(예: IPSec 접목도 가능)이어야 맞겠지만 실제로는 TCP 소켓을 위해서만 주로 사용 UDP 변형은 DTLS, QUIC이지만 TLS 자체엔 포함되지 않음 최근엔 리눅스 커널 TLS, 윈도우즈 특화 인프라도 있지만 단순히 소켓 플래그 켜듯 쉽게 적용되진 않음 그리고 솔직히 '뱀'처럼 들리는 S발음은 사운드 자체가 멋짐
-
"SSL"이 "TLS"보다 발음이 더 쉬움 S-S-L은 발음할 때 혀가 위치 이동이 거의 없어서 빠르고 자연스러움
-
정글북의 Kaa가 TCP 보안을 주제로 S~S~L 이름에 대해 얘기하면 어울릴 것 같음 사실 S 발음 하나 더 얹어서 SSSL로 불러도 재밌을 듯
-
-
TLS와 SSL을 엄격히 구분하는 사람들은 둘의 차이를 잘 알고 있다고 티내고 싶거나 그렇게 얘기 하길 원하는 스타일 실제 구분 자체는 .doc와 .docx(기본적으로 다르지만 일반 사용자에겐 거의 호환)차이와도 비슷 대다수는 HTTPS만 잘 돌아가면 내부 구조나 동작 방식엔 별 신경 안 씀
-
관련 링크: 1996년에 쓰여진 'Randomness and the Netscape Browser'라는 글(Dr. Dobb's Journal) 공유 https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html 1996년 글이라 현대 논문이나 기사와는 언어 분위기 자체가 크게 다름 나이 든 느낌 듦
- 어떤 출판물을 읽느냐(즉, 타겟/포맷에 따라)는 1996년과 마찬가지로 다양함 LWN 같은 곳은 지금도 비슷한 스타일로 글을 보도함(조금 덜 딱딱해졌을 뿐) https://lwn.net/
-
TLS 1.0이 SSL 3.0과 비교해 실제론 많은 개선점이 있었던 것 아닌지 질문 기사에선 단순히 "차이를 두기 위한 소폭 조정"으로 표현한 것 같아서 궁금하다고 제기
- 실질적으로 큰 변화와 개선이 많았던 것은 맞음 다만 SSL 3.0 때만큼의 완전한 리디자인은 아님 강조
-
인터넷에는 여전히 30만 개가 넘는 서비스가 SSLv2를 지원 중 링크: https://shodan.io/search/report/… 추이 그래프: https://trends.shodan.io/search?query=ssl.version%3Asslv2#overview 수치는 수년간 크게 줄었지만 완전히 사라지는 데엔 아직 시간이 소요될 것으로 보임
- 그렇다면 실제 SSLv2 기반 클라이언트는 몇이나 남아 있는지 궁금 요즘 소프트웨어/라이브러리엔 더 이상 의미 있는 수준의 지원이 없는 것으로 파악