Heartbleed : 무엇이며이를 완화 할 수있는 옵션은 무엇입니까?


204

이것은 Heartbleed 보안 문제를 이해하고 개선 하는 것에 관한 정식 질문 입니다.

CVE-2014-0160 AKA "Heartbleed"란 정확히 무엇입니까? 원인, OpenOS의 OS 및 버전이 취약한 이유, 증상은 무엇이며 성공적인 악용을 탐지하는 방법이 있습니까?

시스템이 영향을 받는지 어떻게 확인할 수 있습니까? 이 취약점을 어떻게 완화 할 수 있습니까? 내 키 또는 기타 개인 데이터가 손상되었는지 걱정해야합니까? 다른 부작용은 무엇입니까?


14
Heartbleed에 대한 완화 에는 새로운 키 이상의 것이 포함됩니다 . (Information Security StackExchange에 대한 내 답변 링크)
scuzzy-delta

나는 당신의 말을 듣지만, EEAA는 아래에서 그것을 포괄적으로 다루었다고 생각합니다.
MadHatter

동의합니다. 훌륭한 답변이지만 heartbleed.com 은 암호 변경 및 세션 무효화와 같은 새로운 키 쌍 이외의 고려 사항이 있음을 지적하기 위해 최선을 다하고 있습니다.
scuzzy-delta

1
@ scuzzy-delta-좋은 지적입니다. 지금 CW를 만들었으므로 해당 정보를 사용하여 자유롭게 편집 / 개선하십시오.
EEAA

답변:


118

먼저 , 기절하기 전에이 취약점이 실제로 자신에게 적용되는지 여부를 이해해야합니다. 서버가 있지만 실제로 TLS를 사용하는 응용 프로그램이없는 경우에는이 문제를 해결하는 것이 우선 순위가 아닙니다. 반면에 TLS 지원 애플리케이션 을 보유한 적이 있다면 치료를받을 수 있습니다. 읽어:

CVE-2014-0160, 즉 "Heartbleed"란 정확히 무엇입니까?

그것은 큰 혼란스러운 혼란입니다. 요컨대, 공격자가 시스템 메모리의 특정 부분을 읽을 수있는 OpenSSL 버전 1.0.1 ~ 1.0.1f에서 원격으로 악용 가능한 취약점이 발견되었습니다. 개인 키, 미리 공유 한 키, 암호 및 중요한 기업 데이터와 같은 중요한 데이터를 보유하는 부분입니다.

이 버그는 Google Security의 Neel Mehta (2014 년 3 월 21 일)와 핀란드의 IT 보안 테스트 회사 인 Codenomicon (2014 년 4 월 2 일)에 의해 독립적으로 발견되었습니다.

원인이 무엇입니까?

글쎄, OpenSSL의 잘못된 코드입니다. 여기 에 취약점을 도입 한 커밋이 있고 여기에 취약점을 해결 한 커밋이 있습니다. 이 버그는 2011 년 12 월에 나타 났으며 오늘 2014 년 4 월 7 일에 패치되었습니다.

버그는 더 큰 문제의 증상으로 볼 수도 있습니다. 두 가지 관련 문제는 (1) 잘못된 코드가 코드베이스에 도입되지 않도록하는 프로세스와 (2) 프로토콜과 확장이 왜 그렇게 복잡하고 테스트하기 어려운지입니다. 항목 (1)은 OpenSSL 및 기타 여러 프로젝트의 거버넌스 및 프로세스 문제입니다. 많은 개발자들이 코드 검토, 분석 및 스캔과 같은 관행에 저항하기 만합니다. 항목 (2)는 IETF의 TLS WG에서 논의되고 있습니다. Heartbleed / 프로토콜 복잡성을 참조하십시오 .

잘못된 코드가 악의적으로 삽입 되었습니까?

