OpenSSL

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)이었다.

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

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

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

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

 주요 버전 출시 

 알고리즘 

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

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

 FIPS 140 검증 

FIPS 140은 암호화 모듈의 테스트 및 인증을 위한 미국 연방 프로그램이다. OpenSSL의 FOM 1.0에 대한 초기 FIPS 140-1 인증은 "검증된 모듈과 외부 소프트웨어 간의 상호작용에 대해 의문이 제기되었을 때"인 2006년 7월에 취소되었다. 이 모듈은 FIPS 140-2로 넘어가기 전인 2007년 2월에 재인증을 받았다. OpenSSL 1.0.2는 FIPS 140-2 검증 환경에서 FIPS 승인 알고리즘을 제공하기 위해 구축된 OpenSSL FIPS 객체 모듈(FOM)의 사용을 지원했다. OpenSSL은 FIPS 모드를 지원하는 유일한 OpenSSL 버전이라는 반대에도 불구하고, 1.0.2 아키텍처를 2019년 12월 31일자로 '지원 종료' 또는 'EOL'로 분류하기로 결정하여 논란이 되었다. 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), OpenSSL FIPS 객체 모듈 SE(인증서 #2398), 그리고 OpenSSL FIPS 객체 모듈 RE(인증서 #2473) 등 세 가지 OpenSSL 검증이 모두 이 중단에 포함되었다. 컨설턴트들이 만든 많은 '프라이빗 라벨' OpenSSL 기반 검증 및 복제물들도 역사적 목록으로 옮겨졌지만, 구글의 BoringCrypto나 SafeLogic의 CryptoComply와 같이 대체 호환성을 갖춘 일부 FIPS 검증 모듈들은 중단을 피했다.

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

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

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

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

 라이선스 

OpenSSL은 OpenSSL 라이선스와 SSLeay 라이선스 하에 이중 라이선스가 부여되어 있으며, 이는 두 라이선스의 조건 중 하나를 사용할 수 있음을 의미한다. OpenSSL 라이선스는 아파치 라이선스 1.0이고, SSLeay 라이선스는 4개 조항 BSD 허가서와 다소 유사하다.
OpenSSL 라이선스는 아파치 라이선스 1.0이었지만 아파치 라이선스 2.0은 아니었기 때문에, 광고 자료 및 모든 재배포 시 "본 제품은 OpenSSL 툴킷에서 사용하기 위해 OpenSSL 프로젝트에서 개발한 소프트웨어를 포함하고 있습니다"라는 문구를 표시해야 했다(OpenSSL 라이선스 제3조 및 제6조). 이러한 제한으로 인해 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 하에 출시되었다.

 주목할 만한 취약점 

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

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

 OCSP 스테이플링 취약점 

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

 ASN.1 BIO 취약점 

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

 SSL, TLS 및 DTLS 평문 복구 공격 

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

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

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 버전에서 제공되었다.

 하트블리드 

섬네일|하트블리드 버그를 상징하는 로고

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

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

 CCS 인젝션 취약점 

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

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

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

 ClientHello sigalgs DoS 

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

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

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

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

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

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

 포크 

 Agglomerated SSL 

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

 LibreSSL 

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

 BoringSSL 

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

 AWS-LC 

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

 QuicTLS 

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

 비판 

 하위 호환성 

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

 출시 지연 

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

 심각한 성능 회귀 

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

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

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

 같이 보기 
 LibreSSL

 각주 

 내용주

 외부 링크 

 
 OpenSSL Manpages
 OpenSSL Programming Guide
 The OpenSSL License and the GPL by Mark McLoughlin
 OpenSSL programming tutorial
 OpenSSL Community Wiki

분류:암호 소프트웨어
분류:전송 계층 보안 구현
분류:자유 보안 소프트웨어
분류:1998년 소프트웨어
분류:C 라이브러리