잼잼테크

지금까지 TLS 핸드셰이크부터 키 교환, 인증서 검증, Let's Encrypt 자동 갱신까지 HTTPS의 안쪽을 차근차근 파봤습니다. 그런데 한 가지 어이없는 함정이 남아 있어요. "HTTPS를 아무리 잘 깔아놔도, 사용자가 처음에 http://example.com으로 들어오면?" 그 순간 중간자가 가로채서 영원히 평문 사이트로 안내해 버릴 수 있습니다. 이걸 SSL Stripping 공격이라고 해요.저도 예전에 "어차피 80 포트는 443으로 리다이렉트하니까 안전하지" 하고 넘겼다가, 보안 점검에서 HSTS 미설정으로 빨간불이 떴습니다. 오늘은 HTTPS를 정말 강제하는 HSTS와, 함께 챙겨야 할 핵심 보안 헤더들을 한 번에 정리해 보겠습니다.개념 / 원리HSTS, "이 도메인은 무조건 HTTPS"..

지난 글에서 인증서 체인과 폐기 검증을 다뤘는데요, 거기서 빠진 게 하나 있습니다. "그래서 그 인증서, 누가 어떻게 발급해 주냐?" 예전엔 CA에 돈 내고, 양식 채워서 신청하고, 며칠 기다려서 받았어요. 갱신할 때는 또 그 과정을 반복했고요. 저도 한 번씩 만료일을 놓쳐서 새벽에 식은땀 흘리며 갱신한 적이 있습니다.이걸 다 자동화해서 무료로 풀어버린 게 Let's Encrypt입니다. 그리고 그 뒤에는 ACME라는 잘 만든 프로토콜이 있어요. 오늘은 Let's Encrypt가 어떻게 도메인 소유를 검증하고, 인증서를 발급하고, 자동으로 갱신하는지 그 동작 원리를 풀어보겠습니다.개념 / 원리Let's Encrypt가 가져온 변화Let's Encrypt는 ISRG(Internet Security Rese..

지난 두 글에서 TLS 핸드셰이크 흐름과 키 교환 원리를 풀었는데요, 한 가지가 계속 매달려 있었습니다. "그래서 서버가 보낸 인증서가 진짜라는 걸 브라우저는 도대체 어떻게 믿는 거지?" 키 교환이 아무리 안전해도, 처음 받은 인증서가 가짜라면 전부 도루묵이거든요.저도 예전에 사내 API에 자체 서명 인증서를 붙여놓고 "왜 자꾸 SSL 오류가 나지?" 한참 헤맨 적이 있습니다. 결국 신뢰 체인이라는 개념을 모르고 있었던 거였어요. 오늘은 브라우저가 인증서를 받아들고 어떤 단계로 검증하는지, 그리고 한 번 발급된 인증서를 어떻게 "폐기"할 수 있는지까지 풀어보겠습니다.개념 / 원리신뢰 체인 (Chain of Trust)브라우저가 신뢰하는 건 사실 서버의 인증서가 아니라 그 인증서를 발급한 CA, 그 CA를..

지난 글에서 TLS 핸드셰이크의 전체 흐름을 훑었는데요, 그때 "키 교환" 단계는 한 줄로 지나갔습니다. 사실 이 키 교환이야말로 TLS에서 가장 짜릿한 부분입니다. 서로 한 번도 만난 적 없는 두 사람이, 누가 옆에서 패킷을 다 보고 있는 상황에서, 어떻게 둘만 아는 비밀 키를 만들어낼까요? 마술 같지만 수학이 만든 일입니다.저도 처음 이 원리를 이해했을 때 "아니 이게 진짜 되네?" 싶었어요. 오늘은 TLS 안에서 대칭키와 비대칭키가 어떻게 역할을 나눠 가지는지, 그리고 실제 키 교환이 어떤 식으로 이뤄지는지 한 단계씩 풀어보겠습니다.개념 / 원리대칭키와 비대칭키, 빠른 비교항목대칭키비대칭키키 개수1개 (양쪽 공유)2개 (공개키 + 개인키)속도매우 빠름일반적으로 수백 배 느림약점키를 어떻게 안전하게 ..

HTTPS 사이트에 접속할 때 주소창에 자물쇠 아이콘이 뜨는 거, 다들 한 번쯤은 보셨을 거예요. 가끔 그 자물쇠가 깨지거나 "이 연결은 안전하지 않습니다" 경고가 뜨면 가슴이 철렁하죠. 저도 예전에 운영 중인 서비스의 인증서가 만료된 줄 모르고 있다가, 새벽에 고객사 전화 받고 부랴부랴 갱신한 적이 있습니다.HTTPS가 보안 통신이라는 건 알겠는데, 실제로 그 자물쇠 안에서 무슨 일이 벌어지는지는 의외로 흐릿하게 아는 분들이 많습니다. 오늘은 HTTPS의 심장인 TLS 핸드셰이크가 정확히 어떤 순서로, 무엇을 주고받는지 한번 제대로 까보겠습니다.개념 / 원리HTTPS는 사실 새로운 프로토콜이 아니라 HTTP + TLS 조합입니다. 평문 HTTP를 TLS라는 보안 계층 위에 얹어 돌리는 거죠. 그래서 핵..