HTTP vs HTTPS 차이와 SSL 동작 원리 쉽게 이해하기
웹 서핑을 할 때 주소창에 http://와 https://를 자주 보셨을 것입니다. 이 한 글자 차이가 보안의 핵심을 가르는 중요한 요소입니다. 이번 글에서는 HTTP와 HTTPS의 차이점, 그리고 HTTPS를 가능하게 하는 SSL/TLS의 동작 원리를 쉽게 풀어드리겠습니다.
HTTP란 무엇인가
HTTP(HyperText Transfer Protocol)는 웹 브라우저와 서버 간 데이터를 주고받는 프로토콜입니다. 텍스트, 이미지, 동영상 등 모든 웹 리소스를 전송하는 기본 규약이지만, 데이터를 암호화하지 않고 평문으로 전송합니다.
이 말은 중간에 누군가 데이터를 가로채면(스니핑) 아이디, 비밀번호, 카드 번호 등 민감한 정보가 그대로 노출될 수 있다는 의미입니다. 따라서 HTTP는 보안이 필요 없는 단순 정보 제공 사이트 외에는 사용을 지양해야 합니다.
HTTPS란 무엇인가
HTTPS(HyperText Transfer Protocol Secure)는 HTTP에 SSL/TLS 암호화 계층을 추가한 프로토콜입니다. 데이터를 암호화하여 전송하므로 중간자 공격(MITM)이나 데이터 도청으로부터 안전합니다.
HTTPS를 사용하면 다음과 같은 이점이 있습니다.
- 기밀성(Confidentiality): 데이터를 암호화하여 제3자가 내용을 확인할 수 없음
- 무결성(Integrity): 데이터가 전송 중 변조되지 않았음을 보장
- 인증(Authentication): 서버의 신원을 인증서로 확인
- SEO 가산점: Google 등 검색엔진에서 HTTPS 사이트를 우선 노출
HTTP와 HTTPS의 핵심 차이
| 항목 | HTTP | HTTPS |
|---|---|---|
| 포트 | 80 | 443 |
| 암호화 | 없음 (평문 전송) | SSL/TLS 암호화 적용 |
| 인증서 | 필요 없음 | SSL 인증서 필요 |
| 보안 | 취약 (스니핑, 변조 위험) | 안전 (데이터 보호) |
| 속도 | 상대적으로 빠름 | 암호화/복호화로 약간 느림 (HTTP/3, TLS 1.3으로 개선) |
| SEO | 불리함 | Google 검색 순위 가산점 |
SSL/TLS란 무엇인가
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 네트워크 통신을 암호화하는 프로토콜입니다. SSL은 구버전이며 현재는 TLS 1.2, TLS 1.3이 표준으로 사용됩니다. 하지만 관행적으로 SSL 인증서라는 용어가 여전히 널리 쓰입니다.
TLS는 대칭키 암호화와 비대칭키 암호화를 조합하여 사용합니다. 각각의 특징을 이해하면 SSL의 동작 원리가 명확해집니다.
🔐 대칭키 암호화 (Symmetric Key)
하나의 키로 암호화와 복호화를 모두 수행합니다. 속도가 빠르지만, 키를 안전하게 공유하는 것이 어렵습니다. 만약 키를 전송하는 과정에서 유출되면 암호화가 무의미해집니다.
암호화: 평문 + 대칭키 = 암호문
복호화: 암호문 + 대칭키 = 평문🔐 비대칭키 암호화 (Asymmetric Key)
공개키(Public Key)와 개인키(Private Key) 한 쌍을 사용합니다. 공개키로 암호화하면 개인키로만 복호화할 수 있고, 반대로 개인키로 서명하면 공개키로 검증할 수 있습니다.
암호화: 평문 + 공개키 = 암호문
복호화: 암호문 + 개인키 = 평문
서명: 데이터 + 개인키 = 서명값
검증: 데이터 + 서명값 + 공개키 = 유효성 확인비대칭키는 안전하지만 연산량이 많아 속도가 느립니다. 따라서 SSL/TLS는 비대칭키로 안전하게 대칭키를 교환하고, 실제 데이터 전송은 대칭키로 암호화하는 방식을 사용합니다.
SSL/TLS Handshake 동작 원리
클라이언트(브라우저)와 서버가 HTTPS 연결을 시작할 때, 먼저 Handshake 과정을 거칩니다. 이 과정에서 서로를 인증하고 암호화에 사용할 키를 안전하게 교환합니다.
📡 TLS 1.2 Handshake 과정
1. Client Hello
- 클라이언트가 지원하는 TLS 버전, 암호화 알고리즘 목록, 랜덤 값 전송
2. Server Hello
- 서버가 선택한 TLS 버전, 암호화 알고리즘, 랜덤 값 전송
3. Certificate
- 서버가 SSL 인증서(공개키 포함)를 클라이언트에 전송
4. Server Key Exchange + Server Hello Done
- 서버의 키 교환 정보 전송 후 Handshake 일단락
5. Client Key Exchange
- 클라이언트가 Pre-Master Secret 생성 후 서버 공개키로 암호화하여 전송
6. Change Cipher Spec (클라이언트)
- 이제부터 암호화된 통신 시작 알림
7. Finished (클라이언트)
- 지금까지의 Handshake 내용으로 생성한 해시값 전송
8. Change Cipher Spec (서버)
- 서버도 암호화된 통신 시작
9. Finished (서버)
- 서버의 해시값 전송, Handshake 완료
→ 이후 모든 데이터는 대칭키(Session Key)로 암호화되어 전송📡 TLS 1.3 Handshake (간소화)
TLS 1.3은 1.2보다 Handshake를 1-RTT(또는 0-RTT)로 단축하여 속도를 크게 개선했습니다. 불필요한 암호화 알고리즘을 제거하고 보안성도 향상시켰습니다.
1. Client Hello (키 공유 정보 포함)
2. Server Hello + EncryptedExtensions + Certificate + Finished
3. Client Finished
→ 단 1번의 왕복으로 Handshake 완료SSL 인증서 종류와 선택
SSL 인증서는 검증 수준에 따라 세 가지로 나뉩니다. 사이트의 성격과 보안 요구사항에 맞게 선택해야 합니다.
| 종류 | 검증 수준 | 발급 시간 | 적합한 사이트 |
|---|---|---|---|
| DV (Domain Validation) | 도메인 소유권만 확인 | 수 분 ~ 수 시간 | 개인 블로그, 소규모 사이트 |
| OV (Organization Validation) | 기업 정보 추가 확인 | 1~3일 | 기업 홈페이지, 쇼핑몰 |
| EV (Extended Validation) | 엄격한 기업 심사 | 3~7일 | 은행, 금융, 대형 쇼핑몰 |
무료 인증서로는 Let’s Encrypt가 가장 널리 사용되며, 90일마다 자동 갱신이 필요합니다. 상용 인증서는 유효기간이 길고 보증금(보험)이 포함되어 있습니다.
HTTPS 적용 실무 가이드
🔧 Let’s Encrypt 무료 인증서 발급
# Certbot 설치 (Ubuntu 기준)
sudo apt update
sudo apt install certbot python3-certbot-nginx
# Nginx용 인증서 발급
sudo certbot --nginx -d example.com -d www.example.com
# 자동 갱신 테스트
sudo certbot renew --dry-run🔧 HTTP를 HTTPS로 강제 리다이렉트
# Nginx 설정 예시
server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# TLS 1.2, 1.3만 사용
ssl_protocols TLSv1.2 TLSv1.3;
}🔧 HSTS(HTTP Strict Transport Security) 설정
HSTS는 브라우저가 항상 HTTPS로 접속하도록 강제하는 헤더입니다. 한 번 설정하면 지정된 기간 동안 HTTP 접속을 차단합니다.
# Nginx 설정
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;자주 하는 실수와 해결책
❌ 혼합 콘텐츠(Mixed Content) 오류
HTTPS 페이지에서 HTTP 리소스(이미지, CSS, JS)를 불러오면 브라우저가 차단합니다. 모든 리소스 경로를 상대 경로 또는 HTTPS 절대 경로로 변경하세요.
❌ 
✅
✅ 
✅ 
✅ 
❌ 인증서 만료
Let’s Encrypt 인증서는 90일마다 갱신해야 합니다. certbot의 자동 갱신(cron)을 설정하거나, 모니터링 알림을 구성하세요.
# 자동 갱신 cron 설정
0 3 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"❌ 약한 암호화 알고리즘 사용
TLS 1.0, TLS 1.1은 보안 취약점이 발견되어 사용을 중단해야 합니다. SSL Labs 등의 도구로 서버의 SSL 설정을 점검하세요.
# SSL Labs 테스트
https://www.ssllabs.com/ssltest/analyze.html?d=example.com실무 체크리스트
- ✅ 모든 도메인에 HTTPS를 적용할 것
- ✅ HTTP → HTTPS 강제 리다이렉트를 설정할 것
- ✅ TLS 1.2 이상만 사용할 것 (1.0, 1.1 비활성화)
- ✅ HSTS 헤더를 적용할 것
- ✅ 인증서 자동 갱신을 설정할 것
- ✅ 혼합 콘텐츠가 없는지 확인할 것
- ✅ SSL Labs 등으로 보안 등급을 점검할 것
- ✅ OCSP Stapling을 활성화하여 인증서 상태 확인 속도를 높일 것
자주 묻는 질문
HTTPS를 적용하면 속도가 느려지나요?
과거에는 암호화/복호화로 인해 속도 저하가 있었지만, TLS 1.3과 HTTP/2, HTTP/3의 등장으로 이제는 오히려 HTTP보다 빠를 수도 있습니다. 특히 HTTP/2의 멀티플렉싱과 서버 푸시 기능은 HTTPS에서만 동작합니다.
Let’s Encrypt 인증서를 상용 인증서로 교체해야 하나요?
대부분의 경우 Let’s Encrypt로 충분합니다. 다만 EV 인증서가 필요한 금융권이나, 인증서 보증금(보험)이 필요한 엔터프라이즈 환경에서는 상용 인증서를 고려하세요.
SSL과 TLS의 차이는 무엇인가요?
SSL은 TLS의 전신입니다. SSL 3.0까지 나왔으나 보안 취약점으로 사용이 중단되었고, 이후 IETF가 표준화한 것이 TLS입니다. 현재는 TLS 1.2와 TLS 1.3이 표준이며, SSL이라는 용어는 관행적으로 남아있을 뿐입니다.
마무리
이번 글에서는 HTTP vs HTTPS 차이와 SSL 동작 원리를 쉽게 풀어드렸습니다. HTTPS는 이제 선택이 아닌 필수이며, SSL/TLS Handshake를 통해 안전한 통신이 이루어지는 원리를 이해하면 보안 설정에 자신감을 가질 수 있습니다.
핵심을 정리하면 다음과 같습니다: HTTP는 평문 전송으로 취약하고, HTTPS는 SSL/TLS로 암호화하여 안전하며, Handshake 과정에서 비대칭키로 대칭키를 교환하고 실제 데이터는 대칭키로 암호화하여 전송합니다. 모든 사이트에 HTTPS를 적용하고, TLS 1.2 이상만 사용하며, 인증서는 자동 갱신하세요.
HTTP와 HTTPS, SSL 관련 궁금한 점이나 문제가 있으시면 댓글로 남겨 주세요. 도움이 되셨다면 이 글을 주변에 공유해 주시는 것도 잊지 마세요!
댓글 0
첫 댓글을 남겨보세요.