요약
OpenSSL 4.1.0이 DTLS 1.3 지원과 양자내성 암호 최적화를 담아 나왔습니다.
OpenSSL 프로젝트가 10월 23일 새 기능을 더한 기능 릴리스로 4.1.0을 공개했습니다. 릴리스 노트에는 호환성을 깰 수 있는 변경과 아직 고치지 못한 문제도 함께 적혀 있습니다.
왜 중요한가
- DTLS(UDP 위에서 쓰는 TLS)의 최신판 1.3을 가장 널리 쓰이는 암호 라이브러리에서 쓸 수 있게 됐습니다.
- 다만 DTLS 1.3은 패킷이 손실될 때 생기는 문제가 남아 있어 실제 서비스에 넣기 전에 확인이 필요합니다.
- 오래된 빌드 대상과 설정 옵션이 빠져서, 이를 쓰던 곳은 업그레이드 전에 빌드 설정을 바꿔야 합니다.
핵심 내용
- DTLS 1.3(RFC 9147)과 GREASE(서버의 잘못된 확장 처리를 드러내려 임의 값을 섞어 보내는 기법)를 지원합니다.
- x86_64와 ppc64le에서 ML-DSA·ML-KEM(양자내성 암호 알고리즘)과 AES-CBC 복호화를 빠르게 했습니다.
- SSL 리스너 API에서 DTLS를 쓸 수 있고, IKEv2 KDF와 Elbrus2000(e2k) 아키텍처 초기 지원이 더해졌습니다.
- Windows-on-Itanium과 Windows CE 빌드 대상을 없앴습니다.
- 실제로는 기능을 끄지 못하던 no-ecdsa·no-ecdh 옵션도 없앴고, 대신 no-ec를 쓰라고 안내했습니다.
HN 반응
- 3.0에서 생긴 성능 저하를 고쳤다는 말이 없다는 아쉬움이 나왔고, 많이 나아졌지만 1.1.1 수준은 아니라는 경험담과 이번 판에서 크게 개선됐다는 반론이 이어졌습니다.
- 새 앱은 대부분 QUIC을 쓰는데 왜 이제 DTLS 1.3이냐는 의문에는, 통신 업계가 양자내성 암호 규제 때문에 필요로 한다는 설명이 붙었습니다.
정말 추억의 물건이네요. 제가 알기로 Windows Server 2008 R2는 2020년까지 Itanium용 업데이트가 나왔고 유료 지원은 올해까지 이어졌거든요. 그 정도면 꽤 오래 버텼죠.
그동안 대체 뭘로 테스트했는지 궁금하네요. NetBSD조차 Itanium용 최신 릴리스가 없잖아요. HPPA가 어찌 보면 Itanium의 전신인데, NetBSD 11.0을 HPPA에서는 돌릴 수 있고 Itanium에서는 못 돌린다니 황당합니다.
나이보다는 현재 설치된 기기 수나 실제 사용자 수가 더 중요하겠죠.
십중팔구 "정부" 쪽일 겁니다. 거기는 늘 뒤처져 있고 레거시를 계속 끌어안고 있잖아요. 저는 예전에 서랍에서 Windows 1.0 플로피 디스크를 발견한 적도 있어요.
솔직히 Itanium보다 HPPA 장비가 테스트할 수 있는 게 더 많아요.
Microsoft(아니면 다른 대형 소프트웨어 회사든)가 새 기능을 계속 얹는 대신, 엔지니어들에게 기존 시스템을 리팩터링할 시간을 수십 년쯤 준다면 어떻게 될지 문득 궁금해집니다. 훨씬 깔끔한 코드, 더 나은 아키텍처, 안정적인 제품이 나올까요?
제가 마지막으로 매일 쓴 Windows는 Windows 7 Home(Windows Server 2008과 같은 시기)이었습니다. 사용자 입장에서 보면 이후 버전들은 기능 면에서 별로 나아진 게 없고, 들리는 얘기로는 버전이 새로 나올수록 더 엉성해지고 있다고 합니다.
새 기능 출시에 신경 쓰지 않는다 해도 그렇게 하지 않을 겁니다. Windows/Office 같은 MS의 오래된 핵심 제품 안에 있는 기술적 복잡성은 평범한 기술 부채, 즉 눈에 보이는 동작을 바꾸지 않고도 고칠 수 있는 것에서 비롯된 부분이 아주 적습니다. 복잡성의 대부분은 (이전 버전과의 호환성이든, 지금 잘 돌아가는 하드웨어·소프트웨어 조합과의 호환성이든) 호환성을 깨뜨리지 않는 것을 무슨 일이 있어도 우선하는 Microsoft의 방침 때문입니다.
그러니 그 호환성 우선순위를 바꾸지 않는 한, 리팩터링만 하는 10년은 거의 아무것도 이루지 못할 겁니다.
Microsoft는 NT에서 이미 정확히 그렇게 했어요. 망치는 건 그 위에 얹은 잡동사니죠.
Windows 사용자 모드 내부는 이미 상당히 리팩터링됐습니다. 앱이 링크하는 핵심 시스템 DLL 중 상당수가 이제는 실제 구현으로 넘겨주는 리디렉트일 뿐입니다. 어설픈 부분은 대부분 UI에 있는 것 같습니다.
빅 엔디언 x86_64를 유지해 줘서 그나마 다행이에요.
https://github.com/openssl/openssl/blob/c69b5af10a754051274ef2e5ed17f47753bd6ea9/crypto/whrlpool/wp_block.c#L112
Stratus를 언급한 게 맞는지는 잘 모르겠습니다. 빅 엔디언 x86-64는 HPE NonStop에 실제로 존재합니다.
“HPE Nonstop Compute의 OSS에서 동작하는 실행 파일 형식은 ELF64-bit, Big_Endian, X86_64입니다.”
https://inbox.sourceware.org/gcc-help/AM7PR02MB6483A12F6B98DD168CBF7013C702A@AM7PR02MB6483.eurprd02.prod.outlook.com/
"3.0에서 생긴 과도한 성능 저하 중 일부를 고쳤습니다"라는 말은 안 보이네요. 아쉽습니다...
배경은 이 글을 보세요. https://cryptography.io/en/latest/statements/state-of-openssl/
3.0 초기에 비하면 상당히 좋아졌습니다. 1.1.1 수준의 성능으로 돌아가진 못했지만, 대부분의 사람에게는 아마 치명적인 문제가 될 정도는 아닐 겁니다.
그래도 성능이 후퇴했다는 건 여전히 안타깝습니다.
감을 잡으시라고 말씀드리면, 3.x 초기 버전에서는 개인 키 파싱이 70배나 느려진 걸 제가 확인했습니다. 지금 버전에서는 8배쯤 느린 것 같고요. 그래도 여전히... 많이 느립니다. 그럴 만한 이유도 없이요.
요즘은 AWS-Lc가 OpenSSL을 대체할 유망한 후보로 보입니다.
저도 알아보고 솔깃했습니다. 읽기 락이 줄고 RNG 성능도 더 좋더라고요. 그런데 제가 봇 탐지에 쓰는 SSL_get1_curves() API를 빼 버렸고, nginx와 모든 모듈을 곳곳에서 다시 컴파일해야 해서 결국 갈아탈 만큼 끌리지는 않았습니다. 나이가 들어서 제가 그냥 더 게을러진 건지도 모르겠네요.
저희는 실제 트래픽의 일부를 AWS-LC와 Wolfssl이 돌아가는 엔드포인트로 보내 보는 것까지 포함해 여러 테스트를 했습니다. 기술적으로 OpenSSL 3.X가 느린 건 맞고, 측정도 되지만, 그걸 감수하고 갈아탈 만큼은 아니었습니다. 어디까지나 저희 사용 사례 기준이고, 하드웨어가 다르거나 트래픽이 훨씬 많아서 갈아탈 가치가 있는 곳도 충분히 있을 겁니다. haproxy에서 기본적인 TLS 종단 처리를 하는 정도라면 저희에게는 그럴 가치가 없었습니다.
정확히 어느 버전의 OpenSSL이냐에 따라서도 다릅니다. 저희도 여러 버전의 openssl로 비슷한 테스트를 했습니다. 저희가 쓰는 LTS 배포판의 공식 패키지에 들어 있던 Openssl 3.0은 받아들일 수 없을 만큼 느렸습니다. 3.4에서는 여전히 1.1.1보다 나빴지만 감수할 만한 수준의 성능 저하였습니다.
하드웨어와 사용 방식에 따라서도 분명히 달라집니다. 성능 저하의 주된 원인이 락 경합 증가라서, 더 많은 코어에서 더 많은 스레드를 돌릴수록 체감이 커집니다.
시간을 아끼는 게 잘못은 아니죠!
PyCA와 haproxy가 비판한 영역 일부에서는 성능이 크게 개선됐습니다. X.509 처리도 평균적인 경우에는 더 빨라질 것이고, 4.2에서 더 많은 개선이 계획돼 있습니다.
https://openssl2026.sched.com/event/2VSQR/performance-the-little-sibling-of-cryptography 와 슬라이드 https://2026.openssl-conference.org/slides/2026-d3-1400-performance-the-little-sibling-of-cryptography.pdf 를 보세요. 녹화본도 곧 올라올 겁니다.
너무 늦은 데다 너무 부족하다고 생각합니다. 사람들은 이미 떠나기 시작했어요. https://www.haproxy.com/blog/state-of-ssl-stacks
여담인데, 이런 글에 들어가는 자물쇠나 톱니바퀴, 아니면 관련 없는 작은 복셀 아트 같은 랜덤 그림은 대체 뭐 하러 넣는 건지 늘 궁금했습니다. LLM이 나오기 전에도 이런 그림은 흔한 스톡 이미지인지 누가 직접 그린 건지에 따라 도움이 되기도 하고 안 되기도 했습니다.
그런데 이제는 LLM 덕분에 맞춤 제작이 쉬워졌는데도, 사람들이 왜 그 그림이 거기 있어야 하는지는 더 이상 생각하지 않는 것 같습니다. 그런 그림이 들어간 글이라면 아마 어느 정도 정성이나 고민이 부족하다는 신호일 테니, 저는 나머지 내용까지 은연중에 낮게 보게 됩니다.
블로그 템플릿 대부분과 소셜 미디어에서는 썸네일용 이미지가 사실상 필수잖아요.
SEO 극대화죠.
제가 쓰는 소프트웨어 프로젝트 중에 아직도 perl이 있어야 하는 건 이게 유일한 것 같아요.
DTLS 1.3은 1.2보다 효율성과 단순성이 크게 좋아졌습니다. OpenSSL 구현이 어떤지는 제가 말씀드릴 수 없지만, 마침내 지원이 나왔다는 것 자체는 반가운 소식입니다.
다만 아쉽게도 OpenSSL이 제공하는 데모 코드는 클라이언트 연결마다 스레드를 하나씩 만드는 단순화된 구현을 씁니다.
https://github.com/openssl/openssl/blob/master/demos/dtlslistenerecho/main.c
libuv나 libevent와 통합돼 있다면 훨씬 실용적일 텐데요.
여러분, 이번 주 일도 있었으니 앞으로는 제목에 좀 더 자세히 적어 주면 안 될까요? "보세요! 멋진 OpenSSL 새 기능" 같은 식으로요. 그래야 릴리스 노트를 열면서 치명적인 CVE 패치 얘기가 나올까 봐 트라우마에 시달리는 일이 없죠.
제가 알기로는 대부분의 새 애플리케이션이 QUIC 데이터그램 모드를 기본으로 쓰는 추세인데, 이런 때에 DTLS 1.3 지원을 새로 추가한다니 흥미롭네요. 저는 DTLS 1.3 기반으로 만든 게 있고 그래서 wolfssl을 쓰고 있는데, 이쪽도 한번 살펴봐야겠습니다.
듣기로는 통신 업계가 QUIC이 아니라 DTLS를 쓰고, 규제 때문에 결국 양자내성암호를 원하게 되니 DTLS 1.3이 필요하다고 합니다.