나는 이것이 정말로 실수인지 나쁜 행위자를 대신하여 약간의 코드가 미끄러 졌는지 추측하지 않을 것이다. 그러나 OpenSSL 용 코드를 개발 한 사람은 코드가 잘못되었다고 말합니다. 참조 그가 의도적으로 삽입 거부 심각한 'Heartbleed와'보안 결함을 도입 남자 .

어떤 OS 및 OpenSSL 버전이 취약합니까?

위에서 언급했듯이 OpenSSL 1.0.1 ~ 1.0.1f에 연결된 모든 운영 체제 또는 응용 프로그램.

성공적인 악용을 탐지하는 방법에는 어떤 증상이 있습니까?

이것은 무서운 부분입니다. 우리가 아는 한,이 취약점이 악용되었는지 여부를 탐지하는 알려진 방법은 없습니다. 이론적으로이 악용을 탐지 할 수있는 IDS 시그니처가 곧 릴리스 될 수 있지만이 문서를 작성할 당시에는 사용할 수 없습니다.

Heartbleed가 2013 년 11 월 초에 야생에서 활발하게 이용되고 있다는 증거가 있습니다. EFF의 Wild at Heart : 2013 년 11 월에 Heartbleed를 사용한 정보 기관이 있었습니까? 그리고 Bloomberg는 NSA가 취약점이 도입 된 직후에이 취약점을 악용했다고보고했습니다. 수년 동안 인텔리전스를 위해 하트 블리드 버그를 악용하기 위해 NSA에서 발표 한 내용 참조 . 그러나 US Intelligence Community는 Bloomberg의 주장을 부인합니다. 레코드의 IC를 참조하십시오 .

시스템이 영향을 받는지 어떻게 확인할 수 있습니까?

시스템에서 OpenSSL을 유지 관리하는 경우 간단히 다음을 발행 할 수 있습니다 openssl version.

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

배포판이 OpenSSL을 유지 관리하는 경우openssl 명령 또는 패키지 정보 (예 apt-get: dpkg, yum또는 rpm)를 사용하여 백 패치로 인해 OpenSSL 버전을 확인할 수 없습니다 . 대부분 (전체?) 배포에서 사용하는 백 패칭 프로세스는 기본 버전 번호 (예 : "1.0.1e") 만 사용합니다. 효과적인 보안 버전 (예 : "1.0.1g")을 포함 하지 않습니다 .

패키지가 백 패치 될 때 OpenSSL 및 기타 패키지의 효과적인 보안 버전을 결정하기 위해 수퍼 유저에 대한 공개 질문이 있습니다. 불행히도, 유용한 답변은 없습니다 (distro의 웹 사이트 확인 이외). 백 패칭에 직면 할 때 유효 보안 버전 확인을 참조 하십시오 .

일반적으로 영향을받는 버전 중 하나를 설치하고 OpenLS와 TLS 지원을 연결하는 프로그램이나 서비스를 실행 한 적이 있다면 취약합니다.

취약점을 테스트 할 프로그램을 어디서 찾을 수 있습니까?

Heartbleed 발표 후 몇 시간 내에 인터넷상의 여러 사람들이 공개적으로 액세스 할 수있는 웹 응용 프로그램을 공개하여이 취약점이 있는지 서버를 확인하는 데 사용될 수 있습니다. 이 글을 쓰는 시점에서, 나는 아무 것도 검토하지 않았으므로 그들의 응용 프로그램을 더 이상 공개하지 않을 것입니다. 선호하는 검색 엔진의 도움으로 비교적 쉽게 찾을 수 있습니다.

이 취약점은 어떻게 완화됩니까?

취약하지 않은 버전으로 업그레이드하고 취약한 데이터를 재설정하거나 다시 보호하십시오. Heartbleed 사이트 에 명시된 바와 같이 적절한 대응 단계는 다음과 같습니다.

  1. 취약한 시스템을 패치하십시오.
  2. 새로운 개인 키를 재생성하십시오.
  3. CA에 새 CSR을 제출하십시오.
  4. 서명 된 새 인증서를 확보하여 설치하십시오.
  5. 세션 키 및 쿠키 무효화
  6. 비밀번호 및 공유 비밀번호 재설정
  7. 오래된 인증서를 해지하십시오.

