2008-08-18 21 views
25

https를 통해 클라이언트가 요청한 (|| any) 프록시 서버 캐시 내용을 캐시 할 수 있습니까? 프록시 서버가 쿼리 문자열 또는 http 헤더를 볼 수 없기 때문에 프록시 서버는 쿼리 문자열을 볼 수 없습니다.프록시 서버가 SSL GET을 캐시 할 수 있습니까? 그렇지 않은 경우 응답 본문 암호화가 충분합니까?

데스크톱 응용 프로그램을 고려 중이며, 회사 프록시 뒤에 많은 사람들이 운영하고 있습니다. 이 응용 프로그램은 인터넷을 통해 서비스에 액세스 할 수 있으며 '읽음'을 위해 기본 제공되는 인터넷 캐싱 인프라를 활용하고 싶습니다. 캐싱 프록시 서버가 SSL 전달 컨텐츠를 캐시 할 수없는 경우 단순히 응답 내용을 암호화하면 실행 가능한 옵션이됩니까?

우리는 캐시 할 수있는 모든 GET 요청을 HTTP를 통해 요청할 때 비대칭 암호화를 사용하여 본문을 암호화하고 각 클라이언트가 해독 키를 가지고 있다고 생각합니다. 캐시 할 수 없거나 POST 작업이 아닌 GET을 수행하고자 할 때마다 SSL을 통해 수행됩니다.

답변

16

아니요, https를 직접 캐시 할 수 없습니다. 클라이언트와 서버 간의 전체 통신은 암호화됩니다. 프록시는 서버와 클라이언트 사이에 위치하여 캐시하기 위해이를 읽을 수 있어야합니다. 즉 암호화를 해독 할 수 있어야합니다.

캐시 할 수 있습니다. 기본적으로 프록시에서 SSL을 수행하여 클라이언트에 전송 된 SSL을 가로 채려고합니다. 기본적으로 데이터는 클라이언트와 프록시간에 암호화되고 해독되고 읽기 및 캐시되며 데이터는 암호화되어 서버에서 전송됩니다. 서버로부터의 응답은 마찬가지로 암호화되고, 판독되고 암호화된다. 나는 당신이 주요 프록시 소프트웨어 (예 : 오징어)에서 이것을 어떻게하는지 모르겠다.하지만 가능하다.

이 접근 방식의 유일한 문제점은 프록시가 자체 서명 된 인증서를 사용하여 클라이언트에 암호화해야한다는 것입니다. 클라이언트는 인증서가 원본 사이트에 있지 않으므로 중간에 프록시가 데이터를 읽었 음을 알 수 있습니다.

+0

2 HTTPS를 만들 수있는 방법이 동일한가 바이트를 요청인가? – Pacerier

22

Rory는 프록시가 엄격하게 사실이 아니라면 자체 서명 된 인증서를 사용해야한다고 말합니다.

프록시는 처리 할 새 SSL 호스트마다 새 인증서를 생성하고 공통 루트 인증서로 서명하도록 프록시를 구현할 수 있습니다. OP 환경의 corportate 환경에서 공통 서명 인증서는 클라이언트 컴퓨터에 신뢰할 수있는 CA로 쉽게 설치 될 수 있으며 호스트 이름 불일치가 없으므로 프록시가 트래픽에 대해 이러한 "위조 된"SSL 인증서를 기꺼이 받아들입니다.

는 사실이 정확히 얼마나 소프트웨어 등 브라우저에서 보안 오류를 발생시키지 않고 SSL 트래픽 검사를 허용하는 Charles Web Debugging Proxy

+1

나는 테스트가 아닌 다른 환경에서 이것을 발견하는 데 꽤 혼란 스러울 것이다. 잘하면 이것이 열리는 웜의 깡통 때문에 대부분의 국가에서 불법입니다. CFO가 웹 포털을 통해 회사 은행 계좌를 확인하는 경우 IT 부서가 상호 작용을 감지 할 수 있다는 사실을 알지 못할 것입니다. –

+0

@Phil 기본적으로 리버스 프록시 공급자가 수행하는 작업입니다. 웹 사이트 (역방향 프록시)에 대한 연결이 안전하다고해서 데이터가 엔드 포인트까지 암호화되어 전송되는 것은 아닙니다. –

+0

@ J.Money 그렇습니다. 그러나 질문은 특히 네트워크 A 내의 브라우저에서 서버 B 로의 프록시를 통한 연결에 관한 것입니다. 그 후에 서버 B가하는 일은 완전히 별개의 문제이며 상호간의 엔드 - 투 - 엔드 암호화입니다 인증은 교환 된 데이터가 책임감있게/법적으로/의도 된대로 사용될 것을 보장하지 않습니다. –

1

난 그냥 SSL을 사용하고 HTTP 클라이언트 라이브러리에 의존해야한다고 생각하는 캐싱을 수행합니다 (예 : Windows의 경우 WinInet). 엔터프라이즈 급 캐싱의 이점은 사용자 지정 보안 암호화 스키마 또는 인증서 재미를 프록시에 작성하는 것만 큼 가치가 있다고 상상하기 어렵습니다. 더 나쁜 것은, 당신이 언급 한 암호화 체계에서 엔티티 몸체에 비대칭 암호를 사용하는 것은 응용 프로그램의 서버 측에서 엄청난 성능을 발휘하는 것처럼 들립니다. SSL이 연결의 실제 페이로드에 대해 대칭 암호를 사용하는 이유가 있습니다.

1

나는 SSL을 사용해야하며 캐싱을 수행하는 HTTP 클라이언트 라이브러리 (예 : Windows의 경우 WinInet)에 의존해야한다고 생각합니다. 엔터프라이즈 급 캐싱의 장점은 사용자 지정 보안 암호화 스키마 또는 인증서 재미를 프록시에 작성하는 것만 큼 가치가 있다고 상상하기 어렵습니다. 더 나쁜 것은, 당신이 언급 한 암호화 스키마에서 엔티티 몸체에 비대칭 암호를 사용하는 것은 응용 프로그램의 서버 측에서 엄청난 성능을 발휘하는 것처럼 들립니다. SSL이 연결의 실제 페이로드에 대해 대칭 암호를 사용하는 이유가 있습니다.

해당 응용 프로그램은 브라우저 응용 프로그램이 아니며 인터넷을 통해 데이터를 가져 오는 데스크톱 응용 프로그램입니다. 앱의 모든 인스턴스가 거의 같은 시간에 동일한 부분을 당길 것입니다. 이 데이터는 보안이 필요하지만 앱의 일부 인스턴스를 회사 프록시 서버에서 캐시 된 버전으로 가져와 perf를 늘리 길 바래요.

데이터 청크는 작지만 자주 요청할 수 있습니다. 기본적으로 모든 앱 인스턴스는 동시에 같은 데이터를 요청합니다.

서버 측의 데이터/메시지 본문은 사전 암호화되어 분산 된 메모리 내 해시 테이블에 캐시됩니다. 암호화는 요청별로 수행되지 않습니다.

대신 NServiceBus와 같은 메시지 버스를 사용하여 조사하고 있습니다.

1

체크 아웃 www.bluecoat.com 실제로 콘텐츠를 제한, 사이트를 차단하기 위해 HTTPS 차단을 할 수있는 바이러스 및 캐시 콘텐츠를 검사 상용 프록시

+0

인증서를 사유하는 것이 아닙니다. 기업 환경에서 워크 스테이션은 회사에 CA를 신뢰할 수있게하고 BlueCoat가 통신을 사임하는 데 사용합니다. 그래서 그것은 : 사이트 - [https] -> 블루 코트 - [https] -> 사용자 –

+0

bluecoat.com 사이트 다운 ... – Pacerier

0

을 (GET을) 어떻게 서버를 설정하는 방법에 대한 https 응답을 암호화하는 구성 요소 뒤에있는 응용 프로그램 서버의 캐시? 역방향 프록시 설정이있는 경우 유용 할 수 있습니다.

나는이 같은 것을 생각하고 : 프록시 서버가 캐시 된 응답을 반환 할 수 있도록

application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)