본문으로 이동

OpenSSL

위키백과, 우리 모두의 백과사전.
OpenSSL
개발자OpenSSL 프로젝트
발표일1998년(27년 전)(1998)
안정화 버전
안정판3.6.0[1] 위키데이터에서 편집하기 / 2025년 10월 1일
저장소
프로그래밍 언어C
운영 체제멀티 플랫폼
종류보안 라이브러리
라이선스아파치 라이선스 1.0, 4-clause BSD 라이선스
웹사이트http://www.openssl.org/

OpenSSL컴퓨터 망을 통한 보안 통신을 제공하여 도청을 방지하고, 통신 상대방을 식별하는 애플리케이션을 위한 소프트웨어 라이브러리이다. HTTPS 웹사이트의 대다수를 포함하여 인터넷 서버에서 널리 사용된다.

OpenSSL은 SSL 및 TLS 프로토콜의 오픈 소스 구현을 포함하고 있다. C 언어로 작성된 핵심 라이브러리는 기본적인 암호화 기능을 구현하고 다양한 유틸리티 함수를 제공한다. 다양한 컴퓨터 언어에서 OpenSSL 라이브러리를 사용할 수 있게 해주는 래퍼(wrapper)들도 이용 가능하다.

OpenSSL 소프트웨어 재단(OSF)은 기여자 라이선스 계약, 기부금 관리 등 대부분의 법적 용무에서 OpenSSL 프로젝트를 대표한다. 또한 OpenSSL 소프트웨어 서비스(OSS)는 지원 계약에 대해 OpenSSL 프로젝트를 대표한다.

OpenSSL은 리눅스, macOS, BSD를 포함한 대부분의 유닉스 계열 운영체제, 마이크로소프트 윈도우OpenVMS에서 사용할 수 있다.

프로젝트 역사

[편집]

OpenSSL 프로젝트는 인터넷에서 사용되는 코드에 대해 무료 암호화 도구 세트를 제공하기 위해 1998년에 설립되었다. 이는 에릭 앤드루 영(Eric Andrew Young)과 팀 허드슨(Tim Hudson)이 만든 SSLeay의 포크를 기반으로 하며, 에릭 앤드루 영과 팀 허드슨이 모두 RSA 시큐리티에서 일하게 되면서 1998년 12월 17일에 비공식적으로 개발이 종료되었다. 초기 창립 멤버는 마크 콕스(Mark Cox), 랄프 엥겔샬(Ralf Engelschall), 스티븐 헨슨(Stephen Henson), 벤 로리, 그리고 폴 서튼(Paul Sutton)이었다.[2]

2018년 OpenSSL 버전 번호는 1.1.1에서 3.0.0으로 건너뛰었는데, 이는 OpenSSL의 모듈 중 하나와의 충돌을 피하기 위해 주 버전 번호 2를 생략한 것이다. 버전 3.0.0은 아파치 라이선스를 사용한 첫 번째 버전이었다.

2019년 5월 기준,[3] OpenSSL 관리 위원회는 7명으로 구성되었으며[4] 커밋 권한을 가진 17명의 개발자가 있다[5] (이들 중 다수는 OpenSSL 관리 위원회의 일부이기도 하다). 전임 직원(펠로우)은 두 명뿐이었고 나머지는 자원봉사자였다.

2024년까지 직원은 14명으로 늘어났다.

이 프로젝트는 2024년에 총 550만 달러의 수입을 기록했다.[6] TLS 1.3의 개발은 아카마이의 후원을 받았다.[7]

주요 버전 출시

[편집]
OpenSSL 출시 역사[8][9]
버전 최초 출시일 지원 종료일[10] 비고 최종 마이너 버전
오래된 버전, 지원 중단: 0.9.1[11] 1998년 12월 23일 (1998-12-23)
  • OpenSSL 프로젝트의 공식 시작
0.9.1c (1998년 12월 23일)
오래된 버전, 지원 중단: 0.9.2[11] 1999년 3월 22일 (1999-03-22)
  • 0.9.1c의 후속
0.9.2b (1999년 4월 6일)
오래된 버전, 지원 중단: 0.9.3[11] 1999년 5월 25일 (1999-05-25)
  • 0.9.2b의 후속
0.9.3a (1999년 5월 27일)
오래된 버전, 지원 중단: 0.9.4[11] 1999년 8월 9일 (1999-08-09)
  • 0.9.3a의 후속
0.9.4 (1999년 8월 9일)
오래된 버전, 지원 중단: 0.9.5[11] 2000년 2월 28일 (2000-02-28)
  • 0.9.4의 후속
0.9.5a (2000년 4월 1일)
오래된 버전, 지원 중단: 0.9.6[11] 2000년 9월 24일 (2000-09-24)
  • 0.9.5a의 후속
0.9.6m (2004년 3월 17일)
오래된 버전, 지원 중단: 0.9.7[11] 2002년 12월 31일 (2002-12-31)
  • 0.9.6m의 후속
0.9.7m (2007년 2월 23일)
오래된 버전, 지원 중단: 0.9.8[11] 2005년 7월 5일 (2005-07-05)
  • 0.9.7m의 후속
0.9.8zh (2015년 12월 3일)
오래된 버전, 지원 중단: 1.0.0[12] 2010년 3월 29일 (2010-03-29)
  • 0.9.8n의 후속
1.0.0t (2015년 12월 3일 (2015-12-03))
오래된 버전, 지원 중단: 1.0.1[13] 2012년 3월 14일 (2012-03-14) 2016년 12월 31일 (2016-12-31)
  • 1.0.0h의 후속
  • TLS/DTLS 하트비트 지원[14]
  • SCTP 지원
  • TLS 키잉 데이터 엑스포터 지원[15]
  • SRTP를 위한 DTLS 키 설정 지원[16]
  • Next Protocol Negotiation
  • 인증서, 요청 및 인증서 폐기 목록(CRL)의 PSS 서명
  • CMS를 위한 패스워드 기반 수신자 정보 지원
  • TLS 1.2 및 TLS 1.1 지원
  • 검증되지 않은 2.0 FIPS 모듈을 위한 예비 FIPS 140 기능
  • Secure Remote Password protocol(SRP) 지원
