투명한 SSL 프록시 설정

포트 80을 통과하는 트래픽을 검사하기 위해 2 개의 네트워크 카드로 구성된 Linux 상자가 있습니다. 한 카드는 인터넷으로 나가는 데 사용되고 다른 카드는 네트워킹 스위치에 연결됩니다. 요점은 디버깅 목적으로 해당 스위치에 연결된 장치의 모든 HTTP 및 HTTPS 트래픽을 검사 할 수 있다는 것입니다.

iptables에 대해 다음 규칙을 작성했습니다.

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

192.168.2.1:1337에서 Charles ( http://www.charlesproxy.com/ )를 사용하여 녹음 하는 투명한 http 프록시가 있습니다.

포트 80에는 문제가 없지만 포트 1337을 가리키는 포트 443 (SSL)에 유사한 규칙을 추가하면 Charles를 통해 잘못된 메시지에 대한 오류가 발생합니다.

Charles ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ) 와 동일한 컴퓨터에서 SSL 프록시를 사용 했지만 어떤 이유로 투명하게 수행하지 못했습니다. 내가 봤던 일부 리소스는 불가능하다고 말합니다. 누군가가 이유를 설명 할 수 있다면 대답으로 기꺼이 받아들입니다.

참고로, 서브넷에 연결된 모든 클라이언트를 포함하여 설명 된 설정에 완전히 액세스 할 수 있으므로 Charles가 자체 서명 한 인증서를 수락 할 수 있습니다. 이론적으로 투명한 프록시가 수행하기 때문에 솔루션은 찰스에만 국한되지 않아도됩니다.

감사!

편집 : 조금 가지고 놀다가 특정 호스트에서 작동하도록 할 수있었습니다. 내 iptables를 다음과 같이 수정하면 (그리고 찰스에서 1338을 열어 리버스 프록시) :

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

응답을받을 수 있지만 대상 호스트가 없습니다. 리버스 프록시에서 1338의 모든 항목이 적중하려는 특정 호스트로 이동하도록 지정하면 핸드 쉐이크가 올바르게 수행되고 SSL 프록시를 켜서 통신을 검사 할 수 있습니다.

1338에서 모든 호스트가 해당 호스트로 이동한다고 가정하지 않기 때문에 설정이 이상적이지 않습니다. 대상 호스트가 제거되는 이유를 알고 있습니까?

다시 감사합니다

표시되는 문제는 서버 이름 표시를 사용하지 않고 단일 IP 주소 / 포트에서 여러 인증서를 사용하지 못하게 하는 것과 같습니다 .

일반 HTTP에서 투명 프록시는 Host헤더 를 조사하여 클라이언트가 연결하려는 호스트를 알 수 있습니다 .

HTTPS MITM 투명 프록시가 요청을 받으면 클라이언트가 먼저 요청한 호스트 이름을 알 수 없습니다. (이 규칙을 사용하여 IP 주소를 얻을 수 있는지조차 확실하지 않습니다. 일반적인 경우에는 작동하지 않을지라도 역방향 DNS 조회를 사용하여 추측 할 수 있습니다.)

• 예상되는 호스트 이름을 얻으려면 MITM 프록시가 HostHTTP 메시지 의 헤더 를 읽어야합니다 . 이는 성공적인 핸드 셰이크 후에 만 ​​발생할 수 있습니다.
• 핸드 셰이크를 성공적으로 수행하려면 MITM 프록시가 예상 호스트 이름과 일치하는 스푸핑 인증서를 생성해야합니다.

결과적으로 MITM 프록시는 핸드 셰이크 전에 어떤 인증서를 생성할지 알 수 없습니다.

최소한 HTTP CONNECT메소드 를 통해 의도 한 호스트 이름을 가져 오기 때문에 불투명하지 않은 MITM 프록시에서 작동 할 수 있습니다 .

이 주제에 대한 몇 가지 기본 정보.

내가 아는 몇 가지 장치 만 있으면이 작업을 성공적으로 수행 할 수 있습니다. 그러나 일반 대중에게 실제로 제공되지는 않습니다. SSL Offloading과 함께 Fortinet Fortigate를 사용하고 있습니다.

기본적으로하는 일은; 호스트에 대한 SSL 연결을 가로 채 하드웨어에서 연결을 해독 한 다음 이동하려는 위치를 검사하고 해당 정보를 기반으로 방화벽을 결정합니다.

그런 다음 해당 호스트에 대한 자체 연결을 설정하여 데이터를 검색하고 사용자가 제공 한 CA를 사용하여 원래 요청을 클라이언트에 다시 서명합니다. 이 작업을 원활하게 수행하려면 클라이언트의 신뢰할 수있는 루트 CA에 CA가 있어야합니다.

이러한 종류의 설정은 조직에서 인터넷 사용에 관한 회사 정책을 시행하는 데 사용됩니다. Active Directory를 사용하기 때문에 회사 CA를 클라이언트에 쉽게 설치할 수 있으므로 대규모 조직에는 문제가되지 않습니다.

SSL 트래픽은 암호화되어 있으므로 수동 프록시를 만들지 않고 할 수있는 유일한 방법입니다. 기본적으로 MITM이므로 모든 법적 문제를 다루는 것이 중요합니다.

이 다른 질문에 대해서는 투명 SSL 프록시 신화와 사실 에 대한 몇 가지 제안이 더 있습니다 . 그리고이 링크는 Squid가 투명한 SSL 프록시가되도록 정확하게 구성하는 방법을 설명합니다. 그것은 당신이 찾고있는 것이 아니지만 적어도 무엇이 잘못 될 수 있는지에 대한 통찰력을 줄 수 있습니다.

iptables 규칙은 괜찮아 보이지만 사용중인 프록시 소프트웨어가 수행하려는 작업을 수행 할 수 있는지 잘 모르겠습니다. 문서는 확실히 이것이 사실이라고 주장합니다.

Bruno의 솔루션에 추가하기 위해, 나는 약간의 조사를 해보았지만, 또 다른 비정형적인 빠른 수정 방법을 공유하고 싶었습니다.

해당 iptables를 설정 한 후 포트 1338에 리버스 프록시를 넣고 포트 1337의 localhost로 전달할 수 있습니다. 포트 1337은 투명한 http 프록시이고 데이터가 해독되었으므로 호스트 헤더를 가져 와서 목적지로 만듭니다. 주최자.

주요 단점은 본질적으로 https 연결을 http로 변환했다는 것입니다. 모든 서버에서 항상 작동하지는 않습니다 (내가 노출시키는 보안 허점은 말할 것도 없습니다).

소프트웨어 한계 내에서 일하고있었습니다. Bruno에 따르면 더 깨끗한 솔루션은 1338의 모든 트래픽을 해독해야한다고 가정합니다. 암호 해독 후 대상 호스트를 검사 한 다음 SSL을 사용하여 요청을 프록시하십시오.