하트블리드

1. 개요

Heartbleed

2014년 IT와 금융 업계 등 사회 각지에 갑작스레 닥쳤던 대재앙급 보안 이슈이자 이 이슈의 중심점인 보안 취약점의 별칭.

2014년 4월 1일에 핀란드의 보안 회사 코데노미콘에서 상당수의 웹사이트에서 사용되는 OpenSSL의 보안 결함을 발견하고 이를 발표하면서 세간에 널리 알려진 사태다.[2]

2. 설명

2.1. 이름의 유래

대다수의 웹사이트는 사용자 컴퓨터와 서버 컴퓨터가 정보를 교환할 때 OpenSSL이라는 오픈 소스 소프트웨어를 사용한다. 사용자측 컴퓨터와 서버측 컴퓨터가 웹사이트에서 정보를 주고받을 때마다 암호화 및 복호화라는 일련의 과정을 거치는 것이다. 여기서 주고받는 정보란 사용자가 해당 웹사이트에서 입력해서 서버로 보내는 모든 정보를 일컬으며 웬만한 IT 서비스나 카드사, 금융 쪽의 암호 시스템은 대부분 OpenSSL에 의존하고 있다고 보면 된다.

사용자가 웹사이트에서 서버와 정보를 주고받지 않아도 연결은 계속 유지시킬 필요가 있는데 이때 '하트비트( 심장박동)'라고 불리는 OpenSSL 통신신호가 사용된다. 이 사태의 원인은 하트비트의 취약점을 이용하는 것이기 때문에 '하트블리드(심 출혈)'라고 명명됐다.

2.2. 원리

파일:heartbleed_explanation_translated_to_Korean.jpg

하트블리드 버그의 원리를 설명한 xkcd 1354화 번역본

그 여파와는 달리 원리는 허탈할 정도로 간단하다. 파이썬 기준으로 약 300줄이면 취약점을 이용할 수 있다.

사용자측에서 무작위 데이터를 담은 하트비트 패킷을 웹서버에 보낼 때 이 패킷이 얼마만큼의 데이터를 보내는 것인지 명시한다. 서버는 패킷을 전송받은 후 정확히 같은 양의 데이터를 돌려보내면서 연결이 되어 있음을 확인하는 방식이다.[3]

여기서 문제가 발생한다. 사용자의 컴퓨터가 얼마만큼의 데이터를 보냈는지 거짓으로 명시할 경우 황당한 일이 생기는 것이다.[4] 예를 들어 1바이트의 정보를 보내면서 서버에는 64킬로바이트를 보냈다고 한다. 그럼 서버는 같은 양의 64킬로바이트를 다시 보내줘야 하는데 실제로 받은건 1바이트의 정보뿐이라는 모순이 발생한다.[5] 그래서 서버는 메모리에 저장된 다른 정보까지 끌어와 패킷을 채운 후 사용자에게 재전송해 준다.

문제는 이 '메모리에 저장된 뒷부분'에는 웹서버에 특정한 정보를 보여달라는 요청에 대한 쿼리가 포함될 뿐만 아니라 유저 아이디나 암호, 심지어는 암호키까지 온갖 정보가 포함될 수 있다는 점이다.[6] 운이 좋다면 별 의미없는 더미 정보만 전송될 수 있겠지만 최악의 경우 유저의 계정 정보나 심지어는 서버 자체의 접속 권한까지 전송되어 버릴 수 있다. 따라서 해커는 이 결함을 이용해 반복적인 전송과 응답을 받는 과정에서 정보를 축적할 수 있게 되고 그 중에서 유의미한 자료를 건져내면 그걸 토대로 보안을 뚫어버리는 것이 가능해진다. 대표적인 버퍼 오버플로우 취약점이다.

2.3. 버그가 만들어진 경위

이 끔찍한 버그는 2011년 12월 31일 11시 59분에 Robin Seggelmann이라는 엔지니어가 OpenSSL에 Heartbeat를 넣었을 때 같이 삽입되었다. 그의 말에 따르면 가변 길이 체크를 간과하고 코드를 제출한 것이 원인이 되었다고 한다. 물론 이런 실수는 코드 리뷰 단계에서 걸러지는 게 일반적이지만 불행히도 이 버그는 리뷰어조차도 발견하지 못하고 통과되어 릴리즈된 게 화근이 되었다. 그는 이번 사태에 대한 책임이 자신에게 있다고 밝혔으며 코드가 충분히 많은 사람에게 리뷰되지 못했다고 한다.

