OpenSSL 4.0.0이 공개됐습니다. 이번 업데이트는 단순한 버그 수정판이 아니라, 새 기능을 대거 넣는 동시에 오래된 호환 코드를 과감히 덜어낸 "세대교체형" 릴리스에 가깝습니다.1
한마디로 요약하면 이렇습니다. OpenSSL 4.0.0은 보안과 미래 대응력은 강화했고, 대신 레거시 의존성이 있는 환경에는 분명한 점검 과제를 남겼습니다. 특히 ECH 지원, FIPS 관련 변화, 그리고 SSLv3·엔진 제거는 서버 운영자와 개발자 모두가 꼭 확인해야 할 포인트입니다.12
OpenSSL 4.0.0 핵심 기능: ECH와 차세대 암호화
이번 OpenSSL 4.0.0에서 가장 눈에 띄는 키워드는 ECH, 즉 Encrypted Client Hello입니다. 쉽게 말하면 TLS 연결 초반에 드러나던 일부 메타데이터를 더 잘 숨길 수 있게 돕는 기술입니다. HTTPS가 이미 암호화돼 있어도, 연결 시작 단계 정보는 일부 노출될 수 있었는데, ECH는 이 틈을 줄이는 방향으로 이해하면 됩니다.1
여기에 cSHAKE 지원, SM2 관련 TLS 및 서명 알고리즘, SNMP KDF와 SRTP KDF, 그리고 TLS 1.2에서 협상형 FFDHE까지 추가됐습니다.13 즉, OpenSSL 4.0.0은 "기존 TLS 라이브러리"에서 한 걸음 더 나아가, 현대적 프로토콜 요구와 일부 포스트퀀텀 흐름까지 염두에 둔 버전이라고 볼 수 있습니다.
특히 보안 라이브러리는 새 기능이 많다고 무조건 좋은 게 아닙니다. 중요한 건 어디에 힘을 실었느냐인데, 4.0은 프라이버시 강화와 알고리즘 다양성 확대에 초점을 맞췄다는 점이 인상적입니다.
OpenSSL 4.0.0 호환성 변화: 레거시 제거가 본격화됐다
이번 버전에서 많은 사람이 실제로 체감할 변화는 "무엇이 추가됐나"보다 "무엇이 사라졌나"에 있습니다.
대표적으로 SSLv3와 SSLv2 Client Hello 지원이 제거됐습니다.1 이미 오래전부터 사실상 퇴장 수순이었지만, 이제는 코드 차원에서도 정리된 셈입니다. 엔진 지원도 빠졌습니다. 예전 OpenSSL 기반 확장 구조에 기대고 있던 프로젝트라면 빌드나 연동 방식 재검토가 필요할 수 있습니다.13
또한 c_rehash 스크립트가 사라지고 openssl rehash로 통합됐고, 일부 타임 비교 함수는 더 현대적인 인증서 시간 검사 API로 대체 방향이 제시됐습니다.1 이런 변화는 얼핏 사소해 보여도, 자동화 스크립트나 오래된 운영 문서에서는 꽤 크게 부딪힐 수 있습니다.
즉, OpenSSL 4.0.0 업그레이드는 "패키지 버전만 올리면 끝"인 작업이 아닐 수 있습니다. 특히 자체 빌드 환경, 오래된 TLS 옵션, 엔진 의존 코드가 있다면 사전 테스트가 사실상 필수입니다.
FIPS와 API 변경: 개발자가 놓치면 귀찮아지는 부분
실무적으로 더 중요한 변화는 내부 동작과 API 쪽입니다. FIPS provider를 사용할 때 PKCS5_PBKDF2_HMAC에 하한 검사가 더 엄격하게 적용되고, FIPS 설치 시 self test를 나중으로 미룰 수 있는 옵션도 추가됐습니다.1 규제 환경이나 기업 인프라에서는 꽤 반가운 변화입니다.
X.509 검증도 더 깐깐해졌습니다. strict 모드에서 AKID 검증이 추가됐고, CRL 검증 과정도 보강됐습니다.1 보안적으로는 좋은 일인데, 예전엔 "그냥 통과되던" 인증서 체인이 이제는 실패할 가능성도 있다는 뜻입니다.
개발자 입장에서는 ASN1_STRING이 opaque 타입이 된 점, 여러 함수 시그니처에 const가 추가된 점도 체크해야 합니다.12 기능은 그대로여도 컴파일 에러나 경고가 늘어날 수 있기 때문입니다. 이런 종류의 변화는 늘 귀찮지만, 장기적으로는 API 안정성과 안전한 사용 패턴에 도움이 됩니다.
OpenSSL 4.0.0 도입 전 체크포인트
지금 당장 가장 현실적인 질문은 이것입니다. "그래서 4.0으로 바로 가야 할까?"
최신 기능이 필요하면 답은 꽤 명확합니다. ECH나 새 암호 기능, 더 정리된 보안 정책이 필요하다면 OpenSSL 4.0.0은 매력적입니다.13 반면 운영 안정성과 장기 지원이 더 중요하다면 3.5 LTS를 유지하는 전략도 충분히 합리적입니다. 실제로 현재 LTS 축은 3.5 계열이며, 장기 유지보수를 중시하는 배포판들도 최신 LTS를 채택하는 흐름을 보이고 있습니다.345
예를 들어 Ubuntu 26.04 LTS는 OpenSSL 4.0이 아니라 3.5.6 LTS를 채택했습니다.5 이 선택만 봐도 분위기가 읽힙니다. "최신"과 "안정적"은 늘 같은 말이 아닙니다.
시사점
OpenSSL 4.0.0은 미래를 향한 버전입니다. ECH 같은 최신 보안 기능은 분명 반갑고, 낡은 요소를 정리한 방향도 건강합니다. 다만 그 대가로 레거시 호환성은 줄었습니다.
그래서 결론은 단순합니다. 새 기능이 필요한 팀은 테스트 환경에서 빠르게 검증해볼 가치가 있습니다. 반대로 운영 우선 조직이라면 3.5 LTS를 유지하면서 4.0 호환성 점검을 병행하는 편이 안전합니다.
보안 라이브러리 업그레이드는 늘 "새 장난감"보다 "숨은 깨짐"이 더 중요합니다. OpenSSL 4.0.0은 분명 강력하지만, 도입 전 체크리스트가 반드시 따라붙는 버전입니다.
참고
2OpenSSL 4.0 Beta Release Announcement
3OpenSSL 4.0 Released with ECH Support and Significant Legacy Code Removal
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.