HTTPS의 모든 것

📌 이 글에서 다루는 깊이 있는 내용

  • HTTP가 위험한 이유: Wireshark 패킷 캡처로 보는 평문 전송의 위험성
  • 대칭키 & 비대칭키의 하이브리드 전략: 왜 두 가지를 섞어서 쓰는가?
  • SSL/TLS Handshake 심층 분석: Client Hello부터 Finished까지 4단계 해부
  • TLS 1.2 vs 1.3: 핸드쉐이크 횟수(RTT) 단축을 통한 성능 최적화
  • Chain of Trust: 루트 CA부터 내 브라우저까지의 신뢰 검증 과정

신입 개발자 면접에서 "주소창에 google.com을 치면 일어나는 일" 다음으로 많이 나오는 질문이 바로 "HTTPS의 동작 원리"입니다. 단순히 "보안이 강화된 HTTP입니다"라고 답한다면 좋은 점수를 받기 어렵습니다.

이 글에서는 HTTPS가 어떻게 데이터를 암호화하는지, 그리고 그 과정에서 발생하는 성능 저하를 막기 위해 최신 TLS 1.3은 어떤 마법을 부리는지 아주 깊게 파고들어 보겠습니다.

디지털 네트워크의 SSL/TLS

1. HTTP는 왜 위험한가? (Wireshark로 본 세상)

HTTP는 기본적으로 평문(Plain Text) 통신입니다. 여러분이 카페 공용 와이파이에서 HTTP로 된 쇼핑몰에 로그인한다고 가정해 봅시다. 해커가 같은 와이파이 망에서 Wireshark 같은 패킷 스니핑 툴을 켜면 어떻게 될까요?

POST /login HTTP/1.1 Host: insecure-shop.com Content-Type: application/x-www-form-urlencoded id=myuser&password=I_love_cat_1234

보시는 것처럼 ID와 비밀번호가 아무런 보호 장치 없이 그대로 노출됩니다. 이를 막기 위해 데이터를 알아볼 수 없게 암호화(Encryption)하는 계층인 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)를 HTTP 위에 얹은 것이 바로 HTTPS입니다.

2. 암호화 전략: 속도와 보안의 줄타기

암호화 방식에는 크게 두 가지가 있습니다. HTTPS는 이 둘의 장점만을 취하는 하이브리드 방식을 사용합니다.

① 대칭키 (Symmetric Key)

  • 원리: 암호화할 때 쓰는 키와 복호화할 때 쓰는 키가 같습니다. (예: AES 알고리즘)
  • 장점: 연산 속도가 매우 빠릅니다. 대용량 데이터를 전송하기 적합합니다.
  • 단점: "키 배송 문제"가 발생합니다. 이 키를 상대방에게 어떻게 안전하게 전달할까요? 키를 보내는 과정에서 해커가 가로채면 끝입니다.

② 비대칭키 (Asymmetric Key / 공개키)

  • 원리: 공개키(Public Key)로 잠그고, 개인키(Private Key)로만 열 수 있습니다. (예: RSA 알고리즘)
  • 장점: 키 배송 문제가 해결됩니다. 공개키는 만천하에 공개해도 상관없습니다.
  • 단점: 대칭키 방식보다 연산이 훨씬 복잡하고 느립니다. 모든 통신을 이걸로 하면 서버 CPU가 터집니다.
💡 HTTPS의 결론 (하이브리드 암호화)

"처음 만날 때(Handshake)만 비대칭키를 써서 서로의 '대칭키(세션 키)'를 안전하게 교환하고,
그 이후 실제 데이터 전송은 빠른 대칭키를 사용하자!"

3. SSL/TLS Handshake 심층 분석 (4-Way)

브라우저(Client)와 서버(Server)가 보안 통신을 시작하기 위해 서로를 확인하고 키를 교환하는 과정을 핸드쉐이크라고 합니다. TCP 3-Way Handshake가 끝난 직후에 일어납니다.

Step 1. Client Hello (탐색)

