최근 수정 시각 : 2024-11-27 18:38:43

OpenSSL

<colbgcolor=#730c0a><colcolor=#fff> OpenSSL
파일:openssl.svg
종류 암호화 라이브러리
개발 OpenSSL 프로젝트
언어 C언어, 어셈블리어 및 기타
버전 Stable: 3.4.0 (2024년 10월 22일)
LTS: 3.0.15 (2024년 9월 4일)
라이선스 아파치 라이선스 2.0[1]
OpenSSL 라이선스[2]
링크 파일:홈페이지 아이콘.svg 파일:GitHub 아이콘.svg파일:GitHub 아이콘 화이트.svg Wiki RFC
1. 개요2. 역사3. 상세
3.1. 지원하는 알고리즘
4. 주요 보안 이슈
4.1. ASN.1 서비스 거부 취약점4.2. OCSP 스테플링 취약점4.3. ASN.1 BIO 취약점4.4. TLS 평문 복호화 취약점4.5. 비밀키 예측 공격4.6. 하트블리드4.7. CCS 인젝션 취약점4.8. ClientHello sigalgs 서비스 거부 취약점
5. 포크 및 대체제6. 기타7. 관련 문서

[clearfix]

1. 개요

널리 사용되는 대부분의 대칭/비대칭 암호화 프로토콜을 구현한 오픈 소스 라이브러리로, 가장 대표적으로는 SSL/TLS와 관련된 기능들을 제공한다. 2023년 현재, HTTPS를 사용하는 사실상 거의 대부분의 서버와 클라이언트에서 돌아가고 있으며, 그 외에도 정보보안과 관련된 분야라면 심심찮게 등장할 정도로 폭넓게 사용되는 암호화계의 사실상 표준이다.

2. 역사

1996년 SSL 3.0 표준이 등장하자 에릭 엔드류 영(Eric Andrew Young)과 팀 허드슨(Tim Hudson)은 당시의 상용 SSL 라이브러리를 대체하기 위해 SSLeay라는 오픈 소스 구현체를 제작했다. 이 둘이 RSA security[3]로 가면서 개발이 사실상 중단되자 마크 콕스(Mark Cox), 스티븐 헨슨(Stephen Henson) 외 3명이 1998년 SSLeay의 포크를 만들어 개발을 시작한 것이 OpenSSL 프로젝트의 시작이다. 이름 있는 다른 오픈소스들과 비교하면 그렇게 오래 된 편은 아니지만, 적어도 20년은 족히 넘은 셈.

1998년 12월 23일, OpenSSL의 최초 버전인 0.9.1버전이 공개되었다.

2005년 7월 5일 0.9.8 버전이 공개되었다.

2010년 3월 29일, 1.0.0 버전이 공개되었다.

2012년 3월 14일, 1.0.1 버전이 공개되었다. 이때부터 TLS 1.1/1.2, SRP(Secure Remote Password protocol), SCTP, 하트비트를 지원했다.

2018년 9월 11일, 1.1.1 버전이 공개되었다. 이때부터 TLS 1.3을 지원하며, SHA3해싱, ARIA등을 지원한다. 하트비트가 제거되었다. 보수적인 서버 환경에서는 아직도 많이 쓰이는 LTS버전으로, 2023년 9월 11일 지원이 종료될 예정이다.

2021년 9월 7일, 3.0.0 버전이 공개되었다. 2.x 버전이 없이 바로 3.x 버전이 된 이유가 복잡한데, 현재 미국 연방의 FIPS 인증이 취소된 모듈을 사용했기에 2.0.0 버전을 그대로 릴리즈할 수 없어서 2.x 버전을 생략했다고. 해당 버전부터 아파치 라이선스 2.0을 사용한다.

2023년 3월 14일, 3.1.0 버전이 공개되었다.

2023년 11월 23일, 3.2.0 버전이 공개되었다.

2024년 4월 9일, 3.3.0 버전이 공개되었다.

2024년 10월 22일, 3.4.0 버전이 공개되었다. 현재 Stable 버전이다.

3. 상세

주로 X.509 표준의 인증서 생성, 인증 요청 발급, 인증, 인증서 검증 등의 작업에 사용된다. TLS 프로토콜 처리에도 사용되며, 현재 가장 최신인 TLS 1.3까지 다양한 종류의 SSL/TLS 프로토콜 버전을 지원한다.

OpenSSL 라이브러리는 크게 libssl과 libcrypto로 나눌 수 있는데, libssl은 SSL/TLS 프로토콜 관련 핵심 기능들을 가지고 있고 libcrypto의 경우 다양한 종류의 암호화 알고리즘들을 제공한다.

본체는 C 라이브러리 형태이지만, Python Java 등 거의 대부분의 프로그래밍 언어별로 다양한 OpenSSL 바인딩이 존재한다.

흔히 리눅스 서버 관리시에는 openssl 명령어를 통해 CLI 형태로 사용한다. cli만으로도 라이브러리가 제공하는 대부분의 기능을 사용할 수 있다.

3.1. 지원하는 알고리즘

4. 주요 보안 이슈

과거부터 현재까지 수많은 기업에게 신뢰받으며 사실상 표준으로 쓰이는 중요한 라이브러리인 것에 반해 소스코드가 전부 공개되어있는 OpenSSL 특성상 전 세계 해커들의 공격, 특히 제로 데이 공격에 취약하다. 누군가 코드를 읽고 중요한 보안 결함을 알아냈어도, 그걸 이슈로 달지 않고 자신이 써먹으면 아무도 모르기 때문.

4.1. ASN.1 서비스 거부 취약점

OpenSSL 0.9.6k 버전에 존재했던 이슈. 특정한 ASN.1 바이트 시퀀스를 입력하면 윈도우 환경에서 끝없는 재귀를 발생시키는데, 윈도우가 수많은 재귀를 핸들링하지 못하게 되는 순간 OpenSSL이 크래시를 일으키게 된다.

