TLS 버전은 누가 주체인가요? 어느 기관에서 업그레이드를 하고 배포를 하는지?

 

 

1) TLS(Transport Layer Security) 한 줄 요약

TLS는 네트워크에서 통신 내용을 암호화·무결성·상대방 인증을 제공하는 프로토콜입니다. HTTPS, API 통신, 메일 등 대부분의 애플리케이션 계층 통신에서 사용됩니다. 최신 표준은 TLS 1.3 (RFC 8446) 입니다.

 

2) 왜 TLS 업그레이드(또는 레거시 제거)가 필요한가? — 핵심 이유

1. 보안 취약점: TLS 1.0/1.1, SSL3.0 등 옛 버전은 이미 POODLE, BEAST, CRIME 등 실용적 공격과 설계적 약점을 갖고 있어 중간자·복호화·다운그레이드 공격에 취약합니다. 최신 공격 대비를 위해 TLS 1.2/1.3 사용 권장. Acunetix+1
2. 규제·컴플라이언스: 카드결제·금융 등에서는 TLS 1.2 이상을 요구하거나(PCI 가이드라인), 오래된 TLS 비활성화를 권고합니다 — 미준수 시 인증·거래 차질 위험. blog.pcisecuritystandards.org+1
3. 성능·간소화: TLS1.3은 핸드셰이크가 더 간단해 지연이 줄고 보안 설계가 개선되어 운영 부담 감소(불필요한 옵션 제거).

 

🔹 1. TLS “만드는 주체” — 국제 표준화 기관 (IETF)

구분	설명
기관명	IETF (Internet Engineering Task Force, 인터넷 엔지니어링 태스크포스)
역할	전 세계 인터넷 프로토콜(HTTP, TCP, TLS 등)의 표준(RFC) 을 제정하는 기관
표준 문서 형태	RFC(Request for Comments) 문서로 공개됨
TLS 관련 RFC	- TLS 1.0: RFC 2246 (1999) - TLS 1.1: RFC 4346 (2006) - TLS 1.2: RFC 5246 (2008) - TLS 1.3: RFC 8446 (2018, 최신)
보안 관련 워킹그룹	IETF 내 TLS Working Group이 지속적으로 유지·관리

 

📘 즉, IETF가 “TLS 버전”을 제정하고 공개하는 공식 주체입니다.
새 버전은 연구자·기업·보안 전문가의 합의로 만들어집니다.

---

🔹 2. TLS “구현하고 배포하는 주체” — 소프트웨어/OS/플랫폼 벤더

표준이 만들어지면, 이를 각 기술 벤더들이 소프트웨어 안에 구현합니다.
(즉, 실제로 TLS를 “업그레이드”하고 “배포”하는 건 이 단계에서 일어납니다.)

구현 주체 예시 포함 대상

구현 주체	예시	포함 대상
오픈소스 TLS 라이브러리	OpenSSL, BoringSSL(Google), LibreSSL, wolfSSL, NSS(Firefox), GnuTLS	웹서버, 앱, OS, IoT 기기 등
운영체제(OS)	Windows (Schannel), macOS/iOS (Secure Transport), Linux (OpenSSL 기반), Android (Conscrypt)	브라우저, 앱, 서버
런타임/프레임워크	Java (JSSE), .NET (SChannel/Windows TLS Stack), Python (ssl 모듈), Node.js (OpenSSL 기반)	API, 앱서버
클라우드 벤더	AWS, Azure, GCP, Cloudflare 등	로드밸런서, CDN, HTTPS 엔드포인트
웹서버	Apache, nginx, IIS, Tomcat, Jetty, Spring Boot 등	실제 TLS 접속이 이루어지는 곳

 

이들이 각각 TLS 1.3 같은 최신 버전을 구현한 라이브러리를 배포하고,
운영체제나 애플리케이션 업데이트를 통해 고객(기업, 개발자)이 수동/자동으로 적용하게 됩니다.

---

 

🔹 3. TLS “적용하고 운영하는 주체” — 서비스 운영자(기업, 가맹점, 개발자)

 

여기서 TLS 업그레이드를 “실행”하는 사람은 바로 **우리(서비스 운영자)**입니다.

역할	예시
서버/가맹점 운영자	웹서버, API 서버, LB, 결제서버의 TLS 설정을 최신으로 적용 (1.2 이상)
클라이언트 개발자	앱, 브라우저, POS 단말에서 TLS 1.2 이상 지원 SDK/OS를 사용
보안팀/IT관리자	취약 TLS 버전 차단, 인증서 관리, 보안점검 수행
결제대행사(PG)	가맹점 API 서버에서 TLS 1.0/1.1 접속 차단 공지 및 테스트 지원

 

즉, TLS 표준은 IETF가 만들지만, “적용 책임”은 각 서비스 운영자에게 있습니다.

---

🔹 4. TLS 업그레이드의 실질적 배포 경로 요약

IETF (표준 제정)
   ↓
OpenSSL, Java, .NET 등 (구현)
   ↓
운영체제 / 런타임 / 웹서버 (패키지 업데이트)
   ↓
클라우드/기업/가맹점 (운영 환경에 적용)
   ↓
최종 사용자 (앱, 브라우저 통해 통신)

예를 들어

• IETF가 TLS 1.3 표준을 만들고
• OpenSSL이 이를 구현한 뒤
• Ubuntu / RHEL / AWS가 새 버전 OpenSSL을 배포하고
• 개발자가 nginx나 Java 앱을 업데이트하면
  → 실제 서비스가 TLS1.3 통신을 시작하게 됩니다.

---

🔹 5. 요약 — “누가 TLS 버전을 업그레이드하나요?”

구분	주체	역할
표준 제정자	IETF	TLS 프로토콜 사양(RFC) 작성
구현자	OpenSSL, Microsoft, Oracle, Apple 등	TLS 기능을 코드로 구현
배포자	OS/클라우드/플랫폼 벤더	업데이트 패키지로 배포
적용자(우리)	서버 운영자, 개발자, 가맹점	설정 변경·업그레이드 실행
검증자	보안기관, PCI, 금융당국	취약버전 차단·감사 수행

---

🔹 6. 참고로 – TLS 관련 글로벌 관리 구조

• IETF TLS WG: https://datatracker.ietf.org/wg/tls/
• OpenSSL Project: https://www.openssl.org
• CA/브라우저 포럼 (CAB Forum): 인증서 정책(HTTPS 인증서 표준 관리)
• PCI SSC: 결제망 내 TLS 최소 버전 준수 규정 제정

---