반응형
HTTPS(HTTPS)가 안전한 이유는 사실 여러 기술을 조합했기 때문이야.
핵심은:
1. 진짜 서버인지 확인
2. 안전하게 키 교환
3. AES로 빠르게 암호화 통신
4. 위변조 검증이 4개를 동시에 하기 때문이다.
먼저 HTTP는 위험
HTTP는 평문이다.
즉:
ID/PW
쿠키
본문 데이터전부 그대로 네트워크에 흐른다.
중간에서 보면:
다 읽힘HTTPS는 뭐냐?
간단히:
HTTP + TLS(SSL)이다.
즉 HTTP 위에 암호화 계층을 추가한 것.
HTTPS 전체 흐름
실제로는:
1. 서버 인증
2. 키 교환
3. 암호화 통신순서로 진행된다.
STEP 1 — 서버 인증서 전달
브라우저가 접속하면 서버가:
- 인증서(Certificate)
- 공개키(Public Key)
를 보낸다.
인증서 안에는
예:
도메인
공개키
발급기관(CA)
전자서명등이 들어있다.
STEP 2 — 브라우저가 인증서 검증
브라우저는:
"이 공개키가 진짜 네이버 것 맞나?"를 확인한다.
여기서 CA 등장
대표:
- Let's Encrypt
- DigiCert
같은 인증기관.
CA가 전자서명함
즉:
"이 공개키는 진짜 네이버 것 맞음"이라고 도장 찍어주는 것.
브라우저는 공개키로 검증
브라우저 안에는:
신뢰 가능한 CA 공개키들이 미리 들어있다.
그래서 전자서명 검증 가능.
여기까지의 의미
"가짜 서버가 아니구나"를 확인 완료.
STEP 3 — 키 교환
이제 실제 암호화 통신용 키 필요.
HTTPS는 현재 보통:
- Elliptic-curve Diffie–Hellman
- ECDHE
사용.
핵심
AES 키를 직접 보내지 않음이다.
대신
브라우저와 서버가:
각자 계산해서
같은 AES 세션키 생성한다.
왜 안전하냐?
중간에서:
- 공개값
- 통신 내용 일부
봐도:
최종 AES 키 계산 불가하기 때문.
STEP 4 — 실제 암호화 통신
이제부터는:
- Advanced Encryption Standard
- AES-GCM
으로 통신.
왜 AES 쓰냐?
엄청 빠르기 때문.
즉:
RSA/ECC
→ 키 교환 전용
AES
→ 실제 데이터 통신구조.
STEP 5 — 무결성 검증
현대 HTTPS는 보통:
- AES-GCM
- ChaCha20-Poly1305
사용.
이건:
암호화 + 위변조 검증동시에 수행.
그래서 가능한 것
중간에서 데이터 바꾸면:
인증 태그 검증 실패즉시 연결 오류.
HTTPS가 막아주는 것
| 공격 | 방어 여부 |
| 중간 감청 | O |
| 비밀번호 탈취 | O |
| 데이터 위변조 | O |
| 가짜 서버 | O(인증서 검증 시) |
실제로 중간에서 뭘 보나?
HTTPS에서도:
- IP
- 도메인(SNI/DNS)
- 패킷 크기
등 일부 메타데이터는 보일 수 있다.
하지만:
본문 내용
쿠키
비밀번호는 암호화된다.
왜 "자물쇠 아이콘" 뜨나?
브라우저가:
TLS 연결 성공
+
인증서 검증 성공했다는 의미.
HTTPS 핵심 기술 연결
| 기술 | 역할 |
| 인증서 | 서버 신원 증명 |
| 전자서명 | 인증서 위조 방지 |
| ECDHE | 세션키 교환 |
| AES-GCM | 실제 암호화 |
| Hash/HMAC | 무결성 검증 |
그런데 HTTPS도 완벽하진 않다
HTTPS는:
전송 구간 보호다.
즉:
- 서버 내부 해킹
- XSS
- SQL Injection
- 계정 탈취
까지 막는 건 아니다.
예를 들어
HTTPS라도:
악성 JS가 브라우저에서 비밀번호 훔치면 끝.
핵심 한 줄
HTTPS가 안전한 이유는:
전자서명으로 서버를 검증하고,
ECDHE로 안전하게 AES 키를 만든 뒤,
AES-GCM으로 데이터를 암호화·위변조 검증하기 때문이다.
반응형
'system_fundamentals > security_cryptography' 카테고리의 다른 글
| 인증서는 누가 믿는가 (1) | 2026.05.15 |
|---|---|
| TLS Handshake 전체 흐름 (0) | 2026.05.15 |
| 권한 시스템 설계 (1) | 2026.05.15 |
| ACL (0) | 2026.05.15 |
| ABAC (0) | 2026.05.15 |
댓글