2.4. 어느 버전이 문제인가

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <[email protected]> and Bodo Moeller <[email protected]> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.
- http://www.openssl.org/news/secadv_20140407.txt

문제가 있는 버전	해결 버전 또는 애초에 기능이 없는 버전
OpenSSL 1.0.2-beta OpenSSL 1.0.1 – OpenSSL 1.0.1f	OpenSSL 1.0.2-beta2 (upcoming) OpenSSL 1.0.1g OpenSSL 1.0.0 (and 1.0.0 branch releases) OpenSSL 0.9.8 (and 0.9.8 branch releases)

버그를 해결하려면 서버 관리자가 1.0.1g 버전을 사용하거나 DOPENSSL_NO_HEARTBEATS 같이 취약한 기능을 비활성화한 상태로 OpenSSL을 재컴파일하면 된다.

3. 반응

3.1. IT 업계에서의 반응

페이스북과 구글, 야후! 등 주요 업계는 자신들이 제공하는 서비스가 상당부분 OpenSSL에 의존함을 인정하고 이에 대한 보안 패치를 제공하겠다고 밝혔다.

모바일 OS 쪽에선 Android 운영체제의 4.1.x 젤리빈이 취약한 것으로 알려져 있다. 4.1.x를 포함한 그 이하 버전이 모두 취약한지에 대해선 논란이 가중되었으나 4.1.1 버전은 확실히 취약하다는 게 밝혀졌다. 일단은 4.1.x를 포함한 그 이하 버전의 안드로이드 기기들은 가능하면 4.2 이상으로 업그레이드하는 것이 권장되었다. 구글에서 하트블리드 관련 보안 패치를 제공했다고 하는데 이것에 대한 적용 여부는 결국 제조사들의 재량에 달려 있다.

Apple은 4월 10일에 iOS, OS X, 주요 웹 기반 서비스( iCloud 등의 서비스 포함)는 하트블리드 결함에서 안전하다고 밝혔다. 사실 애플은 이미 2012년에 OpenSSL은 불안정하다는 이유로 개발자 웹사이트에서 그 사용을 권장하지 않으며 대체제를 사용해야 한다고 명시한 바 있다. 당시엔 OpenSSL이 거의 표준처럼 광범위하게 사용되어 개발자와 사용자들이 입을 모아 애플은 폐쇄적이라고 비판했다. 원래부터 OpenSSL은 iOS에선 아예 포함이 안 되고, OS X에선 지원만 하고 마는 정도였다고 한다.

보안업체 카스퍼스키에선 "이 사태의 가장 무서운 점은 '그동안 어떤, 얼마나 많은 정보가 빠져나갔는지 알 수가 없고 누가 정보를 빼나갔는지에 대한 추적도 불가능하다'라는 것"이라고 밝혔다.

미국의 저명한 컴퓨터 보안 전문가 브루스 슈나이어가 자신의 블로그에서 이 사태를 두고 대재앙급(catastrophic)이라고 일컬었다. 보안 위협에 점수를 1부터 10까지 매긴다고 치면, 하트블리드는 11이라고. 서글픈 건 본인도 인정했듯이 저 블로그도 OpenSSL을 사용하기 때문에 보안에 취약하다는 점이다.

3.2. 금융 업계에서의 반응

금융 업계 쪽에선 그야말로 소리 없는 테러를 당한 것과 다름없다. 거의 모두 별 생각없이 OpenSSL에 의존해 왔기 때문에 누구 잘못이랄 것도 없이 시스템상 근본적인 취약점이 드러난 것이기 때문이다. 그야말로 난리가 났다. IT 업계에 비하면 대처가 좀 느린 편이었고 아예 입장을 밝히지 않는 기업들도 많았다.

3.3. 한국에서의 반응

