https 트래픽은 웹 캐시 프록시 서버에 어떤 영향을 줍니까?

컴퓨터 보안과 인터넷 프로그래밍에 관한 두 개의 대학 과정을 수강했습니다. 나는 다른 날에 이것에 대해 생각하고있었습니다.

웹 캐시 프록시 서버는 웹 서버에서 인기있는 컨텐츠를 캐시합니다. 예를 들어 회사에 내부적으로 1Gbps 네트워크 연결 (웹 캐시 프록시 서버 포함)이 있지만 인터넷에 100Mbps 만 연결된 경우에 유용합니다. 웹 캐시 프록시 서버는 캐시 된 컨텐츠를 로컬 네트워크의 다른 컴퓨터에 훨씬 빠르게 제공 할 수 있습니다.

이제 TLS 암호화 연결을 고려하십시오. 암호화 된 콘텐츠를 유용한 방법으로 캐시 할 수 있습니까? letsencrypt.org의 모든 이니셔티브는 기본적으로 SSL을 통해 모든 인터넷 트래픽을 암호화하는 것을 목표로합니다. 이들은 실제로 쉽고 자동화되어 있으며 사이트에 대한 SSL 인증서를 무료로 쉽게 얻을 수있게하여 2015 년 여름부터 시작합니다. SSL 인증서의 현재 연간 비용을 고려할 때 FREE는 정말 매력적입니다.

내 질문은 : HTTPS 트래픽이 결국 웹 캐시 프록시 서버를 쓸모 없게 만들 것입니까? 그렇다면 전세계 인터넷 트래픽에 어떤 영향을 미치나요?

— 이순시
소스

도메인과 하나의 하위 도메인에 대해 무료 인증서를 몇 년 동안 제공 한 신뢰할 수있는 상업용 회사가 있습니다. Let 's Encrypt 프로젝트의 노력, 특히 그들이 얼마나 쉽게 만들고 싶어하는지는 매우 감사하지만 Startcom이 만들어 낸 좋은 업장은 인정되어야합니다.

— Paul

이 질문은 현재 Let 's Encrypt에 대한 언급과 함께 거의 광고처럼 읽습니다.

— fukawi2

@Paul StartCom은 기준 요구 사항을 위반하여 인증서를 업데이트 한 회사 인 WoSign에 매진했습니다.

— Damian Yerrick

@DamianYerrick 나는 투시력이 부족하여 실망 시켜서 죄송합니다. (이 의견은 Mozilla가 발견하기 전에 남겨졌습니다.)

— Paul

의 가능한 중복 되어이 캐시 HTTPS에 대한 방법은 프록시 서버에 요청?

— Dan Dascalescu

답변:

예, HTTP는 네트워크 캐싱에 댐퍼를 추가합니다.

특히 HTTP를 캐싱하려면 중간 유형 공격에서 SSL 인증서를 캐시 서버의 인증서로 대체해야합니다. 해당 인증서는 즉석에서 생성되고 현지 기관에서 서명해야합니다.

회사 환경에서는 모든 PC가 캐시 서버 인증서를 신뢰하도록 할 수 있습니다. 그러나 다른 컴퓨터는 인증서 오류를 발생시킵니다. 악의적 인 캐시는 페이지를 쉽게 수정할 수 있습니다.

비디오 스트리밍과 같이 많은 양의 대역폭을 사용하는 사이트는 여전히 일반 HTTP를 통해 콘텐츠를 보내 캐시 될 수 있다고 생각합니다. 그러나 많은 사이트에서 향상된 보안은 대역폭 증가보다 중요합니다.

— 부여
소스

MITM은 반드시 공격이 아닌 메커니즘입니다. 공격으로 정의해야하는 경우 수많은 회사가 가짜 인증서를 사용하여 직원을 공격하고 Windows 인증서 저장소를 사용하지 않는 도구로 끝없는 두통을 가져옵니다!

— 벤

엄격한 HTTPS 트래픽조차도 엄격한 의미로 프록시 될 수 없습니다 ( '그렇지 않으면 프록시 소프트웨어가 " 중간자 (man in the middle) " 역할을하므로 SSL을 피하기 위해 개발 된 이유 중 하나입니다 ). 일반적인 소프트웨어 프록시 (예 : SQUID) 는 HTTPS 연결을 올바르게 처리 할 수 있습니다 .

이것은 덕분에 가능하다 HTTP CONNECT 방법 것으로, SQUID가 제대로 구현 . 다시 말해, 프록시가 수신하는 HTTPS 요청의 경우 캡슐화 된 암호화되지 않은 트래픽에 대한 개입없이 단순히 "릴레이"합니다.

처음에는 이것이 쓸모없는 것처럼 보이지만 로컬 클라이언트 / 브라우저가 프록시를 가리 키도록 구성하고 동시에 모든 형태의 인터넷 연결을 끊을 수 있습니다.

따라서 원래 질문 : " HTTPS 트래픽으로 인해 결국 웹 캐시 프록시 서버가 더 이상 사용되지 않습니까? "

예 : 캐싱 측면에서만 웹 프록시에 의존하는 경우
NO : 캐싱 이외의 용도로 웹 프록시를 사용하는 경우 (예 : 사용자 인증, URL 로깅 등)

추신 : HTTPS의 유사 / 주요 문제는 웹 호스팅 솔루션에서 일반적이지만 이름 기반 가상 호스트 멀티 호밍과 관련이 있지만 HTTPS 사이트를 처리 할 때 복잡합니다 (세부 사항은 논의하지 않기 때문에 ' 이 질문과 엄격하게 관련이 없습니다.)

— 다미아노 베르 줄리
소스

프록시는 URL도 암호화되므로 HTTPS의 URL 로깅을 수행 할 수 없습니다 (SNI를 사용하는 경우 호스트 이름은 암호화되지 않을 수 있지만 나머지 URL은 항상 암호화 됨)

— Markus Laire

https는 이전에 프록시에서 구현 된 일종의 보안을 무효화합니다. 오징어가 페이지를 가로 채서 로컬 콘텐츠로 대체 할 수 있다고 생각하십시오 (내가 많이 사용하는 기능). 나는 Google 검색에서 링크를 포착하고 프록시가 링크로 바로 리디렉션되도록하여 내가 (또는 프록시를 사용하도록 선택한 로컬 네트워크의 다른 사람)이 Google에 링크 한 링크를 공개하지 않으면 보안이 강화됩니다. https를 사용함으로써 Google은 내 보안의 측면 (물론 중간 공격에 처한 사람)을 물리 쳤습니다. 이제 브라우저 코드를 해킹해야합니다. 더 많은 노력이 필요합니다 ... 가정의 다른 사용자가 사용할 수 없으면 로컬로 해킹 된 브라우저를 실행하는 것이 행복합니다.

— 게르 푸글
소스