1.0.1u (2016년 9월 22일 (2016-09-22))
오래된 버전, 지원 중단: 1.0.2[17] 2015년 1월 22일 (2015-01-22) 2019년 12월 31일 (2019-12-31) 1.0.2u (2019년 12월 20일 (2019-12-20))
오래된 버전, 지원 중단: 1.1.0[18] 2016년 8월 25일 (2016-08-25) 2019년 9월 11일 (2019-09-11)
  • 1.0.2h의 후속
  • BLAKE2 지원[19]
  • ChaCha20-Poly1305 지원[20]
  • X25519 지원[21]
  • DANE 및 인증서 투명성 지원
  • CCM 암호군 지원
  • 확장 마스터 시크릿 지원
  • SSLv2 제거
  • 커베로스 암호군 지원 제거
  • libssl의 기본(DEFAULT) 암호군에서 RC4 및 3DES 제거
  • 기본 암호 목록에서 DSS, SEED, IDEA, CAMELLIA, AES-CCM 제거
  • libssl에서 40 및 56비트 암호 지원 제거
  • FIPS 140 지원 제거
1.1.0l (2019년 9월 10일 (2019-09-10))
오래된 버전, 지원 중단: 1.1.1 LTS[22][23] 2018년 9월 11일 (2018-09-11) 2023년 9월 11일 (2023-09-11) (LTS) 1.1.1w (2023년 9월 11일)
오래된 버전, 지원 중: 3.0 LTS[26][27]
[note 1]
2021년 9월 7일 (2021-09-07) 2026년 9월 7일 (2026-09-07) (LTS) 개발 중
오래된 버전, 지원 중단: 3.1[29][30] 2023년 3월 14일 (2023-03-14) 2025년 3월 14일 (2025-03-14) 3.1.8 (2025년 2월 11일)
오래된 버전, 지원 중단: 3.2[31][32] 2023년 11월 23일 (2023-11-23) 2025년 11월 23일 (2025-11-23)
  • 클라이언트 측 QUIC 지원
  • TLS 인증서 압축 지원[33]
  • ECDSA의 결정론적 사용[34]
  • TLS 원시 공개 키 지원[35]
3.2.6 (2025년 9월 30일)
오래된 버전, 지원 중: 3.3[36] 2024년 4월 9일 (2024-04-09) 2026년 4월 9일 (2026-04-09) 개발 중
오래된 버전, 지원 중: 3.4[37] 2024년 10월 22일 (2024-10-22) 2026년 10월 22일 (2026-10-22) 개발 중
오래된 버전, 지원 중: 3.5 LTS[38] 2025년 4월 8일 (2025-04-08) 2030년 4월 8일 (2030-04-08) (LTS)
  • PQC 알고리즘 지원 (ML-KEM, ML-DSA 및 SLH-DSA)
  • 서버 측 QUIC 지원 (RFC 9000)
  • 0-RTT 지원을 포함한 서드파티 QUIC 스택 지원
  • 불투명 대칭 키 객체(EVP_SKEY) 지원 추가
  • RFC8422에서 지원이 중단된 TLS 그룹을 비활성화하는 새로운 설정 옵션 no-tls-deprecated-ec
  • FIPS 제공자가 JITTER 시드 소스를 사용하도록 하는 새로운 설정 옵션 enable-fips-jitter
  • CMP에서의 중앙 집중식 키 생성 지원
  • 다중 TLS 키 공유 지원 및 개선된 TLS 키 설정 그룹 구성 기능
  • 제공된 암호 알고리즘에서의 파이프라이닝 API 지원
개발 중
현재 안정화 버전: 3.6 2025년 10월 1일 (2025-10-01) 2026년 11월 1일 (2026-11-01) 개발 중
범례:
오래된 버전
오래된 버전, 지원 중
최신 버전
최신 미리보기 버전
배포 예정

알고리즘

[편집]

OpenSSL은 다양한 암호화 알고리즘을 지원한다.

암호
AES, Blowfish, Camellia, ChaCha20, Poly1305, SEED, CAST-128, DES, IDEA, RC2, RC4, RC5, 트리플 DES, GOST 28147-89,[39] SM4
암호화 해시 함수
MD5, MD4, MD2, SHA-1, SHA-2, SHA-3, RIPEMD-160, MDC-2, GOST R 34.11-94,[39] BLAKE2, Whirlpool,[40] SM3
공개 키 암호 방식
RSA, DSA, 디피-헬먼 키 교환, 타원곡선 암호, X25519, Ed25519, X448, Ed448, GOST R 34.10-2001,[39] SM2

(전방향 보안은 버전 1.0부터 타원곡선 디피-헬먼을 사용하여 지원된다.[41])

FIPS 140 검증

[편집]

FIPS 140은 암호화 모듈의 테스트 및 인증을 위한 미국 연방 프로그램이다. OpenSSL의 FOM 1.0에 대한 초기 FIPS 140-1 인증은 "검증된 모듈과 외부 소프트웨어 간의 상호작용에 대해 의문이 제기되었을 때"인 2006년 7월에 취소되었다. 이 모듈은 FIPS 140-2로 넘어가기 전인 2007년 2월에 재인증을 받았다.[42] OpenSSL 1.0.2는 FIPS 140-2 검증 환경에서 FIPS 승인 알고리즘을 제공하기 위해 구축된 OpenSSL FIPS 객체 모듈(FOM)의 사용을 지원했다.[43][44] OpenSSL은 FIPS 모드를 지원하는 유일한 OpenSSL 버전이라는 반대에도 불구하고, 1.0.2 아키텍처를 2019년 12월 31일자로 '지원 종료' 또는 'EOL'로 분류하기로 결정하여 논란이 되었다.[45] EOL 결과, 많은 사용자가 FOM 2.0을 제대로 배포할 수 없었고 1.0.2 아키텍처에 대한 확장 지원을 확보하지 못해 규정 준수에서 벗어나게 되었지만, FOM 자체는 이후 8개월 동안 검증된 상태로 유지되었다.