한국에선 반응이 시큰둥한 편이었다. 워낙 어마어마한 이슈다 보니 외신은 물론이거니와 한국에서도 상당히 수준 높은 기사들이 많이 올라오고 있었는데 이에 대한 대다수 한국인들의 반응은 "별것도 아닌 걸 가지고 기자들이 괜스레 이슈화한다"였다.[7] 여기에는 한국 금융사나 이동통신사 등에 의한 정보유출 및 관리실패 사건이 너무나도 빈번히 일어난 점도 한 몫했다. 즉, 심심하면 유출되는 게 개인 정보고 사실 더 유출될 것도 없는(?) 상태다 보니 반응이 없는게 당연할지도... 하지만 이쪽이 훨씬 심각한 이슈다.[8]

한편 공동인증서 체계와 이 사태를 비교하는 견해가 있는데 OpenSSL을 사용하는 취약점은 서버측의 문제이고, 공동인증서를 사용하는 시스템은 쿠키와 같이 개인을 식별할 수 있는 클라이언트측의 문제로, 양쪽이 공히 보안과 연관이 있기는 하지만 기술적으로는 이 둘을 직접 비교할 수 없다. OpenSSL의 문제는 리눅스와 같이 OpenSSL을 사용하는 서버에만 영향이 있으며 RHEL 같은 오래된 리눅스나 자체 암호화 라이브러리를 사용하는 Microsoft Windows [9], Apple의 macOS [10]와는 관련이 없다.

4. 비판

이 중대한 사태에 대해 오픈 소스 커뮤니티가 제공하는 소프트웨어의 신뢰도와 질에 대해 우려와 비판의 목소리가 높아졌다. 굳이 직접적인 비난의 화살을 돌려야한다면 이 사태의 원인은 당연히 OpenSSL 관련 개발자들에게 있기 때문이다.

오픈 소스는 보는 눈이 많기 때문에 보안에 안전하다고 하지만 오픈 소스라고 해서 보는 눈이 많은 것도 아닌게 인기가 있는 코드는 많은 사람이 보지만 그렇지 않으면 주목을 못 받고 방치되는 게 일반적이기 때문이다.[11]

오픈 소스에서 문제를 발견한 첫번째의 사람이 오픈 소스 보안문제를 공개하리라는 보장도 없다. 다만 보는 사람이 많다는 확률상의 문제일 뿐으로 인기가 없는 코드를 우연히 본 사람이 문제를 발견할 경우 오히려 이를 독점적으로 악용할 여지도 충분히 존재한다. 즉 보는 눈이 많다는 것이 꼭 소스 보완이나 보안적 문제의 조기 종결을 의미하는 것은 아니다.

더욱이 이번 건은 사용자가 많은 오픈 소스임에도 불구하고 하트블리드 사태는 엄연히 일어났고 2년간 방치된 상태였다. 결국 많은 사람들이 소스를 본다는 건 누군가 소스를 책임지고 고친다와는 다른 이야기다. 오픈 소스는 기업이 책임지는 소위 '클로즈드 소스'에 비해 지원이나 참여인원, 책임지는 사람이 적은 것은 당연한 일이다. 이 때문에 오픈 소스라는 방식 자체의 한계와 결함이 단순한 이론이 아닌 현실로 드러난 것이라고 보는 시각도 있다.

관리를 주도하며 관리 의무를 부여받고 전담 모니터링을 할 수 없는 경우이므로 이런 문제에서 자유로울 수 없다.

참고할 만한 오픈 소스 관련 비판글: 오픈이 다시 한번 승리했다?, 하트블리드가 어떻게 인터넷을 망가뜨렸는가 - 그리고 다시 이런 일이 일어날 이유

오픈 소스 커뮤니티 측에선 이런 결함이 발생하는 건 기본적으로 오픈 소스 커뮤니티에 대한 관심과 지원이 부족하기 때문이라고 변명했지만 아무리 많은 관심과 돈을 준다고 하더라도 리뷰는 어디까지나 자유이기 때문에 여전히 편중성이라는 구조적 약점이 존재한다. 오픈 소스라서 더 빨리 발견된 것이라는 주장은 정신승리일 뿐이다. 그런 식이면 클로즈드 소스는 실제 취약점이 있어도 악의적인 목적을 가진 크래커가 취약점을 발견하기도 힘들 것이므로 상대적으로 더 안전하단 논리가 된다.