4.2. OCSP 스테플링 취약점

CVE-2011-0014. TLS 핸드셰이크 과정에서 클라이언트가 비정상적인 ClientHello 메시지를 날렸을 때 OpenSSL이 EOF너머의 데이터를 읽게 만드는 취약점. OpenSSL 1.0.0에서 1.0.0c 사이의 버전에 존재했다. OpenSSL이 존재하지 않는 주소값을 읽게 해 세그먼트 폴트를 일으키거나 ClientHello메시지 뒤의 메모리를 읽을 수 있게 하는 취약점으로, 하트블리드 취약점과 상당히 유사하다.

4.3. ASN.1 BIO 취약점

CVE-2012-2110. 2012년 4월 19일 처음으로 보고되었다. BIO(Basic I/O)를 사용해 미인증된 DER 포맷 데이터를 읽어들일 때 발생했다.

4.4. TLS 평문 복호화 취약점

CVE-2013-0169. 2013년 2월 5일 On the Security of RC4 in TLS and WPA에서 발표되었다. TLS에서 CBC[6] 암호화를 사용할 때 발생하는 MAC 처리 지연(timing attack)을 노린 취약점.

4.5. 비밀키 예측 공격

데비안 배포판에서만 나타난 취약점. 발그린드의 경고 메시지를 없애기 위해 데비안의 메인테이너가 수정한 버전의 OpenSSL이 이 실수로 인해 기존의 엔트로피 기반 의사난수 생성 알고리즘이 손상되어 생성 가능한 값의 범위가 겨우 32768개가 되어버린 사건이다. 이 상태로 OpenSSL 0.9.8 버전이 데비안에 들어간 채 배포되었고, 같은 데비안 저장소를 사용하는 우분투에도 배포되었다.

이후 데비안 4.0버전이 릴리즈되며 수정되었다.

4.6. 하트블리드

파일:external/heartbleed.com/heartbleed.png

가장 유명하고도 치명적이었다고 평가받는 OpenSSL의 보안 결함. 이거 하나 때문에 전세계적으로 수많은 서버들이 보안 업데이트를 진행해야 했고, LibreSSL 포크가 만들어지기도 했다.
파일:상세 내용 아이콘.svg   자세한 내용은 하트블리드 문서
번 문단을
부분을
참고하십시오.

4.7. CCS 인젝션 취약점

CVE-2014-0224. OpenSSL의 keyring과 관련된 취약점으로, 조작된 형태의 핸드셰이크를 사용하여 유저가 약한(weak) keyring을 쓰도록 만들어 중간자 공격을 가능하게 만들 수 있다. 해당 취약점은 1.0.1 버전 미만의 모든 버전에 존재한다.

4.8. ClientHello sigalgs 서비스 거부 취약점

CVE-2015-0291. 만약 클라이언트가 OpenSSL 1.0.2를 사용하는 서버에 접속한 후 비정상적인 시그니처로 재연결(renegotiates)을 시도한다면 서버 쪽에서 null 포인터 역참조가 일어나 서비스 거부 공격을 할 수 있다. 스탠퍼드 대학교의 보안 연구원인 David Ramos의 비공개 제보로 패치되었다. OpenSSL 팀의 발표에 따르면 빠르게 처리되지 않았다면 굉장히 심각했을(high-severity) 취약점이었다고.

5. 포크 및 대체제

OpenSSL이 워낙 유명하고 사실상 표준 취급이지만 그만큼 해커들로부터의 공격 순위 1위이고 안전성을 위해 업데이트 주기가 굉장히 느리기 때문에, 이런 단점들을 보완하기 위해 생겨난 여러 포크들이 존재한다.
  • LibreSSL: OpenSSL의 여러 보안 결함(특히 하트블리드)을 개선하기 위해 시작된 OpenBSD 산하 프로젝트로, 기능 및 인터페이스 면에서 호환성을 유지하면서 더 안전한 구현을 목표로 한다. OpenSSL의 오래된 코드를 계속 뜯어고치려고 노력 중인데, 포크 이후 개발 1주일 만에 9만줄에 달하는 C 코드를 제거했다고. #
  • BoringSSL: 구글이 개발하는 OpenSSL의 포크 버전으로, 2014년 6월부터 구글 서비스에서 사용하기 위해 시작된 프로젝트다. LibreSSL과는 다르게 일반 사용 목적으로 출시된 라이브러리가 아니며 일부 호환성 문제가 존재한다[7]. 구글의 Go에도 탑재되었다. 이후 BoringSSL을 기반으로 Tink라는 라이브러리를 개발했다.

OpenSSL이 존재함에도 특정 목적을 위해 처음부터 만든 경우도 존재한다. 이 경우 호환성은 당연히 보장되지 않는다.
  • GnuTLS: GNU 프로젝트에서 2003년부터 개발하기 시작한 TLS 라이브러리. 만든 이유는 OpenSSL의 라이선스가 GPL과 호환이 안 되기 때문이었다고. GNU 산하 프로젝트 답게 GNOME, GnuPG 등에서 사용된다.

6. 기타

OpenSSH가 내부적으로 OpenSSL을 사용한다.

7. 관련 문서


[1] 3.0 버전 이후[2] 1.x 버전 이하[3] RSA 암호를 개발한 그 회사가 맞다.[k] [k] OpenSSL docs | ciphers[6] 블록 암호화를 사용할 때 사용되는 블록 체이닝 기술 중 하나.[7] 설명부터 오픈소스이긴 하나 일반적인 목적의 사용엔 권장하지 않으며 ABI나 API가 경고 없이 변경될 수 있다고 명시되어 있다.