#6 인터넷에서는 비대칭키를 어떻게 활용할까?

 

주소창에 https만 떠도 안심할 수 있는 이유

인터넷은 원래 위험하다 기본적인 HTTP 통신은 누구나 중간에서 몰래 엿볼 수 있습니다.

• 비밀번호도 평문으로 전달됨
• 쿠키 탈취 가능
• 중간자 공격(MITM, Man-In-The-Middle)에 취약 그래서 등장한 것이 SSL/TLS, 지금은 HTTPS라는 이름으로 사용됩니다.

 

HTTPS 통신, 아주 간단한 흐름

🔒 https\:// 로 시작하면 이런 일들이 벌어집니다

1. 브라우저가 서버에 접속 → "공개키 주세요"
2. 서버는 공개키 + 인증서를 전달
3. 브라우저는 이걸 검증한 뒤, 대칭키를 생성
4. 생성한 대칭키를 서버의 공개키로 암호화해서 전달
5. 서버는 자기 개인키로 복호화해서 대칭키 획득
6. 이후 통신은 빠른 대칭키 방식으로 진행

→ 이 과정을 핸드셰이크(handshake)라고 부릅니다.

 

 

정리: 왜 비대칭키를 먼저 쓰고, 대칭키로 바꾸는가?

이유	설명
대칭키는 빠르다	실시간 통신에 적합
하지만 키를 안전하게 주고받기 어렵다	중간에 탈취당할 수 있음
그래서 비대칭키로 "대칭키를 안전하게 전달"	이후엔 대칭키로 빠르게 통신

📌 암기 공식: 공개키로 대칭키 전달 → 이후 대칭키로 통신

 

특징

① SSL? TLS?

용어	설명
SSL (Secure Sockets Layer)	초창기 암호화 프로토콜 (현재는 사용 안 함)
TLS (Transport Layer Security)	SSL의 후속, 지금 사용되는 표준
HTTPS	HTTP + TLS (이게 지금 우리가 쓰는 것)

✅ 지금 사용하는 https는 사실 TLS 기반

 

② 서버는 공개키를 어떻게 믿게 할까?

서버는 자기 공개키를 그냥 주지 않음

인증서(Certificate)에 공개키 + 정보 + 디지털 서명을 담아 보냄

이걸 브라우저가 검증함 (→ 9장에서 자세히 다룸) > 즉, 공개키를 서명으로 보증받아야 믿을 수 있음 

 

요약

• HTTPS = 공개키 + 대칭키 혼합
• 초반에 공개키로 대칭키를 안전하게 전달
• 이후 대칭키로 빠르게 데이터 통신
• 이 구조는 SSL(과거) → TLS(현재)로 진화됨
• 공개키는 인증서로 신뢰를 보장받아야 함