이 모델이 잘 작동하기 위해서는 충분한 개발 인원과 기금 등의 자원이 필요한데 OpenSSL은 광범위하게 사용된 것에 비하여 가용 자원이 절대적으로 부족하여 충분한 리뷰조차 받을 수 없었다.

OpenSSL을 사용한 이들이 이걸 낼름 받아서 쓰기만 했지 OpenSSL에 별다른 피드백을 주지 않는 경우가 많다. 무책임한 이용자 문제로 볼 수 있지만 무작정 사용자들을 비난할 수도 없는 것이 애초에 오픈 소스의 시작 자체가 무임승차 비율이 높더라도 더 많이 노출되게 해서 그 중에서 충실한 접근인원을 확보하고자 하는 이념, 즉 게임으로 치면 F2P와 비슷한 접근법을 취하고 있는지라 무임승차 비율이 높다고 그들을 비난하는 것은 포인트가 빗나간 것이다. 그런 식이면 코드를 일일이 분석하거나 취약점을 찾아내지 못하는 이들이면 오픈 소스를 이용하면 안 된다는 주장이랑 다를 게 없다.[12] 사실 이들 모두가 반드시 피드백을 한다면 그것도 그것 나름대로 일일이 대처하기 힘든 것도 또다른 문제가 될 수 있다.

개발자들이 기업에게 사용을 강요한 적이 없으므로 책임이 없다는 주장은 틀렸다. 하트블리드 사태를 일으킨 Seggelmann도 자신의 책임을 인정했는데 개발자들에게 면책 운운하는 건 그냥 실드 그 이상도 그 이하도 아니다.

단, 이런 비판은 먼저 오픈 소스 커뮤니티 구조에 대한 이해를 하고 접근해야 한다. 오픈 소스 프로젝트의 소스코드는 유료 서비스가 아니고, 메인테이너는 친절한 소통창구도 아니며, 사용자는 고객이 아니다. 기업에서 지원하기 위해 무료로 자사의 엔지니어를 투입하는 경우가 아니라면 대부분의 개발자는 자원봉사자이다. 오픈 소스 라이센스에 기본적으로 면책 조항 [13]이 포함되는 이유도 이 때문이다. 따라서 이를 오픈 소스의 문제와 한계로만 접근하기 보다는 클로즈드 소스와의 차이라는 관점에서도 접근하는 것이 좋다. 클로즈드 소스로 개발된 프로그램에서 발생한 보안이슈는 내부에서 쉬쉬해버리면 외부에서 모를 수밖에 없고 크게 사건이 터지더라도 해당 개발업체 제품 사용자에게만 피해가 한정된다. 하지만 오픈 소스는 일단 "무료"이고, 코드가 공개되어 있으니 해당 소스코드를 기반으로 개발, 파생된 수없이 많은 프로그램과 시스템이 존재해서 일단 터지면 IT업계가 초토화 되는 것이다. 한마디로 유료 판매 상품이었다면 이렇게 일이 커지지도 않았을 것이라는 것. 리눅스 커널 프로젝트 같은 초대형 프로젝트는 다른 클로즈드 OS보다 몇 배는 빠른 보안 패치가 이루어지기는 등 오픈 소스의 최대 장점인 '보는 눈이 많아 문제가 빠르게 해결됨'을 십분 활용할 수 있지만 관심을 적게 받는 프로젝트는 사용자들 사이에서 인기가 아무리 많아도 메인터너스가 하나, 둘씩 떠나다가 프로젝트가 폐쇄되기도 한다. 어찌보면 강제성이 없기 때문에 갖는 양날의 검이라고 할 수 있다.

결론은 오픈 소스의 가장 근본적인 문제점들을 고스란히 드러낸 사건이라고 볼 수 있다. 물론 이는 클로즈드 소스의 우월성을 입증하는 것이나 반대로 오픈 소스의 열등함을 드러내는 것이 아니다. 오픈 소스 역시 제대로 관리될 수 있으며 클로즈드 소스의 최대 특징인 폐쇄성은 개발주체와 사용주체가 달라지는 경우 사용자 입장에서 개발자를 신뢰할 수 없다면 큰 단점으로 작용하게 된다.[14]