자세한 분석 및 답변 은 웹 사이트 운영자가 Heartbleed OpenSSL 익스플로잇에 대해 어떻게해야합니까?를 참조하십시오 . 보안 스택 교환에.

내 키 또는 기타 개인 데이터가 손상되었는지 걱정해야합니까? 다른 부작용은 무엇입니까?

물론. 시스템 관리자는 취약한 OpenSSL 버전을 사용하는 서버가 실제로 손상되어 그에 따라 대응 한다고 가정 해야합니다 .

이 취약점이 공개 된 직후 Cloudfare는 서버의 개인 키를 실제로 복구 할 수 있는지 확인하는 문제를 제기했습니다. 도전은 Fedor Indutny와 Ilkka Mattila에 의해 독립적으로 이겼습니다. Heartbleed Challenge를 참조하십시오 .

자세한 정보는 어디서 찾을 수 있습니까?

자세한 내용을 찾는 사람들을위한 링크 덤프 :


공개 이벤트의 다소 자세한 타임 라인은 Heartbleed 공개 타임 라인 에서 확인할 수 있습니다 . 누가 언제 무엇을 알고 있었는지 알 수 있습니다 .


프로그래머이고 OpenSSL의 msg_cb콜백을 통한 Heartbleed 공격 탐지와 같은 다양한 프로그래밍 기법에 관심이있는 경우 OpenSSL의 보안 권고 2014047 을 참조하십시오 .


42
SHUT +1 내려가는. 너의. 서버. * -SSL이 정말로 중요한 곳에서 작업을 수행하는 경우 문제를 해결할 때까지 끄십시오. 또한 (새로운 인증서를 설치하는 것을 잊지 마세요 새 키 는 서버 패치 후) - 기존의 키 (손상되었을 수 있음) 취약점을 패치의 전체 목적을 패배 ... 재사용
voretaq7을

29
또한 -OpenSSL 라이브러리에 연결된 모든 서비스를 다시 시작하십시오. 데몬을 다시 시작하지 않고 OpenSSL을 업그레이드하는 것은 전혀 업그레이드하지 않는 것만 큼 좋습니다.
EEAA

14
실제로-OpenSSL과 같은 주요 패치 후에는 컴퓨터를 재부팅하여 아무것도 놓치지 않도록하는 것이 좋습니다.
voretaq7

5
테스터 중 하나가 오픈 소스되었습니다 : github.com/FiloSottile/Heartbleed
Riking

3
@EEAA, "서버 종료"가 전원을 꺼야한다는 의미는 아닙니다. 아파치 또는 서비스를 수행하는 모든 서비스를 종료 (또는 ssl / tls 비활성화하도록 재구성)하는 것을 의미합니다.
psusi


36

우분투 12.04, 12.10 및 13.10

Ubuntu는 USN-2165-1 을 발행 했으며 , 업데이트 된 패키지는 이제 아카이브에서 사용할 수 있습니다. 다음 두 명령을 실행하여 수정 사항을 가져 오십시오.

sudo apt-get update
sudo apt-get upgrade

우분투 14.04

새 릴리스 (1.0.1g)가 포함 된 데비안 패키지를이 목적으로 설정 한 PPA에 업로드했습니다. 이 세 명령은 시스템에 PPA를 추가하고 사용 가능한 패키지 목록을 업데이트하며 모든 것을 업그레이드합니다.

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

참고 : PPA는 또한 아카이브에서 패치 된 버전을 사용하는 대신 실제로 새 버전 (1.0.1g)을 실행하려는 경우를 대비하여 Ubuntu 12.04 및 13.10 용 패키지를 제공합니다.

우분투 10.04

이것은 LTS 버전이며 서버 버전은 여전히 ​​지원되며 보안 업데이트를받습니다. 그러나 heartbleed 취약점은 버전이 1.0.1보다 낮기 때문에 표준 우분투 10.04 설치의 openssl 패키지에 영향을 미치지 않았습니다.

