SSL/TLS
"Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network."
— IETF RFC 8446 (TLS 1.3) 서문
웹 브라우저 주소창에 귀여운 초록색 자물쇠 아이콘을 띄워 유저들에게 '여기는 안전합니다'라고 안심시켜 주는 일등 공신이자, 인증서 만료 시 자비 없이 유저들을 쫓아내는 수문장. 사실 SSL은 심각한 취약점 때문에 완전히 퇴출되고 지금은 다 TLS를 쓰지만, 업계 관행상 다들 그냥 입에 붙어서 SSL/TLS 혹은 그냥 SSL이라 칭한다
1. 개요
SSL/TLS(Secure Sockets Layer / Transport Layer Security)는 컴퓨터 네트워크 상에서 통신 보안을 제공하기 위해 설계된 암호화 프로토콜이다. 인터넷에서 데이터를 전송할 때, 악의적인 제3자가 이를 훔쳐보거나(스니핑) 변조하는 행위를 철저히 방어한다. 대표적인 적용 사례가 바로 우리가 매일 쓰는 HTTPS로, 일반 평문 통신 프로토콜인 HTTP 하단에 이 SSL/TLS 레이어를 깔아두어 데이터를 암호화해 전송한다. 오늘날 금융 거래, 로그인, 개인정보 전송이 일어나는 모든 현대적 웹사이트의 기본 옵션이자 필수 인프라로 굳건히 자리 잡았다.(...)
2. 악마의 스니핑을 막는 비대칭키와 대칭키의 융합 마법
2.1. 대칭키의 빠름과 비대칭키의 안전함을 동시에!
데이터를 암호화할 때 가장 골치 아픈 문제는 '열쇠를 어떻게 안전하게 전달할 것인가'이다. 암호화와 복호화에 같은 열쇠를 쓰는 대칭키 암호화 방식은 속도가 엄청나게 빠르지만, 네트워크로 열쇠를 보내다가 해커에게 털리면 끝장이라는 치명적인 단점이 있다. 반면 서로 다른 키(공개키와 개인키)를 사용하는 비대칭키(공개키) 암호화 방식은 열쇠를 대놓고 공개해도 안전하지만, 컴퓨터에 엄청난 연산 부담을 주는 끔찍한 단점이 있었다.
SSL/TLS는 이 두 가지 방식의 단점을 상쇄하고 장점만 취합한 똑똑한 하이브리드 설계를 채택했다.
- 비대칭키의 활약: 클라이언트와 서버가 처음 만나 통신을 시작할 때(Handshake 단계), 단 한 번 비대칭키 암호화 방식을 사용하여 앞으로 실제 통신에 사용할 임시 대칭키(세션 키)를 안전하게 주고받는다.
- 대칭키의 활약: 서로 대칭키를 안전하게 공유하는 데 성공한 이후부터는, 연산이 매우 가볍고 빠른 대칭키 방식으로 모든 본문 데이터를 초고속으로 암호화해 송수신한다.(...)
이러한 천재적인 이중 설계 덕분에 현대 웹은 기가바이트 단위의 유튜브 영상 스트리밍조차 아주 안전하고 빠르게 실시간 암호화 처리할 수 있게 되었다.
3. 신뢰의 사슬: 인증 기관(CA)과 핸드셰이크
3.1. 너를 어떻게 믿지? Certificate Authority
열쇠를 안전하게 바꿨다 해도, 내가 지금 대화를 나누고 있는 서버가 진짜 '네이버'나 '구글'인지, 아니면 네이버를 사칭한 해커의 피싱 사이트인지 구별할 방법이 필요하다. 이때 등장하는 보증인이 바로 인증 기관(CA, Certificate Authority)이다.
웹 서버 운영자는 자신의 공개키와 신원 정보를 CA에 보내 심사를 받고, CA의 비밀키로 서명된 디지털 인증서를 발급받는다. 우리의 컴퓨터와 웹 브라우저 안에는 전 세계 저명한 CA들의 공개키 리스트가 윈도우나 macOS 업데이트를 통해 기본 탑재(Root CA)되어 있다.1 브라우저는 서버가 제시한 인증서를 CA의 공개키로 검증하여 정당한 인증서임이 확인되는 순간에만 주소창에 자물쇠를 걸어준다. 만약 신뢰할 수 없는 CA가 발급했거나 위조된 인증서라면, 브라우저는 즉시 "이 사이트는 안전하지 않습니다"라는 공포스러운 경고창을 띄워 유저를 대피시킨다.
3.2. 인류 구원의 오픈소스: Let's Encrypt
과거에는 이 SSL 인증서를 발급받기 위해 Symantec이나 VeriSign 같은 독점적인 CA 업체들에게 매년 수십~수백 달러의 무지막지한 수수료를 바쳐야 했다. 이 때문에 가난한 개인 블로거나 오픈소스 개발자들은 HTTPS 도입을 포기하고 보안 사각지대에 머무는 경우가 허다했다.
그러나 2014년, 인터넷 보안 생태계를 정화하기 위해 비영리 단체들이 힘을 합쳐 Let's Encrypt라는 무료 CA 서비스를 출범시켰다. 이들은 인증서 발급 수수료를 0원으로 책정하고, 모든 발급 및 갱신 프로세스를 API로 자동화(certbot)할 수 있게 개방해 버리는 파격적인 행보를 보여주었다. 이 선구적인 기여 덕분에 전 세계 웹의 HTTPS 보급률은 순식간에 90%를 돌파하며 안전한 웹 생태계가 실현되었다.2
4. 관련 밈 및 드립
4.1. 인증서 만료의 날 (Day of Expired Certificate)
아무리 웅장하고 거대한 대기업의 IT 인프라라도, 담당자의 건망증 하나로 한순간에 마비될 수 있음을 증명하는 공포의 시나리오.
SSL/TLS 인증서는 보안을 위해 보통 3개월에서 1년 정도의 짧은 유효기간을 가진다. 이 만료일을 달력에 적어두지 않았거나 자동 갱신 스크립트가 조용히 뻗어버린 경우, 당일 아침 출근한 수백만 명의 유저들은 사이트 접속이 전면 차단되는 경고창을 마주하게 된다. 실제로 마이크로소프트, 에픽게임즈, 심지어 깃허브 같은 공룡 기업들조차 1년에 한 번꼴로 인증서 만료를 까먹어 전 세계 서비스를 먹통으로 만드는 대참사를 벌이며 개발자 커뮤니티에서 '인증서 담당자 지금쯤 시말서 쓰는 중'이라는 짤방으로 박제되곤 한다.(...)
5. 여담
- SSL과 TLS의 혼용: 원래 넷스케이프가 개발한 스펙 명칭은 SSL(Secure Sockets Layer)이었으나, IETF가 이를 표준화하면서 TLS(Transport Layer Security)로 개명했다. 그러나 이미 업계에 SSL이라는 약어가 뇌리에 박혀버린 탓에, 공식 문서 외에는 여전히 두 단어를 섞어서 쓴다.
- Let's Encrypt의 90일 만료 제약: Let's Encrypt가 발급하는 무료 인증서는 유효기간이 단 90일에 불과하다. 이는 해커가 인증서 키를 탈취했을 때의 피해를 최소화하고, 수동 갱신 대신 강제적으로 갱신 프로세스를 자동화(cron 작업 등)하도록 유도하기 위한 영악한 설계다.
- 서버 이름 지시(SNI): 과거에는 IP 주소 하나당 단 하나의 SSL 인증서만 매핑할 수 있어 웹 호스팅 서버 운영자들이 괴로워했으나, 클라이언트가 핸드셰이크 시작 시 접속하고자 하는 도메인명을 미리 알려주는 SNI(Server Name Indication) 기술 덕분에 하나의 IP에서 수십 개의 독립된 HTTPS 도메인을 안전하게 운영할 수 있게 되었다.(...)