허나 해당 이슈들이 오픈 소스의 문제점인 것은 사실이지만 이는 경제적인 면에서 어쩔 수 없는 한계이기도 하다. 특정 주체가 책임을 갖고 계속해서 유지보수하는 클로즈드 소스의 경우 어쨌든 누군가의 시간을 점유해서 특정 프로젝트의 유지보수에 강제로라도 할당시켜야 하는 만큼 상당한 유지보수 비용이 들게 된다. OpenSSL급의 소프트웨어라면 그 비용은 결코 저렴하지 않다. 그렇게 책임자를 앉혀 놓는다 한들 모든 취약점에 대해서 성심성의껏 투명하게 대응하리란 보장도 없다. 막말로 Intel CPU게이트 사태에서 보듯, 보안적인 관점에서만 놓고 보면 클로즈드 소스냐 오픈 소스냐는 다소 거칠게 말하여서는 결국 "잡아다가 교수대에 매달아서 사회경제적으로 모가지 따고 손배소 소장을 보낼 책임자가 있느냐 없느냐"의 차이만 남는 경우도 충분히 존재한다.

결론부터 말해서 나쁘게 이야기하자면 해당 오픈 소스 프로젝트를 도입한 기업의 담당자들조차 면책 조항을(또는 면책 조항이 포함된 라이선스를)[라이센스_면책조항_원문][라이센스_면책조항_번역] 떡하니 박아놓은 프로젝트를 상용 서비스에 자체검증없이 도입했다가 털려나가는 자업자득이라는 소리이고, 좋게 이야기하면 오픈 소스는 경제적으로든 품질 면에서건 보안이슈에서건 평균적인 가성비는 좋지만 그만큼 신뢰성에는 불가피하고 필연적인 태생적 한계가 있다라는 뜻이다. 개발자의 경우도 어디까지나 "도의적"인 관점에서 책임을 인정한 것이지, 경제적으로 전부 배상하겠다고 하진 않았다. 상술했듯 오픈 소스 특성상 그래야 할 필요도 없고, 그게 맞다. 결론부터 말하자면 OpenSSL 개발자에게 모든 유형의 책임에 대해서 면죄부를 쥐어줘야 한다는것은 잘못된 말이지만, 적어도 법률적, 경제적인 측면에서는 자진해서 "도의적"으로 비용을 "분담"하는 것이나 이러한 위험한 사태를 만든 것에 대하여 "사과" 하는 것이면 모를까 강제집행적인 협의적인 의미의 "책임"의 측면에서는 면책되는 것이 맞으며, 특정 주체에서 안전을 보증하는 상용품이 있음에도 별다른 자체 검증 없이 오픈 소스를 사용하기를 선택한 기업들도 일방적인 피해자라고 할 수 없다는 것은 사실이다.

5. 이후

하트블리드 사태 이후로 ~~틈새시장공략~~ OpenBSD 개발 멤버들이 OpenSSL의 포크로 LibreSSL을 만들었다. 이 파생본의 목적은 OpenSSL의 잠재적인 위험이 있는 소스들을 쳐내고 OpenBSD의 보안 가이드라인에 맞추어서 더 안전한 소스로 갈아엎는 것이다. 거의 보안을 병적으로(...) 중시하는 OpenBSD 커뮤니티가 참여하기 때문에 LibreSSL의 보안은 기대해 봐도 좋을 듯하다. 구글도 BoringSSL이라는 포크를 만들어서 OpenSSL과 LibreSSL 개발자와 연계하여 버그 픽스를 진행하고 있다.[17]

한편, 전술한 것처럼 오픈 소스의 지속적인 관리를 위한 가용 자원을 확보, 공급하려는 목적으로 Core Infrastructure Initiative가 발족되었다. 아마존, 어도비, 인텔, 구글, 시스코, 후지쯔, 퀄컴 등 같은 IT 업계의 어마어마한 거물[18]들이 최소 360만 달러 이상의 자금[19]을 출자했으며, 이 자금의 관리는 리눅스 재단이 맡게 되었다.

6. 기타

전세계 인터넷을 지켜보기로 유명한 NSA가 이 버그를 이미 알고 있었다는 일부 언론의 지적이 있었다. CNET NSA는 이 주장을 부인했다.

이 사태 이후 광범위하게 적용되는 일부 위험한 취약점들에 대해 셸쇼크, 고스트, 윈쇼크, 푸들, 프리크, 블루본, 멜트다운, 스펙터 등 취약점에 다채로운(?) 이름을 붙이는 게 유행이 되었다. 긍정적인 효과로, 이후 소프트웨어 취약점이 언론에 꽤 널리 퍼져서 사람들에게 경각심을 조금이나마 더 주게 되었다.

마치 이 사태 이후 심각한 취약점들이 점점 늘어나고 있다는 착각이 들 수도 있지만 실제로는 이전에도 CVE 외에 특별한 명칭이 따로 붙지 않았을 뿐이지 심각한 취약점은 이미 많았다. 즉, 이런 기사처럼 특히나 최근에 취약점이 예전에 비해 점점 더 많이 발견된다는 듯한 말은 맞지 않다. 정확히 말하면 언론에 알려지는 취약점이 늘어났다고 봐야 할 것이다. 예나 지금이나 매년 심각한 취약점은 무수히 발견되고 있고 이는 10년 넘게 특별히 변하지 않았다. 다만 안드로이드/iOS 와 같이 수많은 사람들이 이용하게 된 모바일 플랫폼이 생기면서 이런 플랫폼에서 발견되는 취약점은 그 위험도가 더 크기 때문에 예전보다 좀 더 부각되는 면은 있다. 실생활에 수많은 사람들이 이용하는 컴퓨팅 플랫폼이 늘어날수록 심각한 취약점은 점점 늘어날 것이고 나중에는 이러한 취약점 하나로 원하는 타겟을 별다른 유저 인터렉션이 필요 없이 정확히 공격할 수 있게 될 수도 있다.[20] 결국 하트블리드 이후 약 7년만에 또 다른 취약점이 발생하고 말았다.

7. 관련 문서

[1] 하트블리드라는 이름과 함께 대중의 인식을 이끌어내는데 크게 기여했다. [2] SSL 프로토콜 자체를 말하는 것이 아니다. 물론 SSL도 문제점이 있기는 하지만. [3] 굳이 무작위 데이터가 담긴 하트비트 패킷을 보내야 하는지 의문이 들 수 있는데 이는 서버 응답 오류의 원인이 응답 지연인지 패킷 손실인지 구분하기 위함이다. 예를 들어서 1분 간격으로 3회의 데이터를 보냈는데 3번째 데이터를 보낸 직후 서버가 응답했다면 사용자는 이 응답이 첫번째 요청이 지연되어 회신이 늦은 것인지, 아니면 일부 패킷이 손실되어 3번째 응답만 받은 것인지를 확인하기 어렵다. [4] 이는 조건문을 통해 간단히 해결할 수 있는 문제다. [5] 가변 길이 데이터를 주고받는 경우에는 의도적으로 왜곡된 정보가 들어올 수 있음을 항상 고려해야 한다. 배열에서 데이터를 카피할 때는 항상 정해진 경계보다 많은 양을 복사하는 일이나 경계보다 많은 양의 데이터를 배열에 덮어씌우는 일도 보안상 위험천만한 행위다. 고전적이라면 고전적인 취약점이고 이를 유념하는 것은 보안 상의 기본적인 원칙인데 이런 원칙을 고려하지 않은 몇 줄의 코드가 재앙적인 결과를 불러왔다는 점은 눈여겨볼 만하다. [6] C언어와 기계어의 포인터를 악용한 버그를 생각하면 된다. [7] 어찌보면 문제점이 극도로 근본적인 것이었고, 그에 따라 IT 전문매체에서 논하는 내용이 그만큼이나 밑도 끝도 없이 막연하고 어려웠기 때문에 대다수 평범한 사람들이 아예 이해를 못 해 버린 것일 수 있다. 또는 하트블리드와 관계없는 0.9.x, 1.0.0 버전을 사용 중이었을 수 있다. [8] 개인 정보 유출 사태는 해당 기업/관공서의 이용자에게만 영향을 끼친다면 하트블리드 사태는 OpenSSL을 사용하는 사실상 모든 기업·인프라·기업·유저에게 영향을 끼친다. [9] SSPI [10] Secure Transport [11] 멀리 갈 것도 없이 당장 나무위키만 봐도 이 문제는 명확하다. 여러 사람의 관심을 받는 문서는 하루에 수십회 이상 편집되면서 각 편집자가 문서 내용을 교차평가하고, 문제의 여지가 있는 서술이나 의견충돌이 발생할 경우 바로 토론을 통해 해결을 시도하는 경우도 흔하지만 별 관심을 받지 못하는 문서는 봇에 의한 편집 정도를 제외하면 수개월~수년에 한번씩 기여가 들어올까 말까 하는 경우도 많은데 이런 경우 잘못된 내용이 있어도 보는 사람이 없어서 장기간 방치되는 것이 전혀 이상하지 않다. 프로젝트 전체의 신뢰성이라는 점에서 비유해 보면 나무위키 전체의 평균적인 신뢰도는 '완전히 엉터리는 아니지만 편향적이거나 검증되지 않은 내용이 있을 수 있기 때문에 참고자료로는 쓸 수 있어도 신뢰할 수는 없는' 정도에 해당할 것이다. 하지만 다수의 편집자가 계속 관심을 가지고 기여하며 교차검증/평가가 이루어지는 문서라면 공신력을 가진 언론이나 학술자료에 비교해도 크게 뒤떨어질 것 없는 양질의 문서가 나타나는 것도 충분히 가능한 반면 별 관심을 받지 못하는 문서라면 말도 안 되는 엉터리 내용이 방치되어 질 나쁜 익명 커뮤니티의 악의적 뻘글이나 다름없는 수준까지 신뢰성이 떨어질 수도 있다. 결국 오픈 소스 프로젝트의 장점을 인정하더라도 그 장점이 프로젝트 전반에서 충분히 발휘될 수 있느냐는 또 별개의 문제인 셈이다. [12] 하지만, 이용하면 "안"된다는 주장과 이용하는 건 자유이나 자기책임하에 사용해야 한다는 주장은 전혀 다른 논지이다. 즉, 이게 뭔지 모르고 갖다 넣는 건 본인들 자유이지만 그러다 탈 나는 이슈들에 대해서는 갖다 넣은 사용자 잘못이라는 것이다. [13] 본 프로그램을 사용함으로써 발생하는 문제에 대해 개발자는 일체의 책임을 지지 않는다는 조항이 반드시 들어간다. 백도어를 심는게 아닌 이상 갑자기 오류가 생겨 피해를 입더라도 책임질 수 없다는 것. [14] 예를 들면 인텔 관리 엔진 관련 보안 이슈가 발생했음에도 AMD역시 펌웨어 소스코드를 공개하지 않는 것은 마찬가지라는 이유로 구글은 하드웨어 교체가 아닌 관리엔진을 대체할 NERF라는 자체 소프트웨어를 개발했다. [라이센스_면책조항_원문] THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) [라이센스_면책조항_번역] 이 소프트웨어는 OpenSSL Project에 의해서 있는 그대로 제공되며, 상용성과 특정 목적으로써의 적합성에 대해 명시된 보증을 포함하여 그 외 어떠한 명시된, 또는 암시된 보증을 하지 않습니다. 직접, 간접, 우발적, 특수한, 예외적인 또는 결과적인 손해(사용성, 데이터, 또는 수익, 영업방해로 인한 손실 등 부수 재화나 서비스에 대한 손해, 또는 그 외의 모든 유형에 대한 손해)에 대해 OpenSSL 프로젝트 또는 그 프로젝트의 기여자들은 그 어떠한 상황에서도 책임이 없습니다. [17] 다만 BoringSSL은 OpenSSL과 달리 크로뮴, 안드로이드 등에만 탑재되어 보안 처리를 위해 사용된다. 소스 코드를 가져다 사용하는것은 별도로 지원하지 않는 것이다. [18] 재밌게도 오픈 소스 진영에게 가장 많이 까이는 기업 중 하나인 마이크로소프트도 출자에 참여했다. 사실 사티아 나델라의 성향을 감안하면 마이크로소프트의 행보가 이상한 것은 아니다. [19] 정확한 규모는 밝혀지지 않았다. [20] Stagefright 취약점처럼 MMS 문자 전송만으로 대상을 해킹할 수 있는 경우를 예로 들 수 있다. 이런 경우는 날이 가면 갈수록 늘어날 것이고 현재도 발견되지 않은 채로 이용되고 있는 것들이 많을 것이다.