데스크탑 버전의 수명이 다하여 업그레이드 / 다시 설치해야합니다.

우분투 13.04 및 기타 오래된 버전

Ubuntu 13.04의 지원주기는 매우 짧아 예상치 못한 결과를 낳았습니다. 이미 수명이 다했으며 더 이상 보안 업데이트를받지 않습니다. 오랫동안 업그레이드 되었어야합니다. 여전히 누군가가 사용하고 있다면 지금 처음부터 업그레이드하거나이 쉬운 절차에 따라 비파괴 적으로 13.10으로 업그레이드 할 수 있습니다. http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail -to-ubuntu-13-10-saucy-salamander / 업그레이드 후 시스템은 13.10부터 heartbleed 패치를받습니다.

다른 모든 오래된 우분투 버전의 경우 기본적으로 새로 설치해야 함을 의미합니다.

패치가 적용되었는지 확인

기본적으로 openssl version -a빌드 날짜가 2014 년 4 월 7 일 이상인지 확인하고 자세한 내용은 여기를 참조 하십시오 .

재부팅

OpenSSL에 따라 모든 서비스가 다시 시작되도록하는 가장 좋은 방법은 재부팅하는 것 입니다.


다른 버전에서는 말할 수 없지만 정확한 패치 (12.04)가있는 것 같습니다. 이것이 취약점을 해결한다고 확신 할 수는 없지만 관련 커밋 ( Mon Apr 7 20:31:55 UTC 2014) 이후에 컴파일 된 것 입니다.
Calrion

@Calrion : OpenSSL 용 패치 또는 OpenSSL 용 데비안 패키지? OpenSSL은 이미 수정되었으며 새 릴리스가 발행되었습니다.
Nathan Osman

openssl이 업데이트되는 동안 기존 연결은 어떻게됩니까? 그들은 떨어질 것인가?
pdeva

2
사용중인 웹 서버와 업데이트 방법에 따라 다릅니다. 즉, 기존 연결이 취약한 버전을 사용하고 있기 때문에 기존 연결을 삭제하는 것에 대해 걱정하지 않습니다.
Nathan Osman


14

RedHat 6.5 및 CentOS 6.5

이들은 취약하다. RedHat의 정오표 RHSA-2014-0376에 따르면 패치 된 라이브러리가 있으며 영향을받는 사람은 가능한 한 빨리 업그레이드해야합니다.

작성 당시 CentOS에는 아직 고정 버전이 없었지만 Karanbir Singh의 CentOS-announce에 게시openssl-1.0.1e-16.el6_5.4.0.1 하면 악용 가능한 TLS가 있는 업데이트 된 버전의 openssl ( , 중요한 마지막 네 자리 참고)을 생성 했다고 말합니다. 명령을 사용할 수 없으며, 최종 릴리스시 고정 버전으로 덮어 쓰므로 안전하게 적용 할 수 있습니다.

임시로-고정 된 버전은 아직 모든 거울에 그것을 만든 것 같다,하지만의 주요 저장소에없는 http://mirror.centos.org/centos/6/updates/x86_64/Packages/ 에 대한 유사 (그리고 i686).

편집 : Iain이 말했듯이 이제 C6.5의 정식 패치 버전이있는 것으로 보이며 서둘러 거울 주위로 밀린 것 같습니다. 곧은 yum update내 서버를 위해 그것을 얻었다; 그것은이다 openssl-1.0.1e-16.el6_5.7.

6.5 이전의 RH6 및 C6 버전

이들은 취약하지 않습니다. Red Hat의이 권고 에 따르면 ,

이 문제는 Red Hat Enterprise Linux 5 및 Red Hat Enterprise Linux 6.4 및 이전 버전과 함께 제공되는 openssl 버전에는 영향을 미치지 않았습니다.

CentOS-announce에 Karanbir Singh의 게시물 은 버전 관리에 대해 똑같이 명확합니다.

오늘 당일, CentOS-6.5에서 제공되는 openssl의 심각한 문제에 대해 알게되었습니다.



13

데비안 휘지

데비안은 DSA-2896-1을 발행 했으며 패치 된 라이브러리는 여기에서 구할 수 있습니다 . 쉘 스크립트는 여기에 있습니다 .

1. 패치

Apt-get 저장소가 업데이트되었으므로 이제 패치 된 라이브러리를 통해 사용할 수 있습니다 apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

패키지를 수동으로 업그레이드 할 수도 있습니다 (권장하지 않음).

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. 서버 / 서비스 재시작

최상의 보호를 위해 전체 서버를 다시 시작하거나 서버가 오프라인 일 수없는 경우 필요한 서비스를 다시 시작하십시오.

3. OpenSSL 버전 확인

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

1
에서 업데이트를 받으면에 wheezy/security도움이 될 것입니다 apt-get update && apt-get upgrade. 또는 패키지 만 업데이트하는 대화 형 패키지 관리자를 사용하여 openssl, libssl1.0.0, libssl1.0.0-dbglibssl-dev(시스템에 설치 참조).
CVn

apt-get을 사용해도 문제가 해결되지 않습니다-여전히 OpenSSL 1.0.1e가 표시됨 2013 년 2 월 11 일
user568829

@ michael-kjorling에게 감사드립니다.이 작업을 수행 할 때 사용할 수 없었지만 가장 안전하고 올바른 업그레이드 방법입니다.
jacksoncage

2
패치를 적용한 후 @ user568829 openssl 버전은 여전히 OpenSSL 1.0.1e 11 Feb 2013패치가 1.0.1e-2로 표시됩니다. 확인할 수 있으며 dpkg -l openssl버전을 표시해야합니다1.0.1e-2+deb7u6
jacksoncage

2
OpenSSL을 업데이트 한 후 호스트를 다시 시작하는 것이 좋습니다. 꼭 필요한 것이 아니라 OpenSSL 라이브러리를 동적으로로드하는 모든 것이 새 버전을 사용하고 있다는 점을 명심하십시오. (정적으로 연결된 것이 또 다른 문제입니다.) 즉, 서비스 재시작이 허용되는 모든 상황에서 일부 서버를 쉽게 재부팅 할 수 없다는 것을 알고 있습니다.
CVn

9

개인 키는 손상된 것으로 간주되어야하는 유일한 자산이 아니라는 점을 지적하고 싶습니다. 버그가 누출 할 가능성 갖는 임의 OpenSSL이 동일한 주소 공간 (즉, 동일한 공정)에서 실행되는 메모리. 따라서 취약한 버전의 OpenSSL이 정적으로 또는 동적으로 링크 된 서버 프로세스를 실행하는 경우 비밀번호, 신용 카드 번호 및 기타 개인 데이터를 포함하여 해당 프로세스가 처리 한 모든 정보가 잠재적으로 손상된 것으로 간주해야합니다.


9

포트의 FreeBSD 10.0 또는 openssl

FreeBSD의 보안 팀은 : CVE-2014-0160 (일명 "Heartbleed와")와 관련하여 자문을 발표했다 FreeBSD의-SA-14 : 06.openssl를

  1. FreeBSD 업데이트

    • 바이너리 패치를 통한 FreeBSD 업데이트

      i386 또는 amd64 플랫폼 에서 RELEASE 버전 의 FreeBSD를 실행하는 시스템 은 freebsd-update (8) 유틸리티를 통해 업데이트 할 수 있습니다.

      # freebsd-update fetch
      # freebsd-update install
      
    • 소스에서 FreeBSD 업데이트

      1. 아래 위치에서 관련 패치를 다운로드하고 PGP 유틸리티를 사용하여 분리 된 PGP 서명을 확인하십시오.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        
      2. 루트로 다음 명령을 실행하십시오.

        # cd /usr/src
        # patch < /path/to/patch
        
      3. 운영 체제 재 컴파일

        FreeBSD 핸드북에 설명 된대로 buildworldinstallworld 사용 .

  2. openssl 포트를 최소 버전 1.0.1_10으로 업데이트하십시오.

  3. 라이브러리를 사용하여 모든 데몬을 재시작하거나 시스템을 재부팅하십시오

  4. 시스템이 손상된 것처럼 행동하고 모든 SSL 키 및 / 또는 인증서와 잠재적으로 유출 된 정보를 다시 발행하십시오 ( EEAA 보다 일반적인 답변 참조 ).

