OpenSSL

1. 개요

OpenSSL은 인터넷에서 사용되는 암호화 도구를 제공하기 위해 1998년에 설립된 프로젝트이다. SSLeay를 기반으로 하며, 다양한 암호화 알고리즘과 프로토콜을 지원한다. 2018년 버전 3.0으로 주요 버전 번호를 변경하면서 아파치 라이선스를 채택했다. OpenSSL은 자원봉사자 중심의 프로젝트로, 기부에 의존하며, 주요 취약점과 비판이 존재한다. 하트블리드, CCS Injection 취약점 등 보안 문제와 API 호환성 문제, 릴리스 지연, 성능 저하 등의 비판을 받았다. LibreSSL, BoringSSL, AWS-LC 등 OpenSSL을 포크한 프로젝트도 존재한다.

2. 프로젝트 역사

OpenSSL 프로젝트는 인터넷에서 사용되는 암호화 도구를 자유롭게 사용할 수 있도록 1998년에 설립되었다. 이 프로젝트는 에릭 앤드류 영과 팀 허드슨이 개발한 SSLeay를 기반으로 하며, 영과 허드슨이 RSA 시큐리티에서 일하게 되면서 1998년 12월 17일에 SSLeay의 공식 개발은 종료되었다. 초기 창립 멤버는 마크 콕스, 랄프 엥겔셜, 스티븐 헨슨, 벤 로리, 그리고 폴 서튼이었다.

2018년, OpenSSL 버전 번호는 1.1.1에서 3.0.0으로 변경되었는데, 이는 OpenSSL 모듈과의 충돌을 피하기 위해 2를 주요 버전 번호에서 제외했기 때문이다. 버전 3.0.0부터 아파치 라이선스를 사용하기 시작했다.

2019년 5월 기준으로, OpenSSL 관리 위원회는 7명, 커밋 권한을 가진 개발자는 17명으로 구성되어 있다. 이들 중 다수는 OpenSSL 관리 위원회에도 소속되어 있다. 정규직 직원은 2명뿐이며, 나머지는 자원봉사자이다.

이 프로젝트는 연간 1 미만의 예산으로 운영되며, 주로 기부에 의존한다. TLS 1.3 개발은 아카마이가 후원했다.

3. 주요 버전 배포 현황

OpenSSL의 주요 버전별 출시일과 특징은 다음과 같다.

2018년에 OpenSSL 버전 번호는 1.1.1에서 3.0.0으로 변경되었는데, 이는 OpenSSL의 모듈 중 하나와의 충돌을 피하기 위해 2를 주요 버전 번호에서 제외했기 때문이다. 버전 3.0.0은 아파치 라이선스를 처음 사용했다.

3.1. 세부 버전 정보

wikitext

4. 지원 알고리즘

OpenSSL은 다양한 암호화 알고리즘을 지원하며, 크게 암호, 해시 함수, 공개 키 암호 방식으로 나눌 수 있다.

* 암호: AES, 블로피시, Camellia, CAST-128, DES, IDEA, RC2, RC4, RC5, 트리플 DES, GOST 28147-89 등이 있다.
* 해시 함수: MD5, MD2, SHA-1, SHA-2, MDC-2 등이 있다.
* 공개 키 암호 방식: RSA, DSA, 디피-헬만 키 교환, 타원 암호, GOST R 34.10-2001 등이 있다.

4.1. 프로토콜

SSL 3.0, TLS (1.0, 1.1, 1.2, 1.3), DTLS (1.0, 1.2)

4.2. 대칭키 암호

AES, 블로우피쉬, 카멜리아, 차차20, 폴리1305, SEED, 캐스트-128, DES, IDEA, RC2, RC4, RC5, 트리플 DES, GOST 28147-89, SM4

4.3. 해시 함수

MD5, MD4, MD2, SHA-1, SHA-2, SHA-3, RIPEMD-160, MDC-2, GOST R 34.11-94, BLAKE2, 와일풀, SM3

4.4. 공개 키 암호 방식

RSA, DSA, 디피-헬만 키 교환, 타원 곡선, X25519, Ed25519, X448, Ed448, GOST R 34.10-2001, SM2

