포럼

아파치 SSL 문의

2011.03.03 10:17

학교 개강해서 열심히 학교 다니고 있습니다. 한가지 제가 해결 못하는 문제가 하나 생겨서 여기 의견을 여쭈어 봅니다.

학교 네트워크에서 https://socialxe.net 보안연결이 되지 않아서요. 아파치 로그에는

Re-negotiation handshake failed: Not accepted by client!?

이렇게 표시되고 있습니다. 한국어 검색 결과에는 만족할 만한 답을 얻지 못했고, 영어 검색 결과에서 re-negotiation은 보안 문제 때문에 금지되어 있다라는 건 간신히 찾았습니다.

이게 저희 학교 네트워크의 문제인지? 아니면 제가 고쳐야 할 문제인지 판단이 안 됩니다. 고쳐야 한다면 어떻게 고쳐야 하는지도 잘 모르겠고요.

참고로 학교 네트워크에서 https://www.google.com 은 정상적으로 접속이 이루어 집니다.

이 게시물을

misol

2011.03.03 13:48

http://www.bluequartz.us/phpBB2/viewtopic.php?p=418101&sid=29ea8bf376439acbf2ea2d52d752fa57
에 있는 답변을 그냥.. 발번역 해봤는데 도움이 되려나요 ㅠㅠ;; 전 무슨 얘긴지 하나도 모르겠어요..

재검토는 0.9.8l에서 접두사-넣기(prefix-injection) 공격 결함 때문에 이용할 수 없다.
접두사-넣기 공격은 IETF/TLS 그룹이 단지 수정 초안을 승인한 상태다.
Renegotiation is disabled in 0.9.8l due to the prefix-injection attack
flaw that the IETF/TLS group just approved a draft standard to fix.

나는 0.9.8m이 새로운 재검토 의미들을 활성화 할것이라고 기대한다.
그때까지는, 0.9.8k로 돌아가라. -- 단지 인지하고 있어라.
재검토는, TLS가 그렇지 않는다면 보증했을, 보증하는 범위 안에서 일어나지 않는다.
(즉, 마지막점(endpoint)은 새 말단(endpoint)와 이전(old) 말단 사이에 충돌 없이 마음대로 변할 수 없다.)
I expect 0.9.8m to have the new renegotiation semantics enabled.
Until then, you can go back to 0.9.8k -- just be aware that
renegotiation cannot be performed within the guarantees that TLS
otherwise makes (namely, that the endpoint cannot be arbitrarily
changed without collusion between the old and new endpoints).

그 공격은 단순하다:
The attack is simple:

1) 보안 웹 서버 하나를 설정한다. 그 보안서버는 접근 되길 당신이 원하지 않는
(빈) 파일 하나를 어딘가에 갖고 있다. 이건 '서버'다. (이 시연은 접속을 위한 클라이언트
인증을 요구하는 디렉토리에 이 파일이 있을때 더 낫다.)
2) TLS 클라이언트 말단(endpoint) 그리고 한 서버 말단을 설치한다.
같은 과정으로, 어딘가에 같은 과정을 한다. 우리는 서버를 '프록시'라 부를 것이다.
3) DNS를 설정한다. DNS서버 이름은 이것이 (아파치의 HostName 명령) 실제로 프록시로 가도록
한다고 생각한다.
4) 공격 :
a) 클라이언트는 HostName에 접속하고, 이 클라이언트 접속은 프록시에 신호하는 것으로 끝난다.
  이것은 ClientHello를 보낸다. 하지만, 즉시 응답을 받을 필요는 없다.
b) 프록시는 TLS 넘어 서버로 연결을 만든다.
c) 프록시는 GET /file/you/don't/want/shown HTTP/1.1
  \n Host: server \n\n 비슷한 무언가를 보낸다. (당신이 보이길 원하지 않는 파일)
d) 프록시는 그때 ClientHello를 클라이언트로부터 서버로 보낸다, 그리고 투명하게
  이 앞쪽의 연결을 프록시(대리한다)한다.
e) 서버는 ClientHello를 전달받고, 재검토할 요청으로 이것을 번역한다. (spec 마다)
f) (재)검토가 끝나고, 서버는 전달 받은 모든 데이터가 같은 보안 장막(베일)안에서
  처리 될 수 있다고 생각한다. 이것을(refix를 포함해서) 처리하고, 공격은 성공했다.

1) Set up a secure webserver, with an (innocent) file that you don't
want accessed, somewhere. This is 'server'+ '. (This demo works better
if it's in a directory that requires a client certificate for access.)
2) Set up a TLS client endpoint and a server endpoint in the same
process, preferably somewhere else. We'll call this the 'proxy'.
3) Arrange DNS such that the name that server thinks it has (the
HostName directive in Apache) actually goes to proxy.
4) Attack:
a) Client connects to HostName, ends up talking to proxy. It sends
ClientHello, but it doesn't necessarily receive an answer immediately.
b) proxy makes connection to server over TLS.
c) proxy sends something like GET /file/you/don't/want/shown HTTP/1.1
\n Host: server \n\n
d) proxy then sends ClientHello from client and passes it to server,
and transparently proxies the connection from here forward.
e) server receives ClientHello and interprets it (per spec) as a
request to renegotiate.
f) (re)negotiation finishes, server thinks all data received can be
treated as being under the same security veil, processes it (including
prefix), and the attack is successful.

재검토 이전 상태에 대한 암호화 인증이 없기 때문에(클라이언트는 이것이 첫
검토라고 생각하고, 서버는 이것이 재검토라고 생각한다. 그러나 TLS가 신호할
방법이 없다.), 클라이언트와 서버는 새로운 master_secrets를 생성한다. 그러면,
서버는 전체 요청을 처리한다. 이 요청에는 공격자가 심은 '접두어(prefix)'가
포함되어 있다.
Since there'+ 's no cryptographic verification of the prior state in the
renegotiation (client thinks it's initial negotiation, server thinks
it's a renegotiation, but there's no way within TLS to signal that),
client and server then create new master_secrets. Then, server
processes the entire request, including the prefix that the attacker
injected.

이것은 HTTP가 보안 설정이 다른 경로들이 포함된 경로를 어떻게 다루는지에
대한 결함으로부터 물려받은 것이라고 제안되었다. 그리고 나는 동의하고 싶다.
-- "재검토 전 자료"와 "재검토 후 자료"의 차이를 이해하는 하나의
클라이언트/서버 조합은, 비록 재검토가
"인전하지 않"더라도, 이것을 그냥 흘려보내지 않을것이다. 왜냐하면 그런 조합은
그 자료를, 최신 재검토의 종결 메시지가(클라이언트-서버 조합이 서로 믿는다고
가정하자) 발견되기 전에 그 자료를 다룰 것이기 때문이다. 일반적으로 (한 최고의
수행으로) 잠재적인 공격자로 부터의 의심스러운 자료를 다루는 최고의 방법은
버리는 것이다.
It has been suggested that this is an inherent flaw with how HTTP
handles paths with different security characteristics, and I am
inclined to agree -- a client/server pair that understands the
difference between "pre-renegotiation data" and "post-renegotiation
data" won't trip on this, even if renegotiation is "insecure". That's
because such a pair would treat the data prior to the latest
renegotiation's Finished messages as suspect (assuming that the
client-server pair did mutual authentication), and generally (as a
best practice) with suspect data from a potential attacker it's best
to drop it.

이것은 또한, 부정할 수 없이 TLS 명세의(그런 라이브러리들을 실행하는,
클라이언트들이 증폭시키는) 결점일지라도 -- 왜냐하면 그 클라이언트들은
"보안 장막" 개념을 이해하지 못한다. 그 TLS 실행은, 응용프로그램이
변화를 알고 있어야 하지 않으면, a raw stream of bytes를
(쓰기함수/읽기함수 조합과 유사하다) 제공하려는 경향이 있다.
It is also, though, undeniably a flaw in the TLS specification that's
amplified by the clients of the libraries that implement it -- because
the clients don'+ 't understand the concept of "security veil", the TLS
implementations tend to provide a raw stream of bytes (akin to a
read()/write() pair) without the application necessarily being aware
of the change.

-Kyle H

좋아요 댓글 신고
난다날아

2011.03.07 14:24

스펙(프로토콜?) 자체의 보안 결함이라는데. 새버전으로 컴파일해서 설치하면 될련지 모르겠네요. ㅠㅠ openssl은 yum으로 설치되어 있어서 곤란한데 ㅠㅠ

좋아요 댓글 신고

글쓴이	제목	최종 글
hika1	jquery 질문 하나만요.. [7]	2011.03.16 _by hika1
이영한389	모바일 페이지에서 글을 쓰면 문구를 추가하고 싶습니다.
필카페	로그인 관련 문제에 대해 토론해 주세요. [3]	2011.03.15 _by 씨지
웹 엔진	이 게시물을... 부분의 관리자 전용 메뉴를 버튼으로 바꾸는데.. [1]	2011.03.15 _by CEditor
Loptz	게시판의 전체 게시물수 변수명은..? [1]	2011.03.15 _by CEditor
씨지	신 템플릿 문법에서 반복문과 조건문을 한번에 쓸수있도록 하면 어떨까요? [8]	2011.03.12 _by burster
999	속도 문제에 대해 토론해 봅시다. [6]	2011.03.11 _by cjsound
銀童	XE 의 가장큰 병목현상은 파일 I/O 관련 부분이 아닐까요? [2]	2011.03.11 _by 銀童
씨지	Core의 기본언어팩에 '로그인','로그아웃'같은 기본단어가 없네요. [1]	2011.03.10 _by yoorim
Hide_D	신 템플릿 문법에선 if else가 안되는데 그 대신 [1]	2011.03.10 _by SMaker
행복한고니	요즘 하고 있는 거 [9]	2011.03.10 _by k02092000
웹 엔진	이 게시글을... 부분의 신고에 procDocumentDeclare [2]	2011.03.10 _by B.G.M^^
ForHanbi	레이아웃 스킨 압축 파일형태에 대한 질문 [1]	2011.03.08 _by 행복한고니
ForHanbi	게시물 제목 h1 비논리적 구조 아닌가요? [12]	2011.03.08 _by ForHanbi
Loptz	XE 신 템플릿문법에서 .. [1]	2011.03.07 _by XE Developers
난다날아	아파치 SSL 문의 [2]	2011.03.07 _by 난다날아
똥똥	XE서버 해킹 시도로 인한 일부 서비스 사용불가 안내 [27]	2011.03.06 _by TT PIC
wiley	[XE Project Hosting] 프로젝트 가입처리가 정상적이지 않는 듯 합니다. [2]	2011.03.02 _by wiley
BlogJh	로그인 폼에..
어쿠스틱	게시판 확장변수 한줄 입력칸 폭에 옵션을 주실 수 없나요? [1]	2011.02.28 _by RainDrop+

태그 쓰기

포럼

아파치 SSL 문의

댓글 2

misol

난다날아

About

Get involved

Blog

Download

Support

Showcase