FreeBSD 9.x 및 FreeBSD 8.x

이 시스템은 취약하지 받는 Heartbleed와의 의 이전의 0.9.x 버전에 의존로, 기본적으로 문제가 있는 OpenSSL 라이브러리 를 제외 설치 하려면 openssl을 포트에서 (위층 참조).

이러한 시스템이 Heartbleed 문제에 취약하지 않은 경우 다른 로컬 취약성 으로 인해 시스템을 더 빨리 업그레이드하는 것이 좋습니다 ( FreeBSD-SA-14 : 06.openssl 및 "FreeBSD 10.0"섹션 위층 참조).

로컬 공격자가 서명 프로세스를 스누핑하고 서명 키를 복구 할 수 있습니다. [CVE-2014-0076]

참고 :

최초의 Heartbleed 권고에는 FreeBSD 8.4 및 9.1이 잠재적으로 취약한 것으로 나와 있습니다. 하트 비트 확장 (기본 FreeBSD openssl 라이브러리 버전 0.9.x) 이 없기 때문에 이것은 사실이 아닙니다 .


3

필자는 작업하는 여러 어플라이언스에서 사용중인 SSL 버전을 확인하는 것이 불가능하다는 것을 알았습니다. 기술적으로 완화되지는 않았지만 현재 취약한 호스트를 식별 할 수있는 것이 내 목록의 최상위에있었습니다.

FiloSottile의 테스트 모듈을 사용하여 임의의 호스트 및 포트를 검사하는 작은 VM을 구성했습니다 . 미리 살펴보면 코드가 소리처럼 보입니다.

완성 된 VM의 릴리스는 여기에 있습니다 . VMX 형식입니다.

경고의 말

이 스크립트와 VM은 시스템의 현재 상태 표시합니다. 과거 어느 시점에서 시스템이 취약한 상태에 있었으며 악용되었을 수 있습니다.

여기에 표시되는 것은 수정해야 할 우선 순위가 높지만 업데이트를 적용하고 모든 키를 변경하는 데 도움이 되지않습니다 .


Snapt으로부터 이메일을 받았습니다. 볼로 ( 조심 ) !
Jacob

2

Amazon Linux (Amazon EC2에서 사용되는 Linux 배포판)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

문제 개요 : OpenSSL이 TLS 하트 비트 확장 패킷을 처리하는 방식에서 바운드 검사가 누락되었습니다. 이 결함은 연결된 클라이언트 또는 서버에서 최대 64k의 메모리를 표시하는 데 사용될 수 있습니다.

영향을받는 버전 : openssl 1.0.1이 설치된 Amazon Linux AMI (Amazon Linux AMI 2013.03 이상) 및 2013.03 이상으로 업그레이드 된 Amazon Linux AMI OpenSSL은 기본적으로 Amazon Linux AMI에 설치됩니다.

영향을받는 패키지 : openssl

문제 수정 : yum update openssl을 실행하여 시스템을 업데이트하십시오. 새 패키지가 설치되면 openssl을 사용하는 모든 서비스를 수동으로 다시 시작하거나 인스턴스를 재부팅해야합니다. 새 패키지의 이름은 여전히 ​​openssl-1.0.1e이지만 CVE-2014-0160에 대한 수정 사항이 포함되어 있습니다.

새로운 패키지 : i686 :

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64 :

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.