5. FIPS 140 인증

OpenSSL은 미국 연방 정보 처리 표준 (FIPS 140) 인증을 받은 암호화 모듈을 제공한다. FIPS 140은 암호화 모듈의 보안 요구 사항을 규정하는 표준이다. OpenSSL FIPS Object Module은 FIPS 140-2 인증을 획득했으며, OpenSSL 1.0.1 및 1.0.2 버전에서 사용 가능하다. OpenSSL 3.0은 FIPS 모드를 복원하고 FIPS 140-2 테스트를 거쳤다.

OpenSSL은 미국 국립표준기술연구소(NIST)의 [암호 모듈 검증 프로그램](en:Cryptographic Module Validation Program)에 따른 컴퓨터 보안 표준인 FIPS 140-2에서 승인된 최초의 오픈 소스 프로그램이다.

최초 승인은 2006년 1월에 이루어졌다. 같은 해 7월에는 "승인된 모듈에 의한 외부 프로그램과의 상호 작용에 관해 의문이 제기되었다"는 이유로 한 번 철회되었지만, 이듬해 2007년에 다시 승인이 이루어졌다.

6. 라이선스

OpenSSL은 OpenSSL 라이선스와 SSLeay 라이선스, 이중 라이선스로 제공되었으며, 이는 두 라이선스 중 어느 조건을 사용해도 된다는 것을 의미한다. OpenSSL 라이선스는 아파치 라이선스 1.0이며, SSLeay 라이선스는 4조항 BSD 라이선스와 유사하다.

OpenSSL 라이선스는 아파치 라이선스 1.0이었고 아파치 라이선스 2.0이 아니었기 때문에, 광고 자료와 재배포 시 "본 제품에는 OpenSSL Toolkit에서 사용하기 위해 OpenSSL 프로젝트에서 개발한 소프트웨어가 포함되어 있습니다"라는 문구를 표시해야 했다. 이러한 제약 때문에 OpenSSL 라이선스와 아파치 라이선스 1.0은 GNU GPL과 호환되지 않는다.

일부 GPL 개발자는 OpenSSL을 자체 시스템과 함께 사용할 수 있도록 명시적으로 허용하는 OpenSSL 예외를 라이선스에 추가했다. GNU Wget과 climm은 모두 이러한 예외를 사용한다. 일부 패키지 (예: Deluge)는 라이선스의 시작 부분에 예외를 문서화하는 추가 섹션을 추가하여 GPL 라이선스를 명시적으로 수정한다. 다른 패키지는 동일한 작업을 수행하는 LGPL 라이선스 GnuTLS, BSD 라이선스 Botan 또는 MPL 라이선스 NSS를 사용한다.

OpenSSL은 2015년 8월에 대부분의 기여자가 기여자 라이선스 계약 (CLA)에 서명해야 하며, OpenSSL은 결국 재라이선스를 아파치 라이선스 2.0의 조건으로 할 것이라고 발표했다. 이 과정은 2017년 3월에 시작되었으며, 2018년에 완료되었다.

2021년 9월 7일, OpenSSL 3.0.0이 아파치 라이선스 2.0으로 출시되었다. OpenSSL v3.0.0 미만 버전은 OpenSSL 라이선스와 SSLeay 라이선스 두 가지 라이선스 하에 공개되었다. OpenSSL v3.0.0 이후 버전은 Apache 라이선스 Version 2.0만 적용된다. OpenSSL 라이선스는 Apache 라이선스, Version 1.0이며, SSLeay 라이선스는 광고 조항이 있는 4조항 BSD 라이선스이다. 일반적으로 듀얼 라이선스에서는 사용자가 두 가지 라이선스 중 하나를 선택할 수 있지만, OpenSSL 설명에 따르면 두 라이선스가 모두 적용된다는 의미이다.

