내 직장에서는 최근 POODLE 취약점을 해결하기 위해 서버 중 하나에 패치를 적용했습니다. 그 이후로 이전 Oracle Linux 5 클라이언트(RHEL 5 기반)는 더 이상 애플리케이션을 사용하여 서버에 안전하게 연결할 수 없습니다. 클라이언트 컴퓨터는 OpenSSL 버전 0.9.8e를 사용합니다. 이러한 컴퓨터에 사용 가능한 최신 버전의 OpenSSL(0.9.8e-31)을 설치하면 아무런 영향이 없지만 클라이언트는 TLSv1만 사용해야 합니다.하다문제를 풀다.
예를 들어, s_client결과는 다음과 같습니다.
$ openssl s_client -connect foo.bar.com:443
CONNECTED(00000003)
5529:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
그러나 이것은 잘 작동합니다.
$ openssl s_client -connect foo.bar.com:443 -tls1
이번에도 wget https://foo.bar.com/testFile실패했지만 wget --secure-protocol=TLSv1 https://foo.bar.com/testFile효과적이었습니다.
내 주요 질문은 이러한 클라이언트 컴퓨터에서 다시 연결할 수 있도록 전역적으로 OpenSSL을 구성하는 방법입니다.아니요우리가 사용하고 있거나 앞으로 사용할 수 있는 모든 애플리케이션은 수동으로 재구성되어야 합니다. 이러한 시스템을 최신 버전의 Linux로 업그레이드하는 것은 선택 사항이 아닙니다. 이 동작의 원인을 정확히 설명할 수 있다면 보너스 포인트가 됩니다.
감사해요!
答え1
첫째, 왜? 내부에다음에 대한 문서s_clientopenssl은 올바른 프로토콜을 파악하기 위해 기본적으로 핸드쉐이킹을 사용한다고 합니다. 이것이 POODLE 공격의 전체 기반입니다. 문제는 0.9.8에서 핸드셰이크가 SSL_V23으로 시작하고 나중에 TLSv1을 시도한다는 것입니다. 클라이언트가 SSL_V23을 사용하여 연결할 때 많은 서버는 클라이언트가 안전하지 않은 작업을 수행하고 있다는 위험 신호이므로 문제가 발생하는 것을 좋아하지 않습니다.
어떻게 고치나요? 글쎄요, openssl.cnf에서 "기본적으로 TLSv1을 사용하세요"라고 말할 수 있는 옵션을 찾을 수 없습니다. 존재하다이 스레드, 그들은 이것이 v1.0.0+에서 가능하다는 것을 암시하는 것 같습니다. 한 시간 동안의 인터넷 검색 끝에 최선의 선택은 다음과 같습니다.openssl을 다시 컴파일하고 SSLv2 및 SSLv3을 비활성화합니다.. openssl을 다시 컴파일하는 경우 0.9.8을 사용하는 것이 더 쉬울 수 있습니다. RHEL과 같은 시스템에서 openssl을 1.x+로 업그레이드하는 것은 완전히 악몽이 될 수 있습니다.
答え2
RHEL 5에도 동일한 문제가 있으므로 방금 버그질라를 확인했습니다.https://bugzilla.redhat.com/show_bug.cgi?id=1152789
그들은 Tomcat 6과 JBoss에 중점을 두고 있으며 애플리케이션 서버 구성에서 몇 줄을 변경하는 것으로 귀결됩니다.
하지만 이 버그질라에는 RHEL5의 openssl에 문제를 일으키는 스레드가 있습니다.
https://rhn.redhat.com/errata/RHSA-2014-1653.html
openssl-0.9.8e-31.el5_11은 필요한 업스트림 재컴파일된 openssl입니다.
그래서: IMHO, 패치를 설치하고 웹/응용 프로그램 서버가 안전하지 않은 프로토콜을 사용하지 않도록 강제하면 됩니다.