Java 기반 보안 솔루션의 TLS 하드닝 - 개념 정리

🔹 들어가며

최근 새로운 직장에서 바쁘지만 재미있게 학습과 업무를 수행하며 시간을 보내고 있습니다. 
이번에는 통합 보안 솔루션(SIEM)을 포함한 모든 솔루션들의 통신 채널 취약점에 관련한 내용을 정리해보고자 합니다.

솔루션들이 사용하는 통신 채널 자체가 취약하다면, 보안 데이터를 보호해야 할 시스템이 오히려 쉽게 공격 타겟이 되어버립니다. 
그렇기 때문에 실제로 보안 감사나 컴플라이언스 점검 시에 아래 항목들을 체크하는 것이 중요합니다.

점검 항목	위험도	예시
TLS 1.0/1.1 허용 여부	높음	BEAST, POODLE 등 알려진 공격 가능
순수 RSA 키교환 허용 여부	높음	Forward Secrecy 미보장
RC4, DES, 3DES 허용 여부	높음
CBC 모드 cipher 허용 여부	중간	Padding 공격 가능

 

Java 기반 서버의 특수성

이번 테스트를 통해, Java 기반 환경(Netty, Tomcat, Spring Boot 등)은 JDK의 TLS 스택(JSSE)에 의존한다는 것과 OpenSSL 기반 서버(ex. Apache)와 설정 방식이 다른 것에 대해 알 수 있었습니다. 
실제로, Java 서버에서는 JDK 보안 설정이나 JVM 시스템 프로퍼티로, 두 가지 레이어 별 구성이 가능했고, 설정 별 반영되는 반영되는 바운더리가 달랐습니다.

 

🔹 TLS 1.2, TLS 1.3의 구조적 차이 이해

TLS 1.3 Cipher Suite 구조

TLS_AES_256_GCM_SHA384
│     │    │     │
│     │    │     └─ HKDF 해시
│     │    └─────── 블록 암호 모드
│     └──────────── 대칭 암호 알고리즘
└────────────────── 프로토콜

키교환: 별도 협상 (ECDHE/DHE만 허용, RSA 키교환 원천 불가)
인증: 별도 협상 (Certificate + CertificateVerify)

TLS 1.3은 키 교환이 cipher suite에서 분리되었고(RSA 키교환은 기본 차단됨), ECDHE/DHE 표준 프로토콜만 지원됩니다. 
TLS 1.3을 사용하면 Forward Secrecy가 자동으로 보장이 됩니다. 

 

TLS 1.2, TLS 1.3 비교

항목	TLS 1.2	TLS 1.3
Forward Secrecy	수동으로 cipher suite 제한 필요	프로토콜에서 강제함
Cipher Suite 수	~300개 이상 (약한 것 포함)	5개 (모두 강력)
핸드셰이크	2-RTT	1-RTT (성능 향상)
0-RTT	미지원	지원

 

참고사항

• TLS 1.2는 RSA키교환 프로토콜이 포함이 되어 있기 때문에, 수동으로 cipher suite 제한을 해야 한다. 
• 단, 레거시 호환성으로 인해 TLS 1.2를 유지해야 하는 경우가 존재하기 때문에 연동 서버 별 cipher suite나 SSL/TLS 프로토콜 설정에 유의해야 한다. 

 

🔹 Forward Secrecy? RSA 키교환?

Forward Secrecy 란?
FS, PFS(Perfect Forward Secrecy)란 서버의 개인키가 유출되어도 과거에 기록된 통신은 복호화할 수 없는 성질을 의미합니다. 
 

RSA, ECDHE 알고리큼 키교환 로직

 
 

---

🔹 보안 솔루션에서 중요한 이유

보안 솔루션에서 다루는(전송하는) 보안 이벤트 데이터

• 침해 지표(IoC)
• 사용자 인증 로그
• 방화벽/IPS 이벤트 등

이런 데이터가 순수 RSA 키교환으로 전송되고 있었다면, 공격자가 패킷을 캡처·보관한 뒤 나중에 서버 개인키를 탈취하면 과거의 모든 보안 이벤트 데이터를 열람할 수 있습니다. 
 
이상, 보안 솔루션에서 씬 하드닝이 필요한 이유와 개념에 대해서 설명을 해보았습니다.
다음 편에서는 이번 편에서 설명힌 취약점들을 해소하기 위힌 실습과정인 실제로 openssl로 TLS 취약점을 진단하는 방법, JDK 파라미터 설정법, 그리고 다중 노드 환경에서의 안전한 롤링 적용 전략에 대해 다뤄보겠습니다.
 
 그럼 다음 글에서 뵙겠습니다.
감사합니다!