OpenSSL v3.0.0 미만 버전의 OpenSSL 라이선스는 Apache 라이선스 Version 2.0이 아닌 Apache 라이선스 Version 1.0 (OpenSSL v3.0.0 이후 버전은 Apache 라이선스 Version 2.0만 적용)이므로, "이 제품은 OpenSSL 툴킷을 이용하기 위해 OpenSSL 프로젝트에서 개발한 소프트웨어를 포함하고 있습니다."라는 문구를 재배포 시 포함해야 하며, GNU 일반 공중 사용 허가서(GPL)와 호환되지 않는다. 그러나 The OpenSSL Project의 견해에 따르면, 많은 리눅스나 BSD 배포판에서 OpenSSL은 운영 체제의 일부를 이루고 있기 때문에 GPL의 제한이 적용되지 않는다고 한다. 일부 프로젝트에서는 "OpenSSL 예외"를 추가하여 시스템에서 실행할 수 있도록 하고 있다. GNU Wget과 climm^영어 프로젝트가 그러한 예이다.

7. 주요 취약점

OpenSSL은 과거 여러 심각한 보안 취약점이 발견되어 사용자들에게 큰 영향을 미쳤다. 주요 취약점은 다음과 같다:

* 하트블리드 (Heartbleed): TLS 하트비트 확장의 구현에 존재했던 메모리 처리 버그이다. 매 하트비트마다 최대 64KB의 메모리가 노출되어, 공격자가 서버의 개인 키 등 민감한 정보에 접근하여 중간자 공격이나 세션 하이재킹을 할 수 있었다. 2014년 4월 7일 공개 당시, 인터넷 보안 웹 서버의 약 17%가 취약했다.

* CCS Injection 취약점 (CVE-2014-0224): 키 재료에 사용되는 OpenSSL 메서드의 약점을 이용한 보안 우회 취약점이다. 중간자 공격으로 트래픽 해독 및 수정이 가능했다. 0.9.8za, 1.0.0m, 1.0.1h 이전 버전의 OpenSSL 클라이언트와 1.0.1, 1.0.2-beta1 버전의 서버가 취약했다.

* 데비안 취약 키: 데비안 배포판에서 OpenSSL 패치 과정 중 발생한 오류로, 생성 가능한 개인 키 개수가 32,768개로 제한되어 난수 생성기가 손상되었다. 2006년 9월 17일 릴리스된 데비안 버전(0.9.8c-1)부터 포함되었으며, 우분투 등 데비안 기반 배포판에도 영향을 미쳤다.

* 기타 취약점:

* 2003년 11월 4일 발견: 특정 ASN.1 시퀀스로 인해 윈도우에서 OpenSSL 충돌 발생.
* 잘못된 형식의 ClientHello 메시지를 통한 DoS 공격 유발 가능 (CVE-????-????).
* 신뢰할 수 없는 DER 형식 데이터 처리 시 취약점 (2012년 4월 19일 발견).
* SSL, TLS, DTLS에서 CBC 암호 모음 처리 중 시간 공격에 취약 (2013년 2월 5일 발견).
* 잘못된 서명 알고리즘으로 인한 DoS 공격 가능.
* 특정 상황에서 Diffie–Hellman 키 복구 가능.
* DROWN 공격: SSLv2 사용 시 TLS 연결 해독 가능.

7.1. 하트블리드 (Heartbleed)

OpenSSL 1.0.1부터 1.0.1f 버전까지는 TLS 하트비트 확장의 구현에 심각한 메모리 처리 버그가 있어, 매 하트비트마다 최대 64KB의 응용 프로그램 메모리를 노출시킬 수 있었다(). 공격자는 웹 서버의 메모리를 읽어 서버의 개인 키를 포함한 민감한 데이터에 접근할 수 있었다. 이를 통해 공격자는 암호화 프로토콜이 완전 순방향 비밀성을 보장하지 않는 경우, 이전에 도청된 통신을 해독할 수 있었다. 개인 키를 알게 되면, 공격자는 향후 모든 통신에 대해 중간자 공격을 수행할 수 있었다. 이 취약점은 또한 세션 쿠키 및 비밀번호를 포함한 다른 사용자의 민감한 요청 및 응답의 암호화되지 않은 부분을 노출하여 공격자가 서비스의 다른 사용자의 ID를 하이재킹할 수 있게 할 수 있었다.

2014년 4월 7일 공개 당시, 인증 기관에 의해 인증된 인터넷 보안 웹 서버의 약 17% (50만 대)가 공격에 취약한 것으로 여겨졌다. 하트블리드는 서버와 클라이언트 모두에 영향을 미칠 수 있다.

2014년 4월 7일에 OpenSSL의 1.0.2-beta 및 1.0.1 계열에서 TLS의 heartbeat 확장에 메모리 처리에 버그가 있다는 것이 발표되었다 . 이 버그를 이용하면 하트비트 1회당 64킬로바이트의 메모리를 읽을 수 있게 된다 . 이 문제의 CVE 번호는 CVE-2014-0160이다 .

이 취약점은 2011년 12월 31일부터 존재했으며, OpenSSL 1.0.1이 출시된 2012년 3월 14일 이후 취약한 OpenSSL이 널리 사용되고 있다 . 서버 측의 메모리를 읽음으로써 기밀 정보에 접근할 수 있게 되어, 비밀 키를 도난당하여 암호화가 무력화되고 중간자 공격을 가할 수 있게 된다.

사용자에 관한 비공개 정보 (예: 세션 쿠키나 비밀번호)도 유출될 수 있으므로, 다른 사람으로 위장하는 것도 가능하게 된다 . 취약점이 판명된 시점에서 인증 기관으로부터 인증을 받은 HTTPS 서버 중 약 17%가 영향을 받는 것으로 보인다 .

기본적인 대책은 하트비트를 사용하지 않거나(-DOPENSSL_NO_HEARTBEATS 옵션을 붙여 다시 컴파일한다) 취약점을 수정한 버전(1.0.1g 이후)으로 업데이트하는 것이다 .

7.2. CCS Injection 취약점 (CVE-2014-0224)

CCS Injection 취약점()은 키 재료에 사용되는 OpenSSL 메서드의 약점에서 비롯된 보안 우회 취약점이다.

이 취약점은 중간자 공격을 사용하여 악용될 수 있으며, 공격자는 전송 중인 트래픽을 해독하고 수정할 수 있다. 원격 인증되지 않은 공격자는 특별히 조작된 핸드셰이크를 사용하여 약한 키 재료를 사용하도록 강제함으로써 이 취약점을 악용할 수 있다. 성공적인 악용은 공격자가 잠재적으로 민감한 정보에 접근할 수 있는 보안 우회 조건을 초래할 수 있다. 이 공격은 취약한 클라이언트 및 서버 간에만 수행될 수 있다.

OpenSSL 클라이언트는 0.9.8za, 1.0.0m 및 1.0.1h 버전 이전의 모든 OpenSSL 버전에서 취약하다. 서버는 OpenSSL 1.0.1 및 1.0.2-beta1에서만 취약한 것으로 알려져 있다. 1.0.1 이전의 OpenSSL 서버 사용자는 예방 차원에서 업그레이드하는 것이 좋다. 2014년 6월 6일, 지난 10년 이상에 걸쳐 모든 OpenSSL 버전에 대해 ChangeCipherSpec 메시지의 처리 순서가 부적절하여 공격자가 의도하는 약한 암호로 강제 변경된 통신으로 시작되는 공격 방법이 발견되어 CCS Injection 취약점(CCS Injection Vulnerability, CVE-2014-0224)으로 공개되었다.

이 취약점은 과거의 OpenSSL 대부분의 버전에 존재하며, 통신 시작 절차 도중에 부정한 신호를 보내면 해당 통신에 사용되는 임시 암호 키를 제3자도 예측할 수 있게 된다. 취약점 발견 경위는 발견자에 의해 공개되어 있다.

7.3. 데비안 취약 키

OpenSSL의 의사 난수 생성기는 복잡한 프로그래밍 방식을 사용하여 엔트로피를 획득한다. 데비안 배포판의 유지보수 담당자는 Valgrind 분석 도구가 관련 경고를 발급하지 않도록 하기 위해 OpenSSL 제품군의 데비안 변형에 패치를 적용했는데, 이로 인해 생성할 수 있는 개인 키의 총 개수를 32,768개로 제한하여 의도치 않게 난수 생성기가 손상되었다. 이 손상된 버전은 2006년 9월 17일 데비안 릴리스(버전 0.9.8c-1)에 포함되었으며, 우분투 등 다른 데비안 기반 배포판에도 영향을 미쳤다. 즉시 사용 가능한 익스플로잇이 쉽게 구할 수 있게 되었다.

이 오류는 2008년 5월 13일 데비안에 의해 보고되었다. 데비안 4.0 배포판(etch)에서는 이러한 문제가 버전 0.9.8c-4etch3에서 수정되었으며, 데비안 5.0 배포판(lenny)에 대한 수정 사항은 버전 0.9.8g-9에서 제공되었다. Valgrind를 OpenSSL에도 적용할 수 있도록 하기 위해 데비안 배포판에 포함된 OpenSSL에 패치를 적용했는데, 이 과정에서 실수로 의사 난수 생성기가 제대로 작동하지 않아 생성되는 암호 키가 예측 가능한 것으로 되어 버렸다.

이 버그는 2006년 9월 17일에 릴리스된 데비안 (OpenSSL 0.9.8c-1)부터 포함되어 있었으며, 버그가 발견되어 데비안에서 발표된 것은 2008년 5월 13일이었다. 데비안 계열 이외의 시스템을 포함해 문제가 된 데비안에서 생성한 키를 사용하고 있는 경우에는 취약점이 없는 OpenSSL로 키를 다시 생성해야 한다. 이 버그는 데비안 4.0 (etch)에서는 OpenSSL의 0.9.8c-4etch3 이후, 데비안 5.0 (lenny)에서는 0.9.8g-9에서 수정되었다.

7.4. 기타 취약점

OpenSSL 0.9.6k에는 2003년 11월 4일에 발견된 버그가 있었는데, 특정 ASN.1 시퀀스가 윈도우 머신에서 많은 수의 재귀 호출을 발생시키는 문제였다. 윈도우는 대량의 재귀 호출을 제대로 처리할 수 없었고, 그 결과 OpenSSL이 충돌했다. 임의로 많은 수의 ASN.1 시퀀스를 보낼 수 있으면 OpenSSL이 충돌하게 되었다.

클라이언트가 핸드셰이크를 생성할 때 잘못된 형식의 ClientHello 메시지를 보내면, OpenSSL이 메시지 끝을 넘어 파싱할 수 있었다. 이 취약점은 CVE 프로젝트에서 식별되었으며, OpenSSL 버전 0.9.8h부터 0.9.8q까지, 그리고 OpenSSL 1.0.0부터 1.0.0c까지의 모든 버전에 영향을 미쳤다. 파싱 과정에서 잘못된 메모리 주소에 대한 읽기가 발생할 수 있으므로, 공격자는 DoS 공격을 유발할 수 있었다. 또한 일부 애플리케이션이 파싱된 OCSP 확장의 내용을 노출하여, 공격자가 ClientHello 이후의 메모리 내용을 읽을 수 있게 할 수도 있었다.

Basic Input/Output(BIO) 또는 FILE 기반 함수를 사용하여 신뢰할 수 없는 DER 형식 데이터를 읽을 때 OpenSSL은 취약했다. 이 취약점은 2012년 4월 19일에 발견되었으며 CVE 식별자 가 할당되었다. OpenSSL의 SSL/TLS 코드에는 직접적인 영향을 미치지 않았지만, ASN.1 함수(특히 d2i_X509 및 d2i_PKCS12)를 사용하는 모든 응용 프로그램도 영향을 받지 않았다.

SSL, TLS, DTLS에서 CBC 암호 모음을 처리하는 과정에서 OpenSSL은 MAC 처리 중 시간 공격에 취약한 것으로 밝혀졌다. 나뎀 알파르단(Nadhem Alfardan)과 케니 패터슨(Kenny Paterson)이 이 문제를 발견하고, 2013년 2월 5일에 연구 결과를 발표했다. 이 취약점에는 CVE 식별자 가 할당되었다.

취약점은 누구나 인증서를 가져와 그 내용을 읽고 정확하게 수정하여 인증서가 클라이언트 또는 서버를 충돌시키는 방식으로 악용할 수 있게 했다. 클라이언트가 OpenSSL 1.0.2 서버에 연결하여 잘못된 서명 알고리즘 확장으로 재협상하면 널 포인터 역참조가 발생했다. 이는 서버에 대한 서비스 거부(DoS) 공격을 유발할 수 있었다. 스탠퍼드 보안 연구원 데이비드 라모스(David Ramos)는 개인적인 익스플로잇을 가지고 있었고 이를 OpenSSL 팀에 제시했으며, 이후 팀은 이 문제를 해결했다. OpenSSL은 해당 버그를 심각도가 높은 문제로 분류했으며, 버전 1.0.2가 취약한 것으로 확인되었다.

취약점은 특정 상황이 충족될 경우 OpenSSL 서버의 개인 Diffie–Hellman 키를 복구할 수 있게 했다. 어도비 시스템 보안 연구원 안토니오 산소(Antonio Sanso)가 이 취약점을 비공개로 보고했다. OpenSSL은 이 버그를 심각한 문제로 분류했으며, 버전 1.0.2만 취약한 것으로 확인되었다.

Decrypting RSA with Obsolete and Weakened eNcryption (DROWN) 공격은 SSLv2를 사용할 수 있도록 설정하면, 공격자가 동일한 비밀 키를 공유하는 SSLv2가 유효한 서버에 프로브를 전송하여, 새로운 프로토콜인 TLS를 사용한 클라이언트와 서버 간의 연결을 해독할 수 있다는 것이다. 예상되는 영향은 원격 공격자에게 SSLv2를 지원하는 서버의 암호 통신이 해독될 우려가 있다는 것이다. SSLv2를 지원하고 TLS 통신에서 SSLv2와 동일한 인증서를 사용하는 경우, TLS의 암호 통신이라 하더라도 유사한 영향을 받을 수 있다. 이 공격에 대처한 패치는 1.0.1s 또는 1.0.2.g이다. SSLv2 자체는 2011년부터 비권장되고 있다.

8. 포크

2014년 4월, 하트블리드 사태 이후, OpenBSD 프로젝트는 OpenSSL 1.0.1g를 포크하여 LibreSSL 프로젝트를 시작했다.

구글(Google)은 2014년 6월에 OpenSSL의 자체 포크인 BoringSSL(BoringSSL)을 발표했다. 구글은 OpenSSL 및 LibreSSL 개발자와 협력할 계획이며, 이후 BoringSSL을 기반으로 Tink(Tink)를 개발했다.

2020년 9월, AWS(AWS)는 AWS 암호화 팀에서 유지 관리하는 범용 암호화 라이브러리를 출시했다. 이는 OpenSSL 및 BoringSSL 프로젝트의 코드를 기반으로 한다.

8.1. LibreSSL

OpenBSD 프로젝트는 하트블리드 문제를 계기로, 2014년 4월에 OpenSSL 1.0.1g를 기반으로 포크한 LibreSSL을 시작했다。이는 OpenBSD에서 사용되는 OpenSSL 라이브러리를 대체하는 것을 목표로 하며, OpenSSL 코드를 검토하여 더욱 안전한 구현을 목표로 한다.

OpenBSD에서 불필요한 코드와 오래된 시스템 지원을 위한 코드를 삭제하여 90,000 라인 이상의 소스 코드를 줄였다。

2014년 7월 11일에 LibreSSL 2.0.0이 릴리스되었다。

8.2. BoringSSL

구글은 2014년 6월에 OpenSSL을 포크한 BoringSSL의 출시를 발표했다. 구글은 OpenSSL, LibreSSL 양쪽 개발자와 협력해 나갈 것이라고 밝혔다.
* https://boringssl.googlesource.com/boringssl/ boringssl - Git at Google

9. 비판

개발자 커뮤니티에서는 OpenSSL이 새로운 주요 버전마다 API 호환성이 깨지는 것으로 자주 언급되며, 이는 새로운 버전 채택을 지연시키는 소프트웨어 적응을 필요로 한다. 이전 릴리스가 새로운 주요 릴리스 후 일반적으로 2년 이상 유지 관리되지 않는다는 사실과 결합되어, 일부 벤더는 새로운 릴리스로 업데이트할 시간이 거의 없는 상태에서 소프트웨어 마이그레이션을 매우 일찍 예상해야 하며, 기존 소프트웨어와의 일부 호환성을 잃거나 회귀의 위험을 감수해야 하는 경우도 있다.

