Tomcat 10.1.54 버전 Release Note 요약 및 정리
안녕하세요.
톰캣 릴리즈 노트 최신 업데이트 내용으로 소개하고자 합니다.
Tomcat 10.1.54 버전 Release 의 내용 정리 및 요약 입니다.
-
URI 및 Query String 이스케이프 처리 추가
-
개요
(1) 로그 깨짐 (Log Injection / Format 깨짐)
예를 들어 이런 요청이 들어오면:
GET /test?param=hello” 500 “hacked HTTP/1.1 → “GET /test?param=hello” 500 “hacked HTTP/1.1”
– 로그 필드 구분(“)이 깨짐
– 분석 툴(Grafana, ELK) 파싱 실패
(2) 로그에 그대로 찍히면 로그 위조(Log Forging) 가능
/test?param=abc\nERROR: hacked → /test?param=abc ERROR: hacked
-
개선사항
URI와 Query String을 로그에 남길 때 위험한 문자들을 안전한 형태로 변환
ELK / Grafana / Splunk에서 깨짐 방지 공격자가 로그를 조작하는 것 차단
JSON 구조 로그 대응
-
잘못된 HEADERS 프레임 수신 시 연결이 비정상 종료되는 문제 수정
HEADERS 프레임이란?
클라이언트(웹 브라우저 등)가 서버에 새로운 요청을 시작할 때 보내는 가장 첫 번째 프레임입니다. 여기에는 어떤 페이지를 요청하는지(URL 경로), 어떤 방식인지(GET/POST), 브라우저 정보는 무엇인지 등 핵심적인 HTTP 헤더 정보가 담겨 있습니다.
-
개요
이전 버전에서는 잘못된 HEADERS 프레임을 해석(Parsing)하는 로직에 결함이 있었습니다. 이 때문에 GOAWAY 프레임을 클라이언트에게 보내지도 않은 채 TCP 연결 자체를 비정상적으로 끊어버리는(Abrupt Close) 현상이 발생했습니다.
-
개선사항
이제 규격에 어긋난 프레임이 들어오더라도 당황해서 연결을 끊어버리지 않고, HTTP/2 표준에 맞게 정상적으로 GOAWAY 프레임을 생성하여 클라이언트에게 전송한 뒤 안전하게 연결을 종료합니다.
-
request header 버퍼가 stream reset 후 제대로 초기화되지 않는 문제 수정
-
개요
정상흐름 : 요청 → 헤더 파싱 → 처리 → 응답 → 버퍼 초기화
문제 상황: 요청 → 헤더 파싱 중 or 직후 → Stream Reset 발생→ 버퍼 초기화 안됨
– HTTP/2는 연결을 재사용하기 때문에 다음 stream에서 이전 header 일부가 남아 있을 수 있음 그로 인해 이전 요청 데이터가 다음 요청에 섞일 가능성 있음 또한 내부 객체 상태가 깨지거나
예상치 못한 동작 발생 할수 있음,보안 관련 문제 발생가능성 생김
-
개선사항
– Stream reset 시점에 request header 버퍼를 명시적으로 초기화
-
non-blocking flush 버그 수정
-
개요
정상흐름: write() → flush() → 일부 전송 → 나머지는 나중에 이어서 전송
문제상황: write() → flush() → 실제 전송 안됨 (버퍼에 남음) → 계속 쌓임 → 연결 종료 시점에 한 번에 전송
– 이로인해 응답 지연 발생
클라이언트는 응답이 안 오는 것처럼 보임, 실제로는 서버 버퍼에 쌓여 있음
그리고 스트리밍 깨짐 – SSE (Server-Sent Events), chunked response , 파일 다운로드 등 마지막에 한꺼번에 전송
-
개선사항
– flush가 완전히 끝나지 않았을 때 반드시 재시도 상태로 등록
– socket writable 이벤트 발생 시 남은 데이터 다시 flush
-
OpenSSL 동작을 tomcat-native 및 FFM 코드와 일관되게 정렬
-
개요
Tomcat에서 TLS(HTTPS)는 3가지 방식으로 처리
1) JSSE
2) tomcat-native
3) FFM
같은 OpenSSL 기반인데도 tomcat-native 과 FFM 는 동작 방식이 미묘하게 달랐음
– handshake 처리 방식
– 에러 반환 방식
– 버퍼 처리 타이밍
– shutdown / close 처리
다음과 같은 처리방식 시, 환경마다 동작이 달라짐 (native에서는 정상, FFM에서는 오류)
디버깅 어려움 , TLS edge case에서 오류
-
개선사항
OpenSSL 호출/처리 로직을 통일하여 TLS 동작 일관성 확보 , 환경별 차이 제거, 유지보수 쉬워짐 , 버그 발생 가능성 감소
-
HTTP trailer 필드에도 필터링 적용
Trailer Field란?
: 일반 HTTP 요청/응답 구조
[Start Line]
[Headers]
[Body]
-
개요
Trailer Field 필터링 부족,없음으로 인해 검증되지 않은 데이터가 들어올 수 있음
-
개선사항
– 제어 문자 제거 ( \x00 ~ \x1F :제어문자, \x7F : DEL )
– 255 초과 문자 제거
Trailer 필드에도 Header와 동일한 입력 검증을 적용하여, 제어문자 및 비정상 문자를 공백으로 치환하는 보안 강화 패치
-
OpenSSLEngine 버퍼 재사용 방식 개선
-
개요
버퍼 재사용 방식 불일치
– tomcat-native (JNI 기반)
– FFM (Foreign Function & Memory API)
둘 다 OpenSSL 쓰는데 버퍼 처리 방식이 달랐음
불필요한 버퍼 생성/복사
데이터 → 새 ByteBuffer 생성 → 복사 → OpenSSL 전달
이로인해 GC 증가 , 메모리 낭비 , CPU 오버헤드
-
개선사항
버퍼 재사용 로직 통일하여 같은 방식으로 buffer lifecycle 관리함
불필요한 복사 제거하기위해 가능하면 기존 buffer 그대로 재사용
버퍼 lifecycle 명확화
tomcat-native와 FFM 간 동작을 통일
-
Kubernetes 연결 실패 로그 과다 출력 감소
클러스터/서비스 디스커버리 과정에서 불필요하게 반복되던 에러 로그를 줄인 개선입니다.
-
개요
java.net.ConnectException: Connection refused 이로그가 매 요청 / 매 주기마다 계속 출력됨
그래서 로그 파일 급증 , 중요한 로그 묻힘, 디스크 사용량 증가등의 문제가 생김
-
개선사항
동일한 오류 반복 출력 제한, Log Level Down : ERROR → WARN / DEBUG
-
EncryptInterceptor 에러 처리 개선
-
개요
암호화/복호화 과정에서는 다양한 예외가 발생할 수 있습니다:
잘못된 키 (Key mismatch)
암호화 알고리즘 오류
데이터 손상 (네트워크 문제)
Padding 오류
복호화 실패 (BadPaddingException 등)
-
개선사항
단순 Exception → 구체적인 처리
– 복호화 실패 → 해당 메시지만 드롭
– 전체 클러스터 영향 최소화
안전한 실패 (Fail-safe)
<변경전>
복호화 실패 → 연결 끊김 → 클러스터 불안정
<변경후>
복호화 실패 → 해당 메시지 무시 → 계속 동작
결론적으로,
암호화 실패가 전체 클러스터 장애로 이어지지 않도록 안전하게 처리하도록 개선한 것입니다
-
그외 릴리즈
– bnd 라이브러리 7.2.3으로 업데이트
– 프랑스어 / 일본어 번역 품질 개선
Kubernetes 연결 실패 로그 과다 출력 관련해선 꼭 개선해야 한다고 생각 했었는데
드디어 되었네요!
글 읽어 주셔서 감사합니다:)
자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의: info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr
