SSL (Secure Sockets Layer)과 TLS (Transport Layer Security)는 모두 인터넷 연결을 암호화하는 암호화 프로토콜입니다. 실질적인 차이점은 모든 SSL 버전은 지원 중단되었고 안전하지 않으며, TLS가 오늘날 실제로 웹을 보호한다는 것입니다. 사람들이 “SSL 인증서”라고 할 때, TLS와 함께 사용되는 인증서를 의미합니다.
무언가를 해야 하는지 궁금하시다면 — 해야 할 일로 바로 이동하세요.
빠른 비교
| SSL | TLS | |
|---|---|---|
| 정식 명칭 | Secure Sockets Layer | Transport Layer Security |
| 개발 | Netscape (1994) | IETF (1999) |
| 최신 버전 | SSL 3.0 (1996) | TLS 1.3 (2018) |
| 상태 | ⛔ 모든 버전 지원 중단 | ✅ TLS 1.2와 1.3 사용 중 |
| 알려진 취약점 | POODLE, BEAST, CRIME, DROWN | 없음 (TLS 1.3), 소수 완화 가능 (TLS 1.2) |
| 성능 | 느림 (2+ 왕복) | TLS 1.3: 1-RTT 핸드셰이크 |
| 순방향 비밀성 | 선택사항 (거의 사용 안 됨) | TLS 1.3에서 필수 |
| 암호화 스위트 | 약함 (RC4, DES, 수출용 암호화) | 강함 (AES-GCM, ChaCha20) |
| 메시지 인증 | MD5/SHA-1을 사용한 MAC | SHA-256 이상을 사용한 HMAC |
| 브라우저 지원 | 모든 브라우저에서 제거 | 보편적 |
전체 버전 역사
| 연도 | 프로토콜 | 내용 |
|---|---|---|
| 1994 | SSL 1.0 | Netscape가 설계. 공개되지 않음 — 출시 전 내부에서 심각한 결함 발견. |
| 1995 | SSL 2.0 | 첫 공개 출시. 초기 HTTPS 사이트에서 사용. 빠르게 주요 취약점 발견 (약한 MAC, 절단 공격에 취약). |
| 1996 | SSL 3.0 | Paul Kocher + Netscape의 완전 재설계. 18년간 광범위하게 배포. POODLE 공격 (2014년 10월)으로 무력화. 2015년 6월 IETF에 의해 지원 중단 (RFC 7568). |
| 1999 | TLS 1.0 | SSL 3.0 기반의 IETF 표준화 프로토콜. 소규모 개선. BEAST 공격 (2011)에 취약. 2021년 3월 지원 중단 (RFC 8996). |
| 2006 | TLS 1.1 | BEAST 취약점 수정. CBC 암호화에 명시적 IV 추가. TLS 1.0과 함께 2021년 3월 지원 중단. |
| 2008 | TLS 1.2 | 주요 업그레이드. AEAD 암호화 (AES-GCM) 추가, 핸드셰이크에서 MD5/SHA-1 제거, 서명 알고리즘 협상 추가. 올바르게 설정하면 여전히 널리 사용되고 안전. |
| 2018 | TLS 1.3 | 현재 표준 (RFC 8446). 모든 레거시 알고리즘 제거, 1-RTT 핸드셰이크, 순방향 비밀성 필수, 암호화된 핸드셰이크. 근본적인 재설계. |
주요 시점:
- 2014년 10월: Google이 POODLE 취약점 발견 — SSL 3.0은 수정 불가, 폐기해야 함
- 2015년 6월: IETF가 공식적으로 SSL 3.0 지원 중단 (RFC 7568)
- 2021년 3월: IETF가 TLS 1.0과 1.1 지원 중단 (RFC 8996)
- 2020-2021: 모든 주요 브라우저가 TLS 1.0/1.1 지원 중단
왜 여전히 “SSL”이라고 부르나
“SSL”이라는 용어가 먼저 나왔기 때문에 굳어졌습니다. Netscape가 1994년에 만들었고, 1999년에 TLS가 대체했을 때 “SSL”은 이미 일상 용어였습니다. 오늘날:
- “SSL 인증서” = TLS와 함께 사용되는 인증서 (SSL이 아님)
- “SSL/TLS” = 두 용어를 아우르는 표현
- 제품명의 “SSL” = 마케팅이지 실제 프로토콜이 아님
- “무료 SSL” = 무료 TLS 인증서
GetHTTPS, Certbot, Let’s Encrypt, ZeroSSL — 모두 이름이나 마케팅에서 “SSL”이라고 해도 TLS 연결용 인증서를 발급합니다. 인증서 자체는 X.509 형식이며 모든 TLS 버전에서 작동합니다.
이 글은 업계와 동일한 방식으로 “SSL 인증서”를 사용합니다: TLS와 함께 사용되는 인증서를 의미합니다.
중요한 기술적 차이점
암호화 스위트
SSL은 현재 깨진 것으로 알려진 알고리즘에 의존했습니다:
| 알고리즘 | 사용 위치 | 상태 |
|---|---|---|
| RC4 | SSL 2.0, 3.0 | 깨짐 — RFC 7465가 금지 |
| DES, 3DES | SSL 2.0, 3.0 | 깨짐/지원 중단 |
| MD5 | SSL 핸드셰이크 | 충돌 공격 입증됨 |
| 수출용 암호화 | SSL (미국 정책) | 의도적으로 약함 (40/56비트 키) |
| AES-GCM | TLS 1.2, 1.3 | ✅ 현재 표준 |
| ChaCha20-Poly1305 | TLS 1.2, 1.3 | ✅ 모바일/ARM에 우수 |
TLS 1.3은 암호화 스위트 목록을 단 5개 옵션으로 줄였으며 — 모두 안전합니다. TLS 1.2는 37개 이상이며, 일부는 약합니다. TLS 1.3의 단순함은 잘못된 설정의 여지를 줄입니다.
핸드셰이크 속도
| SSL 3.0 | TLS 1.2 | TLS 1.3 | |
|---|---|---|---|
| 전체 핸드셰이크 | 2+ 왕복 | 2 왕복 | 1 왕복 |
| 세션 재개 | 1 왕복 | 1 왕복 | 0-RTT (첫 메시지에 데이터 포함) |
| 실질 지연 | 60-120ms | 40-80ms | 20-40ms |
TLS 1.3의 0-RTT 재개는 재방문자가 즉시 암호화된 데이터를 전송할 수 있다는 의미입니다 — 핸드셰이크 지연이 전혀 없습니다.
순방향 비밀성
순방향 비밀성은 모든 연결이 고유한 키를 사용한다는 의미입니다. 누군가 서버의 개인키를 탈취해도 과거 대화를 복호화할 수 없습니다.
- SSL 3.0: 순방향 비밀성 미지원
- TLS 1.0-1.2: 지원 (ECDHE 경유) 하지만 RSA 키 교환도 허용 (순방향 비밀성 없음)
- TLS 1.3: 필수 — RSA 키 교환 완전 제거
메시지 인증
- SSL: MD5 또는 SHA-1을 사용한 MAC — 둘 다 현재 약한 것으로 간주
- TLS: SHA-256 이상을 사용한 HMAC — 알려진 약점 없음
해야 할 일
대부분의 웹사이트 운영자에게: 아마 아무것도 안 해도 됩니다. 만약:
- 유효한 SSL/TLS 인증서가 있고 (Let’s Encrypt 또는 다른 인증 기관에서)
- 합리적으로 최신인 웹 서버를 사용하고 (Nginx 1.13+, Apache 2.4.37+, IIS 10)
- 설정에서 TLS 1.2/1.3을 명시적으로 비활성화하지 않았다면
…이미 TLS를 사용하고 있습니다. “SSL 인증서”는 자동으로 TLS 1.2와 1.3에서 작동합니다 — 동일한 .pem 파일이 두 프로토콜 모두에 사용됩니다.
한 가지 확인할 것: 서버에서 TLS 1.0과 1.1이 비활성화되어 있는지 확인하세요. 2021년부터 지원 중단되었습니다.
Nginx:
ssl_protocols TLSv1.2 TLSv1.3;Apache:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1현재 TLS 버전을 확인하는 방법:
# 어떤 TLS 버전이 협상되었는지 표시
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep "Protocol"
# 예상: TLSv1.2 또는 TLSv1.3온라인 도구: SSL Labs Server Test에서 서버가 어떤 프로토콜을 지원하는지 정확히 보여줍니다.
TLS 1.3 도입 현황
2026년 초 기준, 62%의 웹사이트가 TLS 1.3을 지원합니다. 모든 주요 브라우저가 지원합니다. 서버가 최신 상태라면 이미 TLS 1.3이 적용되어 있을 가능성이 높습니다.
TLS 1.3을 기본 지원하는 서버 (특별한 설정 불필요):
- Nginx 1.13+ (OpenSSL 1.1.1+ 포함)
- Apache 2.4.37+ (OpenSSL 1.1.1+ 포함)
- Caddy (모든 버전 — 항상 최신 TLS 사용)
- Cloudflare (자동)
- AWS ALB/CloudFront (자동)
앞으로의 전망: 포스트 양자 암호화
다음 주요 TLS 발전은 포스트 양자 키 교환 — 현재 키 교환 알고리즘(ECDHE, RSA)을 깨뜨릴 수 있는 미래의 양자 컴퓨터에 대한 보호입니다. Google Chrome과 Cloudflare는 이미 TLS 1.3에서 하이브리드 키 교환(고전 + 포스트 양자)을 실험하기 시작했습니다.
이는 새 인증서를 필요로 하지 않습니다 — 변경은 인증서 형식이 아닌 키 교환 메커니즘에 있습니다. Let’s Encrypt 인증서는 포스트 양자 TLS가 도입되어도 작동합니다.
자주 묻는 질문
TLS와 SSL에 다른 인증서가 필요한가요?
아니요. 동일한 인증서가 모든 TLS 버전에서 작동합니다. “SSL 인증서”와 “TLS 인증서”는 동일한 X.509 파일을 의미합니다. GetHTTPS에서 인증서를 받으면 TLS 1.2와 1.3에서 작동합니다 — 특별한 설정이 필요 없습니다.
TLS 1.2는 아직 안전한가요?
네. AEAD 암호화 스위트(AES-GCM 또는 ChaCha20-Poly1305)를 사용하는 TLS 1.2는 프로덕션에서 안전합니다. TLS 1.3이 더 좋지만(더 빠르고, 더 간단하며, 순방향 비밀성을 강제), TLS 1.2도 안전합니다. 권장 설정은 TLSv1.2 TLSv1.3입니다.
TLS 1.3만 강제해야 하나요?
아직은 아닙니다. 약 38%의 사이트가 TLS 1.3을 지원하지 않으며, 일부 이전 클라이언트(기업 환경, 임베디드 기기, Java 8)는 TLS 1.2만 지원할 수 있습니다. 오늘 TLS 1.2를 제거하면 일부 정당한 사용자가 차단됩니다. 둘 다 지원하세요.
”SSL 인증서”가 작동을 멈추나요?
아니요. 이름과 달리 “SSL 인증서”는 모든 TLS 버전에서 작동하는 X.509 인증서입니다. 이름은 레거시 유물입니다. 인증 기관이 신뢰되고 인증서가 만료되지 않는 한 계속 작동합니다.
HTTPS는 SSL이나 TLS와 같은 건가요?
HTTPS는 HTTP + TLS입니다. HTTP 연결에 TLS 암호화를 적용한 결과입니다. https://example.com을 방문하면, 브라우저는 TLS 프로토콜을 사용하여 HTTP 트래픽을 암호화합니다. HTTPS는 TLS와 별개의 프로토콜이 아닙니다 — TLS 터널 안에서 실행되는 HTTP입니다.
POODLE 공격이 무엇인가요?
POODLE (Padding Oracle On Downgraded Legacy Encryption)은 2014년 10월 Google이 발견했습니다. SSL 3.0의 CBC 암호화 패딩 결함을 악용했습니다. 이 공격으로 같은 네트워크의 공격자가 암호화된 트래픽의 개별 바이트를 복호화할 수 있었습니다. 결함이 특정 구현이 아닌 프로토콜 설계에 있었기 때문에, SSL 3.0은 패치할 수 없었습니다 — 완전히 폐기해야 했습니다. 이것이 SSL의 관에 박은 마지막 못이었습니다.