장기 지원(LTS) 릴리스는 5년 동안 유지 관리되지만, 릴리스 간의 누적된 지연으로 인해 운영 체제 공급업체는 마지막으로 지원되는 릴리스를 더 오래 유지해야 하는 경향이 있으며, 새 버전이 출시될 때 여유가 줄어든다. 예를 들어 OpenSSL 3.0은 처음에 2019년 4분기에 출시될 것으로 예상되었지만, 결국 21개월 후에 출시되었으며, 이전에 지원되었던 버전 1.1.1에 대한 예상 지원 종료일을 연장하지 않았다. 이는 기존 소프트웨어에 대한 적응이 필요한 상당한 변경 사항에도 불구하고 발생했다.

버전 1.1.1의 축소된 지원 지연은 성능에 민감한 워크로드를 가진 사용자들에게 더 큰 우려를 야기한다. 3.0 버전이 정식 출시된 지 얼마 지나지 않아, 일부 사용자들은 다중 스레드 환경에서 이 버전에 심각한 성능 저하가 발생한다고 보고하기 시작했으며, 많은 경우 빈번한 저수준 작업에서 비효율적인 잠금 사용을 언급하며 80배에서 400배까지의 속도 저하를 지적했다. OpenSSL 팀은 이러한 대규모 성능 저하 보고서를 통합하기 위해 메타 이슈를 생성했다. 이들 중 약 절반은 이전 버전 1.1.1에 남은 제한된 지원 시간으로 인한 문제에 더해, 이전 버전에서 3.0으로 업그레이드하는 것이 불가능하다고 언급했다.

QUIC 전송 계층이 HTTP 프로토콜의 세 번째 버전을 지원하기 위해 작업 중일 때, 보안을 제공하기 위해 TLS를 사용하는 것이 제안되었고, TLS 라이브러리에 대한 몇 가지 조정이 필요하다는 것이 확인되었다. 이러한 수정 사항은 당시 QUIC 개발자들이 주로 사용하던 라이브러리인 BoringSSL에 적용되었고, 이후 다른 라이브러리로 이식되었다. 이 작업의 포트는 빠르게 OpenSSL에 제안되었다. 같은 날 논의가 시작되었지만, 라이선스 고려 사항으로 인해 빠르게 중단되었고, 이러한 우려가 해소된 후 보류되었다. 마침내 10개월 후 OpenSSL 관리 위원회는 블로그 게시물을 통해 API가 시간이 지남에 따라 변경될 것이라는 우려로 인해 이 패치 세트가 3.0에 채택되지 않을 것이라고 발표했다. 3.0 출시가 계획되었지만 1년이 넘도록 나오지 않은 상황에서, 아카마이(Akamai)와 마이크로소프트(Microsoft)의 자원 봉사자 팀은 QuicTLS로 프로젝트를 포크하고 QUIC 개발을 차단 해제하기 위해 OpenSSL 코드 위에 이러한 패치를 지원하기로 결정했다. 이 조치는 일반적으로 커뮤니티에서 환영받았다. OpenSSL 3.0이 최종 출시된 후, QUIC 패치 세트는 재검토되었으나 반대 결정이 내려졌고, 커뮤니티 내에서 수십에서 수백 건의 실망스러운 반응을 야기했다. 풀 리퀘스트는 종료되었고, 사용자들은 공개적으로 실망감을 표현하거나, 운영 체제 공급업체에게 대안인 QuicTLS 포크를 지원해 달라고 요청하거나, 대안 솔루션을 찾고 있다는 것을 느꼈다. QuicTLS 포크의 공동 창립자인 Rich Salz는 QuicTLS에서 포크된 Apache 프로젝트를 보고 싶다는 관심을 발표했다. 2023년 2월 25일 현재, 최종 사용자가 소스에서 직접 다시 빌드하지 않아도 운영 체제에서 기본적으로 사용할 수 있는 QUIC 호환 장기 지원 TLS 라이브러리는 아직 없다.