FIPS 객체 모듈 2.0은 2020년 9월 1일 NIST가 디지털 서명 표준에 대한 FIPS 186-2 사용을 중단하고 준수하지 않는 모든 모듈을 '역사적(Historical)'으로 지정하기 전까지 여러 형식으로 FIPS 140-2 검증 상태를 유지했다. 이 지정에는 연방 기관이 신규 조달에 해당 모듈을 포함해서는 안 된다는 경고가 포함되어 있다. OpenSSL FIPS 객체 모듈(인증서 #1747),[46] OpenSSL FIPS 객체 모듈 SE(인증서 #2398),[47] 그리고 OpenSSL FIPS 객체 모듈 RE(인증서 #2473)[48] 등 세 가지 OpenSSL 검증이 모두 이 중단에 포함되었다. 컨설턴트들이 만든 많은 '프라이빗 라벨' OpenSSL 기반 검증 및 복제물들도 역사적 목록으로 옮겨졌지만, 구글의 BoringCrypto[49]나 SafeLogic의 CryptoComply[50]와 같이 대체 호환성을 갖춘 일부 FIPS 검증 모듈들은 중단을 피했다.

OpenSSL 관리 위원회는 버전 관리 체계의 변경을 발표했다.

이 변경으로 인해, OpenSSL FIPS 모듈이 이미 주 버전 번호를 점유하고 있었기 때문에 다음 주 버전 번호는 두 배가 될 예정이었다. 따라서 OpenSSL 2.0 버전 번호를 건너뛰고 OpenSSL 3.0으로 계속하기로 결정했다.

OpenSSL 3.0은 FIPS 모드를 복원하고 FIPS 140-2 테스트를 거쳤지만, 상당한 지연이 있었다. 이 노력은 2016년에 SafeLogic의 지원으로 시작되었고,[51][52][53] 2017년에 오라클로부터 추가 지원을 받았지만 과정은 험난했다.[54][55][56]

2020년 10월 20일, OpenSSL FIPS 제공자 3.0이 CMVP 테스트 중 구현 목록(Implementation Under Test List)에 추가되었으며, 이는 FIPS 140-2 검증을 진행하기 위한 테스트 랩과의 공식적인 협력을 반영했다. 이로 인해 이후 몇 달 동안 많은 인증이 이루어졌다.[57]

라이선스

[편집]

OpenSSL은 OpenSSL 라이선스와 SSLeay 라이선스 하에 이중 라이선스가 부여되어 있으며, 이는 두 라이선스의 조건 중 하나를 사용할 수 있음을 의미한다.[58] OpenSSL 라이선스는 아파치 라이선스 1.0이고, SSLeay 라이선스는 4개 조항 BSD 허가서와 다소 유사하다. OpenSSL 라이선스는 아파치 라이선스 1.0이었지만 아파치 라이선스 2.0은 아니었기 때문에, 광고 자료 및 모든 재배포 시 "본 제품은 OpenSSL 툴킷에서 사용하기 위해 OpenSSL 프로젝트에서 개발한 소프트웨어를 포함하고 있습니다"라는 문구를 표시해야 했다(OpenSSL 라이선스 제3조 및 제6조). 이러한 제한으로 인해 OpenSSL 라이선스와 아파치 라이선스 1.0은 GNU GPL과 호환되지 않는다.[59] 일부 GPL 개발자들은 자신의 라이선스에 OpenSSL 예외 조항을 추가하여 자사 시스템에서 OpenSSL을 사용하는 것을 특별히 허용했다. GNU Wgetclimm 모두 이러한 예외 조항을 사용한다.[60][61] Deluge와 같은 일부 패키지는 라이선스 시작 부분에 예외 조항을 명시하는 추가 섹션을 추가하여 GPL 라이선스를 명시적으로 수정한다.[62] 다른 패키지들은 동일한 작업을 수행하는 LGPL 라이선스의 GnuTLS, BSD 라이선스의 Botan, 또는 MPL 라이선스의 NSS를 사용한다.

OpenSSL은 2015년 8월 대부분의 기여자에게 기여자 라이선스 계약(CLA)에 서명할 것을 요구할 것이며, OpenSSL이 결국 아파치 라이선스 2.0의 조건으로 재라이선스될 것이라고 발표했다.[63] 이 프로세스는 2017년 3월에 시작되어[64] 2018년에 완료되었다.[65]

2021년 9월 7일, OpenSSL 3.0.0이 아파치 라이선스 2.0 하에 출시되었다.[66]

주목할 만한 취약점

[편집]

서비스 거부(DOS): ASN.1 파싱

[편집]

OpenSSL 0.9.6k에는 특정 ASN.1 시퀀스가 윈도우 머신에서 다수의 재귀를 유발하는 버그가 있었으며, 이는 2003년 11월 4일에 발견되었다. 윈도우는 대규모 재귀를 올바르게 처리하지 못해 OpenSSL이 충돌하는 결과를 초래했다. 임의의 대규모 ASN.1 시퀀스를 전송할 수 있게 되면 OpenSSL이 결과적으로 충돌하게 된다.

OCSP 스테이플링 취약점

[편집]

핸드셰이크를 생성할 때 클라이언트가 잘못된 형식의 ClientHello 메시지를 보낼 수 있으며, 이로 인해 OpenSSL이 메시지의 끝을 넘어서 파싱하게 된다. CVE 프로젝트에서 CVE-2011-0014 식별자가 부여된 이 버그는 모든 OpenSSL 버전 0.9.8h ~ 0.9.8q 및 OpenSSL 1.0.0 ~ 1.0.0c에 영향을 미쳤다. 파싱이 잘못된 메모리 주소를 읽게 할 수 있으므로 공격자가 DoS를 유발할 수 있었다. 또한 일부 애플리케이션이 파싱된 OCSP 확장 내용을 노출할 수 있어, 공격자가 ClientHello 뒤에 오는 메모리 내용을 읽을 수 있는 가능성도 있었다.[67]

ASN.1 BIO 취약점

[편집]

신뢰할 수 없는 DER 형식 데이터를 읽기 위해 기본 입출력(BIO)[68] 또는 FILE 기반 함수를 사용할 때 OpenSSL은 취약하다. 이 취약점은 2012년 4월 19일에 발견되었으며 CVE 식별자 CVE-2012-2110이 부여되었다. OpenSSL의 SSL/TLS 코드에 직접 영향을 미치지는 않지만, ASN.1 함수(특히 d2i_X509 및 d2i_PKCS12)를 사용하는 모든 애플리케이션도 영향을 받았다.[69]

SSL, TLS 및 DTLS 평문 복구 공격

[편집]

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

예측 가능한 개인 키 (데비안 전용)

[편집]

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

이 오류는 2008년 5월 13일 데비안에 의해 보고되었다. 데비안 4.0 배포판(etch)에서는 0.9.8c-4etch3 버전에서 수정되었으며, 데비안 5.0 배포판(lenny)에 대한 수정 사항은 0.9.8g-9 버전에서 제공되었다.[74]

하트블리드

[편집]
하트블리드 버그를 상징하는 로고

OpenSSL 버전 1.0.1부터 1.0.1f까지는 TLS 하트비트 확장의 구현에 심각한 메모리 처리 버그가 있어, 매번의 하트비트마다 애플리케이션 메모리를 최대 64 KB까지 노출하는 데 사용될 수 있었다[75][76] (CVE-2014-0160). 웹 서버의 메모리를 읽음으로써 공격자는 서버의 개인 키를 포함한 민감한 데이터에 접근할 수 있었다.[77] 사용된 암호화 프로토콜이 전방향 보안을 보장하지 않는 경우, 공격자가 이전에 감청된 통신을 해독할 수 있게 된다. 개인 키를 알게 되면 공격자는 향후의 모든 통신에 대해 중간자 공격을 가할 수 있다. 또한 이 취약점은 세션 쿠키와 비밀번호를 포함하여 다른 사용자의 민감한 요청 및 응답의 암호화되지 않은 부분을 노출할 수 있으며, 이를 통해 공격자가 해당 서비스 사용자의 신분을 탈취할 수 있게 된다.[78]

2014년 4월 7일 취약점 공개 당시, 신뢰할 수 있는 기관에 의해 인증된 인터넷 보안 웹 서버의 약 17% 또는 50만 개가 공격에 취약했던 것으로 추정된다.[79] 하트블리드는 서버와 클라이언트 양쪽 모두에 영향을 미칠 수 있다.

CCS 인젝션 취약점

[편집]

CCS 인젝션 취약점(CVE-2014-0224)은 키잉 데이터에 사용되는 OpenSSL 방식의 약점으로 인해 발생하는 보안 우회 취약점이다.[80]

이 취약점은 중간자 공격을 통해 악용될 수 있으며,[81] 공격자는 전송 중인 트래픽을 해독하고 수정할 수 있다. 원격의 인증되지 않은 공격자는 특별히 제작된 핸드셰이크를 사용하여 취약한 키잉 데이터를 강제로 사용하게 함으로써 이 취약점을 악용할 수 있다. 성공적으로 악용될 경우 공격자가 잠재적으로 민감한 정보에 접근할 수 있는 보안 우회 상태로 이어질 수 있다. 이 공격은 취약한 클라이언트와 서버 사이에서만 수행될 수 있다.

OpenSSL 클라이언트는 0.9.8za, 1.0.0m 및 1.0.1h 이전의 모든 OpenSSL 버전에서 취약하다. 서버는 OpenSSL 1.0.1 및 1.0.2-beta1에서만 취약한 것으로 알려져 있다. 1.0.1 이전 버전의 OpenSSL 서버 사용자들에게는 예방 조치로 업그레이드가 권고된다.[82]

ClientHello sigalgs DoS

[편집]

이 취약점(CVE-2015-0291)은 누구든지 인증서를 가져와 그 내용을 읽고 정확하게 수정하여 인증서가 클라이언트나 서버를 충돌하게 만듦으로써 취약점을 악용할 수 있게 한다. 클라이언트가 OpenSSL 1.0.2 서버에 연결하고 잘못된 서명 알고리즘 확장으로 재협상을 시도하면 null-pointer 역참조가 발생한다. 이는 서버에 대한 DoS 공격을 유발할 수 있다.

스탠포드 보안 연구원인 데이비드 라모스(David Ramos)가 개인적인 익스플로잇을 보유하고 있었으며 이를 OpenSSL 팀에 제시하여 문제가 해결되었다.

OpenSSL은 이 버그를 '심각도 높음'으로 분류했으며, 버전 1.0.2가 취약한 것으로 확인되었다.[83]

디피-헬먼 소그룹에 대한 키 복구 공격

[편집]

이 취약점(CVE-2016-0701)은 특정 상황이 충족될 때 OpenSSL 서버의 개인 디피-헬먼 키를 복구할 수 있게 한다. 어도비 시스템 보안 연구원인 안토니오 산소(Antonio Sanso)가 이 취약점을 개별적으로 보고했다.

OpenSSL은 이 버그를 '심각도 높음'으로 분류했으며, 버전 1.0.2만 취약한 것으로 확인되었다.[84]

포크

[편집]

Agglomerated SSL

[편집]

2009년, 기존 OpenSSL API에 대한 불만으로 당시 OpenBSD 개발자였던 마르코 페레봄(Marco Peereboom)은 Agglomerated SSL(assl)을 만들어 기존 API를 포크했다.[85] 이는 내부적으로는 OpenSSL API를 재사용하지만 훨씬 더 단순한 외부 인터페이스를 제공한다.[86] 2015년경 LibreSSL 포크가 등장함에 따라 이후 사용되지 않게 되었다.

LibreSSL

[편집]

2014년 4월 하트블리드 여파로 OpenBSD 프로젝트 멤버들은 1.0.1g 브랜치부터 시작하여 OpenSSL을 포크하여 LibreSSL이라는 프로젝트를 만들었다.[87] OpenSSL의 코드베이스를 정리하기 시작한 첫 주 만에 포크에서 90,000줄 이상의 C 코드가 제거되었다.[88]

BoringSSL

[편집]

2014년 6월, 구글은 BoringSSL이라고 불리는 자체 OpenSSL 포크를 발표했다.[89] 구글은 OpenSSL 및 LibreSSL 개발자들과 협력할 계획이다.[90][91][92] 구글은 이후 BoringSSL을 기반으로 한 새로운 라이브러리 Tink를 개발했다.[93] 마이크로소프트 엣지를 포함한 크로미엄 기반 브라우저들은 BoringSSL을 구현하고 있다.

AWS-LC

[편집]

2020년 9월, 아마존 웹 서비스 암호화 팀이 AWS 클라우드 컴퓨팅 플랫폼에서 사용하기 위해 유지 관리하는 범용 암호화 라이브러리로 출시되었다. OpenSSL 및 BoringSSL 프로젝트의 코드를 기반으로 한다.[94]

QuicTLS

[편집]

QuicTLS는 아카마이마이크로소프트 간의 협력 포크로, OpenSSL 3.3 릴리스를 기반으로 한다. 일부 기능과 수정 사항은 현재의 OpenSSL 저장소에서 선별(cherry-pick)하여 반영했다.[95]

비판

[편집]

하위 호환성

[편집]

개발자 커뮤니티 사이에서 OpenSSL은 각 새로운 주 버전마다 API 호환성을 깨뜨리는 것으로 자주 언급되며,[96][97][98][99] 이는 새로운 버전 채택을 지연시키는 소프트웨어 적응 작업을 필요로 한다.[100] 이는 이전 릴리스가 일반적으로 새로운 주 버전이 출시된 후 2년 이상 유지 관리되지 않는다는 사실과 결합되어,[26] 일부 벤더들이 기존 소프트웨어와의 호환성을 잃거나[101][102] 회귀 버그 위험을 감수하면서까지[103][104] 시간이 얼마 남지 않은 상황에서 매우 이른 소프트웨어 마이그레이션을 서두르게 만드는 경향이 있다.[105]

출시 지연

[편집]

장기 지원 버전(LTS) 릴리스는 5년 동안 유지 관리되지만,[10] 출시 기간의 누적된 지연으로 인해 운영체제 벤더들은 마지막으로 지원되는 릴리스에 더 오래 머물게 되어 새 버전이 나왔을 때 여유가 없게 되는 경향이 있다. 예를 들어, OpenSSL 3.0은 당초 2019년 4분기에 나올 것으로 예상되었으나[45] 최종적으로 21개월이나 늦게 출시되었고,[26] 상당한 변경으로 인해 기존 소프트웨어의 적응이 필요했음에도 불구하고 이전에 지원되던 버전 1.1.1의 예상 지원 종료 기한은 연장되지 않았다.

심각한 성능 회귀

[편집]

위에서 언급한 버전 1.1.1의 단축된 지원 지연은 워크로드가 성능에 민감한 사용자들에게 더 큰 우려를 낳는다. 3.0 정식 출시 후 얼마 지나지 않아 일부 사용자들은 멀티스레드 환경에서 이 버전에 영향을 미치는 심각한 성능 회귀를 보고하기 시작했다. 많은 이들이 잦은 저수준 연산에서 잠금(lock)의 비효율적인 사용을 지적하며 80배에서 400배까지 느려진 사례를 언급했다.[106][107][108][109][110][111][112][113] OpenSSL 팀은 이러한 대규모 성능 회귀에 대한 보고를 중앙 집중화하기 위해 메타 이슈를 생성했다.[114] 이 보고자들의 절반 정도는 이전 버전에서 3.0으로 업그레이드하는 것이 불가능하다고 밝히고 있으며, 이는 이전 버전 1.1.1의 남은 지원 시간이 한정되어 있어 발생하는 문제를 심화시킨다.

사용자 요구 사항에 대한 고려

[편집]

세 번째 버전의 HTTP 프로토콜을 지원하기 위해 QUIC 전송 계층 작업이 진행되는 동안 보안을 위해 TLS를 사용하기로 제안되었고,[115] TLS 라이브러리에 일부 수정이 필요하다는 점이 확인되었다. 이러한 수정 사항은 당시 QUIC 개발자들이 주로 사용하던 라이브러리인 BoringSSL에 도입되었고,[116] 나중에 다른 라이브러리들로 포팅되었다.[117] 이 작업의 포트가 OpenSSL에 신속하게 제안되었다.[118] 제안 당일 토론이 시작되었으나 빠르게 교착 상태에 빠졌고, 처음에는 라이선스 고려 사항으로 인해 차단되었다가[118] 이러한 문제가 해결된 후에도 보류되었다. 마침내 10개월 후 OpenSSL 관리 위원회는 블로그 게시물을 통해[119] API가 시간이 지남에 따라 변할 수 있다는 우려로 인해 이 패치 세트를 3.0에 채택하지 않겠다고 발표했다. 결국 출시가 늦어지던 3.0의 계획된 출시일로부터 1년 넘게 지난 시점에서도 소식이 없자, 아카마이마이크로소프트의 자원봉사 팀은 QUIC 개발을 진척시키기 위해 이 패치들을 OpenSSL 코드 위에 지원하는 QuicTLS라는 프로젝트로 포크하기로 결정했다.[120] 이 조치는 커뮤니티에서 전반적으로 환영받았다. 마침내 OpenSSL 3.0이 출시된 후 QUIC 패치 세트가 다시 고려되었으나 거부되었고,[121] 이는 커뮤니티에서 수십에서 수백 건의 실망 섞인 반응을 일으켰다.[118] 풀 리퀘스트는 닫혔으며, 사용자들은 공개적으로 실망감을 표하거나[122] 운영체제 벤더들에게 대안인 QuicTLS 포크를 지원해 달라고 간청하거나[123][124] 대안을 모색해야 할 필요성을 느꼈다.[125] 마지막으로 QuicTLS 포크의 공동 창립자인 리치 살츠(Rich Salz)는 QuicTLS에서 포크된 아파치 프로젝트를 보는 것에 대한 관심을 표명했다.[125] 2023년 2월 25일 기준으로, 최종 사용자가 소스에서 직접 빌드하지 않고 운영체제에서 기본적으로 제공하는 QUIC 호환 장기 지원 TLS 라이브러리는 여전히 존재하지 않는다.

같이 보기

[편집]

각주

[편집]
  1. “OpenSSL 3.6.0”. 2025년 10월 1일. 2025년 10월 1일에 확인함. 
  2. Laurie, Ben (1999년 1월 6일). “Announce: OpenSSL (Take 2)” (메일링 리스트). 《ssl-users》. 2019년 3월 23일에 원본 문서에서 보존된 문서. 2018년 10월 29일에 확인함. 
  3. “New Committers”. OpenSSL Software Foundation. 2019년 5월 20일. 2024년 10월 14일에 원본 문서에서 보존된 문서. 2024년 10월 11일에 확인함. 
  4. “OpenSSL Management Committee”. OpenSSL Software Foundation. 2018년 7월 22일에 원본 문서에서 보존된 문서. 2019년 11월 3일에 확인함. 
  5. “OpenSSL Committers”. OpenSSL Software Foundation. 2018년 7월 22일에 원본 문서에서 보존된 문서. 2019년 11월 3일에 확인함. 
  6. “OpenSSL Annual Report 2024” (PDF). 
  7. Marquess, Steve (2017년 1월 19일). “Akamai sponsors TLS 1.3” (메일링 리스트). 《openssl-announce》. 2017년 2월 1일에 원본 문서에서 보존된 문서. 2018년 11월 9일에 확인함. 
  8. “OpenSSL – Changelog”. OpenSSL Software Foundation. 2016년 9월 13일에 원본 문서에서 보존된 문서. 2016년 9월 26일에 확인함. 
  9. “OpenSSL Releases”. 《GitHub. 2022년 12월 6일에 확인함. 
  10. “OpenSSL Library – Release Strategy”. OpenSSL Software Foundation. 2024년 12월 9일에 원본 문서에서 보존된 문서. 2024년 8월 1일에 확인함. 
  11. “OpenSSL 0.9.x series notes”. 《GitHub. 2022년 12월 6일에 확인함. 
  12. “OpenSSL 1.0.0 series notes”. 《GitHub. 2022년 12월 6일에 확인함. 
  13. “OpenSSL 1.0.1 series notes”. 《GitHub. 2022년 12월 6일에 확인함. 
  14. R. Seggelmann; M. Tuexen; M. Williams (February 2012). Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. Internet Engineering Task Force. ISSN 2070-1721. RFC 6520. https://tools.ietf.org/html/rfc6520.  Proposed Standard. Updated by RFC 8447.
  15. E. Rescorla (January 2010). Keying Material Exporters for Transport Layer Security (TLS). Internet Engineering Task Force. ISSN 2070-1721. RFC 5705. https://tools.ietf.org/html/rfc5705.  Proposed Standard. Updated by RFC 8446 and 8447.
  16. D. McGrew; E. Rescorla (May 2010). Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). Internet Engineering Task Force. ISSN 2070-1721. RFC 5764. https://tools.ietf.org/html/rfc5764.  Proposed Standard. Updated by RFC 7983 and 9443.
  17. “OpenSSL 1.0.2 series notes”. 《GitHub. 2022년 12월 6일에 확인함. 
  18. “OpenSSL 1.1.0 series notes”. 《GitHub. 2022년 12월 6일에 확인함. 
  19. J-P. Aumasson (October 2015). M-J. Saarinen. ed. The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC). Independent Submission. ISSN 2070-1721. RFC 7693. https://tools.ietf.org/html/rfc7693.  Informational.
  20. Y. Nir; A. Langley (June 2018). ChaCha20 and Poly1305 for IETF Protocols. Internet Research Task Force. ISSN 2070-1721. RFC 8439. https://tools.ietf.org/html/rfc8439.  Informational. Obsoletes RFC 7539.
  21. A. Langley; M. Hamburg; S. Turner (January 2016). Elliptic Curves for Security. Internet Engineering Task Force. ISSN 2070-1721. RFC 7748. https://tools.ietf.org/html/rfc7748.  Informational.
  22. Caswell, Matt (2018년 9월 11일). “OpenSSL 1.1.1 Is Released”. 《OpenSSL Blog》. OpenSSL Foundation. 2024년 10월 11일에 확인함. 
  23. “OpenSSL 1.1.1 series notes”. 《GitHub. 2022년 12월 6일에 확인함. 
  24. Caswell, Matt (2018년 2월 8일). “Using TLS1.3 With OpenSSL”. 《OpenSSL Blog》. OpenSSL Foundation. 2024년 10월 11일에 확인함. 
  25. B. Kaliski; A. Rusch; J. Johnsson; A. Rusch (November 2016). K. Moriarty. ed. PKCS #1: RSA Cryptography Specifications Version 2.2. Internet Engineering Task Force. ISSN 2070-1721. RFC 8017. https://tools.ietf.org/html/rfc8017.  Informational. Obsoletes RFC 3447.
  26. “OpenSSL 3.0 Has Been Released!”. 《OpenSSL Blog》. 2021년 9월 7일. 2024년 10월 11일에 확인함. 
  27. “OpenSSL 3.0 series notes”. 《GitHub. 2022년 12월 6일에 확인함. 
  28. Matt Caswell (2018년 11월 28일). “The Holy Hand Grenade of Antioch”. OpenSSL Blog. 2024년 10월 11일에 확인함. 
  29. “OpenSSL 3.1 Final Release”. 《OpenSSL Blog》. 2023년 3월 7일. 2024년 10월 11일에 확인함. 
  30. “OpenSSL 3.1 series notes”. 《GitHub. 2023년 3월 15일에 확인함. 
  31. “OpenSSL 3.2.0 Final Release”. 《OpenSSL Blog》. 2023년 11월 23일. 2024년 12월 7일에 원본 문서에서 보존된 문서. 2024년 10월 11일에 확인함. 
  32. “OpenSSL 3.2 series notes”. 《GitHub. 2023년 11월 24일에 확인함. 
  33. A. Ghedini; V. Vasiliev (December 2020). TLS Certificate Compression. Internet Engineering Task Force. ISSN 2070-1721. RFC 8879. https://tools.ietf.org/html/rfc8879.  Proposed Standard.
  34. T. Pornin (August 2013). Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). Independent Submission. ISSN 2070-1721. RFC 6979. https://tools.ietf.org/html/rfc6979.  Informational.
  35. J. Gilmore; S. Weiler; T. Kivinen (June 2014). P. Wouters; H. Tschofenig. eds. Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Internet Engineering Task Force. ISSN 2070-1721. RFC 7250. https://tools.ietf.org/html/rfc7250.  Proposed Standard.
  36. “OpenSSL 3.3 Final Release”. 《OpenSSL Blog》. 2024년 4월 10일. 2024년 10월 11일에 확인함. 
  37. “OpenSSL 3.4 Final Release”. 《OpenSSL Blog》. 2024년 10월 22일. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2024년 11월 22일에 확인함. 
  38. “OpenSSL 3.5 Final Release”. 《OpenSSL Blog》. 2025년 4월 8일. 2025년 4월 25일에 원본 문서에서 보존된 문서. 2025년 4월 28일에 확인함. 
  39. “GOST engine OpenSSL 1.0.0 README”. cvs.openssl.org. 2013년 4월 15일에 원본 문서에서 보존된 문서. 
  40. “OpenSSL source code, directory crypto/whrlpool”. 《GitHub》. 2019년 2월 17일에 원본 문서에서 보존된 문서. 2017년 8월 29일에 확인함. 
  41. “Protecting data for the long term with forward secrecy”. 2016년 3월 4일에 원본 문서에서 보존된 문서. 2012년 11월 5일에 확인함. 
  42. “NIST recertifies open source encryption module”. gcn.com. 2007년 10월 10일에 원본 문서에서 보존된 문서. 
  43. “FIPS-140”. openssl.org. 2019년 11월 12일에 확인함. 
  44. “OpenSSL User Guide for the OpenSSL FIPS Object Module v2.0” (PDF). openssl.org. 2017년 3월 14일. 2020년 6월 9일에 원본 문서 (PDF)에서 보존된 문서. 2019년 11월 12일에 확인함. 
  45. “Update on 3.0 Development, FIPS and 1.0.2 EOL”. 《OpenSSL Blog》. 2019년 11월 7일. 2024년 10월 11일에 확인함. 
  46. “Cryptographic Module Validation Program Certificate #1747”. 《Computer Security Resource Center》. 2016년 10월 11일. 
  47. “Cryptographic Module Validation Program Certificate #2398”. 《Computer Security Resource Center》. 2016년 10월 11일. 2020년 10월 26일에 원본 문서에서 보존된 문서. 2020년 10월 29일에 확인함. 
  48. “Cryptographic Module Validation Program Certificate #2473”. 《Computer Security Resource Center》. 2016년 10월 11일. 
  49. “Cryptographic Module Validation Program search results”. 《Computer Security Resource Center》. 2016년 10월 11일. 
  50. “Cryptographic Module Validation Program search results”. 《Computer Security Resource Center》. 2016년 10월 11일. 
  51. Schneider, Troy K. (2016년 7월 20일). “Getting government approval of a more secure OpenSSL”. 《GCN: Technology, Tools, and Tactics for Public Sector IT》. 2021년 5월 9일에 원본 문서에서 보존된 문서. 2020년 10월 29일에 확인함. 
  52. Waterman, Shaun (2016년 7월 21일). “SafeLogic saves the day for feds' use of OpenSSL”. 《FedScoop》. 
  53. Rashid, Fahmida Y. (2016년 7월 26일). “Reworked OpenSSL on track for government validation”. 《InfoWorld》. 
  54. Wells, Joyce (2017년 8월 3일). “Oracle, SafeLogic and OpenSSL Join Forces to Update FIPS Module”. 《Database Trends and Applications》. 
  55. Kerner, Sean Michael (2017년 8월 4일). “Oracle Joins SafeLogic to Develop FIPS Module for OpenSSL Security”. 《eWeek》. 
  56. “OpenSSL 3.0 Alpha7 Release”. 《OpenSSL Blog》. 2020년 10월 20일. 2024년 10월 14일에 원본 문서에서 보존된 문서. 2024년 10월 11일에 확인함. 
  57. “Cryptographic Module Validation Program: OpenSSL”. 《Computer Security Resource Center》. 2016년 10월 11일. 2021년 4월 14일에 원본 문서에서 보존된 문서. 2021년 9월 24일에 확인함. 
  58. “OpenSSL: Source, License”. openssl.org. 2019년 1월 18일에 원본 문서에서 보존된 문서. 2015년 2월 5일에 확인함. 
  59. “Licenses – Free Software Foundation”. fsf.org. 2008년 1월 24일에 원본 문서에서 보존된 문서. 2008년 1월 4일에 확인함. 
  60. “WGET 1.10.2 for Windows (win32)”. users.ugent.be. 2008년 1월 2일에 원본 문서에서 보존된 문서. 
  61. “Releases of source and binaries”. climm.org. 2011년 2월 12일에 원본 문서에서 보존된 문서. 2010년 11월 30일에 확인함. 
  62. “Deluge LICENSE file”. deluge-torrent.org. 2013년 12월 3일에 원본 문서에서 보존된 문서. 2013년 1월 24일에 확인함. 
  63. Salz, Rich (2015년 8월 1일). “License Agreements and Changes Are Coming”. 《openssl.org》. 2024년 10월 11일에 확인함. 
  64. “OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Broader Use with Other FOSS Projects and Products”. 2017년 3월 23일. 2017년 7월 18일에 원본 문서에서 보존된 문서. 2018년 8월 6일에 확인함. 
  65. Lee, Victoria; Radcliffe, Mark; Stevenson, Chris ( 5 February 2019). “Top 10 FOSS legal developments of 2018”. 《Opensource.com, 레드햇》. 5 February 2019에 원본 문서에서 보존된 문서. 28 September 2019에 확인함. The OpenSSL project announced that it had completed its shift from the OpenSSL/SSLeay license to the Apache Software License version 2 (ASLv2). 
  66. “OpenSSL 3.0 License Change”. 2021년 9월 22일. 2025년 1월 17일에 원본 문서에서 보존된 문서. 2021년 9월 24일에 확인함. 
  67. “OpenSSL Updates Fix Critical Security Vulnerabilities”. August 9, 2014. August 26, 2014에 원본 문서에서 보존된 문서. August 25, 2014에 확인함. 
  68. “OpenSSL ASN.1 asn1_d2i_read_bio() Heap Overflow Vulnerability”. Cisco. 2016년 6월 10일에 원본 문서에서 보존된 문서. 2016년 5월 9일에 확인함. 
  69. “ASN1 BIO vulnerability”. OpenSSL. 2015년 3월 2일에 원본 문서에서 보존된 문서. 2015년 2월 5일에 확인함. 
  70. “On the Security of RC4 in TLS”. Royal Holloway Department of Information Security. 2013년 3월 15일에 원본 문서에서 보존된 문서. 2014년 4월 29일에 확인함. 
  71. “research!rsc: Lessons from the Debian/OpenSSL Fiasco”. 《research.swtch.com》. August 12, 2015에 확인함. 
  72. “SSLkeys”. 《Debian Wiki》. June 19, 2015에 확인함. 
  73. “Debian OpenSSL – Predictable PRNG Bruteforce SSH Exploit Python”. 《Exploits Database》. June 1, 2008. February 6, 2025에 원본 문서에서 보존된 문서. August 12, 2015에 확인함. 
  74. “DSA-1571-1 openssl – predictable random number generator”. 데비안 Project. 2008년 5월 13일. 2011년 3월 9일에 원본 문서에서 보존된 문서. 2012년 8월 5일에 확인함. 
  75. OpenSSL.org (April 7, 2014). “OpenSSL Security Advisory [07 Apr 2014]”. April 8, 2014에 원본 문서에서 보존된 문서. April 9, 2014에 확인함. 
  76. OpenSSL (April 7, 2014). “TLS heartbeat read overrun (CVE-2014-0160)”. April 8, 2014에 원본 문서에서 보존된 문서. April 8, 2014에 확인함. 
  77. Codenomicon Ltd (April 8, 2014). “Heartbleed Bug”. April 7, 2014에 원본 문서에서 보존된 문서. April 8, 2014에 확인함. 
  78. “Why Heartbleed is dangerous? Exploiting CVE-2014-0160”. IPSec.pl. 2014. 2014년 4월 8일에 원본 문서에서 보존된 문서. 2014년 4월 8일에 확인함. 
  79. Mutton, Paul (April 8, 2014). “Half a million widely trusted websites vulnerable to Heartbleed bug”. Netcraft Ltd. November 19, 2014에 원본 문서에서 보존된 문서. April 8, 2014에 확인함. 
  80. “OpenSSL continues to bleed out more flaws – more critical vulnerabilities found”. Cyberoam Threat Research Labs. 2014. June 19, 2014에 원본 문서에서 보존된 문서. June 13, 2014에 확인함. 
  81. “CVE-2014-0224”. CVE. 2014. 2014년 8월 1일에 원본 문서에서 보존된 문서. 2014년 6월 13일에 확인함. 
  82. “OpenSSL Security Advisory”. OpenSSL. June 5, 2014. April 30, 2024에 원본 문서에서 보존된 문서. June 13, 2014에 확인함. 
  83. “OpenSSL Patches Severe Denial-of-Service Vulnerability”. Brandon Stosh. March 20, 2015. April 2, 2015에 원본 문서에서 보존된 문서. March 20, 2015에 확인함. 
  84. Goodlin, Dan (January 28, 2016). “High-severity bug in OpenSSL allows attackers to decrypt HTTPS traffic”. 《Ars Technica》. November 20, 2016에 원본 문서에서 보존된 문서. June 14, 2017에 확인함. 
  85. “Agglomerated SSL”. 《GitHub》. 2010년 9월 7일. 2024년 12월 9일에 원본 문서에서 보존된 문서. 2024년 12월 9일에 확인함. 
  86. “security/assl: assl-1.5.0p0v0 – hide awful SSL API in a sane interface”. 《OpenBSD ports》. 2014년 5월 22일. 2015년 2월 10일에 원본 문서에서 보존된 문서. 2015년 2월 10일에 확인함. 
  87. “OpenBSD has started a massive strip-down and cleanup of OpenSSL”. 《OpenBSD journal》. 2014년 4월 15일. 2014년 7월 1일에 원본 문서에서 보존된 문서. 2014년 4월 21일에 확인함. 
  88. “OpenBSD forks, prunes, fixes OpenSSL”. ZDNet. 2014년 4월 21일. 2014년 4월 21일에 원본 문서에서 보존된 문서. 2014년 4월 21일에 확인함. 
  89. “BoringSSL”. 《Git at Google》. 2018년 2월 17일에 원본 문서에서 보존된 문서. 2015년 12월 28일에 확인함. 
  90. “Google unveils independent 'fork' of OpenSSL called 'BoringSSL'. 《Ars Technica》. 2014년 6월 21일. 2014년 6월 23일에 원본 문서에서 보존된 문서. 2017년 6월 14일에 확인함. 
  91. “BoringSSL”. 《Adam Langley's Weblog》. 2014년 6월 20일. 2018년 6월 1일에 원본 문서에서 보존된 문서. 2015년 9월 22일에 확인함. 
  92. “BoringSSL wants to kill the excitement that led to Heartbleed”. Sophos. 2014년 6월 24일. 2018년 2월 14일에 원본 문서에서 보존된 문서. 2016년 10월 24일에 확인함. 
  93. Buchanan, Bill (2018년 8월 30일). “Goodbye OpenSSL, and Hello To Google Tink”. 《Medium》. 2019년 4월 4일에 확인함. 
  94. “AWS-LC is a general-purpose cryptographic library”. 《GitHub》. 2020년 9월 4일. 2024년 12월 8일에 확인함. 
  95. “The official repository for the QuicTLS project”. 《GitHub》. 2025년 5월 7일. 2025년 5월 7일에 확인함. 
  96. “OpenSSL 3 breaks webpack build · Issue #22305 · brave/brave-browser”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  97. “openssl version 3.0 in arch? / Newbie Corner / Arch Linux Forums”. 《bbs.archlinux.org》. 2024년 5월 16일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  98. “OpenSSL 3.0 transition plans”. 《Ubuntu Community Hub》. 2022년 4월 6일. 2024년 12월 25일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  99. “OpenSSL 3.0 Compatibility · Issue #597 · nginx/unit”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  100. “Our future with OpenSSL”. 《Discussions on Python.org》. 2022년 11월 28일. 2023년 2월 25일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  101. “Compile against OpenSSL 3.X”. 《groups.google.com》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  102. “ESET Management Agent (RHEL 9.x, OpenSSL 3.0.x)”. 《ESET Security Forum》. 2022년 6월 6일. 2024년 12월 9일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  103. “Issue 46313: SSLObject does not raise SSLEOFError on OpenSSL 3 - Python tracker”. 《bugs.python.org》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  104. “RHEL 9 : openssl (RHSA-2022:6224)”. 《www.tenable.com》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  105. “The experience of bringing OpenSSL 3.0 into Red Hat Enterprise Linux and Fedora”. 《www.redhat.com》. 
  106. “Massive performance degradation in OpenSsl 3.0 if used in a heavy multi threaded server application · Issue #17064 · openssl/openssl”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  107. “Performance issue with Openssl 3.0 in multi threaded application when using d2i_x509 · Issue #17950 · openssl/openssl”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  108. “Severe efficiency degradation of credential loading in comparison to 1.1.1 · Issue #18814 · openssl/openssl”. 《GitHub》. 2024년 12월 7일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  109. “3.0 performance degraded due to locking · Issue #20286 · openssl/openssl”. 《GitHub》. 
  110. “High cpu usage for outbound ssl requests after upgrading from v16.15.0 to v18.1.0 · Issue #43128 · nodejs/node”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  111. “Massive performance degradation in OpenSsl 3.0 FIPS provider · Issue #18472 · openssl/openssl”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  112. “Performance measurements · Issue #16791 · openssl/openssl”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  113. “PEM/DER decoding of PKCS8 RSA private keys are 80 times slower in 3.0 · Issue #15199 · openssl/openssl”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  114. “3.0 Performance problems · Issue #17627 · openssl/openssl”. 《GitHub》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  115. Thomson, Martin; Turner, Sean (2017년 1월 14일). “Using Transport Layer Security (TLS) to Secure QUIC”. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 11월 27일에 확인함 – IETF 경유. 
  116. “221 - boringssl - A fork of OpenSSL that is designed to meet Google's needs - Monorail”. 《bugs.chromium.org》. 
  117. “Support QUIC TLS API (#826) · Issues · gnutls / GnuTLS · GitLab”. 《GitLab》. 2019년 9월 4일. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  118. “WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl”. 《GitHub》. 2025년 1월 21일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  119. “QUIC and OpenSSL”. 《OpenSSL Blog》. 2020년 2월 17일. 2024년 10월 11일에 확인함. 
  120. “quictls announce on twitter”. 
  121. “OMC Release Requirements”. 《www.mail-archive.com》. 2025년 1월 21일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  122. “The QUIC API OpenSSL will not provide | daniel.haxx.se”. 2021년 10월 25일. 2025년 1월 21일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  123. Tarreau, Willy (2021년 10월 27일). “[Pkg-openssl-devel] Any intent to maintain quictls ?”. 2024년 12월 7일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  124. “Bug#1011391: openssl: please support quictls patchset”. 《groups.google.com》. 2024년 12월 8일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
  125. “HTTP/3 support · Issue #680 · haproxy/haproxy”. 《GitHub》. 2024년 12월 7일에 원본 문서에서 보존된 문서. 2023년 2월 25일에 확인함. 
내용주
  1. 주 버전 2.0.0은 이전에 OpenSSL FIPS 모듈에서 사용되었기 때문에 건너뛰었다.[28]

외부 링크

[편집]