클라이언트가 서버에게 접속을 요청하며 다음 정보를 보냅니다.

  • Cipher Suite: "난 RSA랑 AES 암호화 방식을 지원해." (지원 가능한 암호화 리스트)
  • Client Random: 나중에 대칭키를 만들 때 쓸 난수 문자열 ①
  • Session ID: 이미 연결된 적이 있다면 재사용하기 위함.

Step 2. Server Hello (응답 & 인증서 전달)

서버는 클라이언트의 제안 중 가장 강력한 암호화 방식을 선택하고 답장을 보냅니다.

  • Selected Cipher Suite: "그래, 우리 TLS 1.2에 RSA 방식으로 하자."
  • Server Random: 나중에 대칭키를 만들 때 쓸 난수 문자열 ②
  • Certificate: 서버의 공개키(Public Key)가 포함된 SSL 인증서.

Step 3. 인증서 검증 & Pre-Master Secret 교환 (핵심)

이 단계가 가장 중요합니다.

  1. 브라우저는 내장된 CA(Root Certificate Authority) 리스트를 통해 서버가 보낸 인증서가 진짜인지 검증합니다.
  2. 검증이 끝나면, 브라우저는 Pre-Master Secret이라는 임시 비밀 키를 생성합니다.
  3. 이 비밀 키를 서버의 공개키로 암호화해서 서버에게 보냅니다. (이제 이 키는 오직 서버의 개인키를 가진 서버만 풀 수 있습니다. 해커는 못 풉니다.)

Step 4. Session Key 생성 & 통신 시작

서버는 암호화된 Pre-Master Secret을 자신의 개인키로 복호화합니다. 이제 클라이언트와 서버는 모두 다음 3가지를 똑같이 가지고 있습니다.

Client Random + Server Random + Pre-Master Secret
⬇️
Session Key (대칭키) 완성!

이후부터는 이 Session Key를 이용해 데이터를 AES 등으로 빠르게 암호화하여 주고받습니다.

4. TLS 1.2 vs TLS 1.3: 속도 혁명

위에서 설명한 과정(TLS 1.2)은 안전하지만, 데이터를 보내기 전까지 2번의 왕복(2-RTT: Round Trip Time)이 필요합니다. 서울-뉴욕 간 통신이라면 핸드쉐이크에만 수백 밀리초가 소요됩니다.

최신 TLS 1.3은 이를 획기적으로 개선했습니다.

구분 TLS 1.2 TLS 1.3
핸드쉐이크 RTT 2 RTT (느림) 1 RTT (빠름)
키 교환 방식 RSA (느림) Diffie-Hellman (빠름, 기본값)
보안 강도 취약한 암호화 알고리즘 지원 취약한 알고리즘(SHA-1 등) 전면 삭제

TLS 1.3은 Client Hello 단계에서 "서버가 뭘 쓸지 예상해서" 키 교환 정보를 미리 보내버립니다. 덕분에 한 번의 왕복만으로 통신 준비가 끝납니다. 심지어 0-RTT(이전에 접속했던 사이트라면 핸드쉐이크 없이 바로 데이터 전송)까지 지원합니다.

5. Chain of Trust (신뢰의 사슬)

마지막으로, 브라우저는 어떻게 네이버의 인증서가 진짜인지 알 수 있을까요?

  • Root CA: 최상위 인증 기관(VeriSign, DigiCert 등). 이들의 공개키는 OS나 브라우저 설치 시 이미 내장되어 있습니다.
  • Intermediate CA: Root CA가 "얘는 믿을만해"라고 서명해 준 중간 관리자.
  • Leaf Certificate: 우리가 발급받은 도메인 인증서.

브라우저는 인증서를 받으면 상위 기관의 서명을 확인하며 Root CA까지 거슬러 올라갑니다. 만약 사슬 중 하나라도 끊어지거나 신뢰할 수 없다면, 브라우저는 그 무서운 "연결이 비공개로 설정되어 있지 않습니다"라는 빨간 경고창을 띄웁니다.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기