Şeffaf bir SSL proxy kurma

80 numaralı bağlantı noktasından geçen trafiği incelemek için 2 ağ kartı ile kurulmuş bir linux kutusu var. Bir kart internete çıkmak için kullanılır, diğeri bir ağ anahtarına bağlanmış. Buradaki nokta, hata ayıklama amacıyla bu anahtara bağlanan aygıtlardaki tüm HTTP ve HTTPS trafiğini denetleyebilmektir.

İptables için aşağıdaki kuralları yazdım:

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'de, kayıt için Charles ( http://www.charlesproxy.com/ ) kullanan şeffaf bir http proxy'im var .

80 numaralı bağlantı noktası için her şey yolunda, ancak 443 numaralı bağlantı noktasını işaret eden 443 numaralı bağlantı noktası (SSL) için benzer kurallar eklediğimde, Charles aracılığıyla geçersiz ileti hakkında bir hata alıyorum.

Charles ile daha önce aynı bilgisayarda SSL proxy kullanıyordum ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ), ancak bir nedenden ötürü şeffaf bir şekilde yapmada başarısız oldum. Googled yaptığım bazı kaynaklar bunun mümkün olmadığını söylüyor - birisi nedenini açıklayabilirse bunu bir cevap olarak kabul etmeye hazırım.

Bir not olarak, alt ağa bağlanan tüm istemciler de dahil olmak üzere açıklanan kuruluma tam erişimim var - böylece Charles tarafından kendinden imzalı sertifikaları kabul edebilirim. Teoride, şeffaf vekillerin yapacağı için çözümün Charles'a özgü olması gerekmez.

Teşekkürler!

Düzenleme: Onunla biraz oynadıktan sonra, belirli bir ev sahibi için çalışmayı başardım. Benim iptables benim aşağıdaki değiştirmek (ve ters proxy için charles 1338 açmak):

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

Yanıt alabilirim, ancak hedef ana bilgisayar olmadan. Ters proxy'de, sadece 1338'den her şeyin vurmak istediğim belirli bir ana bilgisayara gittiğini belirtirsem, el titremesini düzgün bir şekilde gerçekleştirir ve iletişimi incelemek için SSL proxy'sini açabilirim.

Kurulum ideal daha azdır çünkü 1338'den her şeyin bu ana bilgisayara gittiğini varsaymak istemiyorum - hedef ana bilgisayarın neden soyulduğuna dair herhangi bir fikir?

Tekrar teşekkürler

Gördüğünüz sorunlar , tek bir IP adresinde / bağlantı noktasında (Sunucu Adı Göstergesi kullanmadan) birden çok sertifikanın kullanılmasını engelleyen sorunlarla aynıdır .

Düz HTTP'de, şeffaf proxy'niz istemcinin hangi ana bilgisayara bağlanmak istediğini Hostbaşlığa bakarak söyleyebilir .

HTTPS MITM şeffaf proxy isteği aldığında, istemcinin en başta hangi ana bilgisayar adını istediğini bilemez. (Bu durumda IP adresini alabileceğinden bile emin değilim; bu, genel durumda çalışma olasılığı düşük olsa bile, en azından ters DNS araması kullanarak bir tahmin yapmasına izin vermiş olabilir.)

• Beklenen ana bilgisayar adını almak için, MITM proxy'sinin HostHTTP iletisindeki başlığı okuması gerekir ; bu, yalnızca başarılı bir el sıkışmadan sonra gerçekleşebilir.
• Başarılı bir el sıkışma olması için, MITM proxy'sinin beklenen ana bilgisayar adıyla eşleşen bir kimlik doğrulama sertifikası oluşturması gerekir.

Sonuç olarak, MITM proxy el sıkışmadan önce hangi sertifikanın üretileceğini bilemez.

En azından HTTP CONNECTyöntemiyle amaçlanan ana bilgisayar adını alacağınız için, bu saydam olmayan bir MITM proxy'si ile çalışabilir .

Bu konu hakkında bazı temel bilgiler.

Bu işlemi başarılı bir şekilde başlatabildiğini bildiğim birkaç cihaz var. Ancak halk tarafından gerçekten kullanılamazlar. Ben kendim SSL Boşaltma ile Fortinet Fortigate kullanıyorum.

Temel olarak yaptığı şey; ana bilgisayara yapılan SSL Bağlantısını durdurur ve donanımdaki bağlantının şifresini çözer, ardından nereye gitmek istediğinizi denetler ve bu bilgilere dayanarak bir güvenlik duvarı kararı verir.

Daha sonra, verileri almak için ana bilgisayara kendi bağlantısını kurar ve kullanıcı tarafından sağlanan bir CA'yı kullanarak istemciye orijinal isteği yeniden imzalar. Bu işlemin sorunsuz çalışması için CA'nın istemcideki güvenilir kök CA'da olması gerekir.

Bu tür kurulumlar, şirketlerde internet kullanımına ilişkin şirket politikalarını uygulamak için kullanılır. Bir Active Directory kullandığınızda, şirket CA'nızı istemcilere yüklemek kolaydır, bu büyük kuruluşlar için sorun oluşturmaz.

SSL trafiği şifreli olduğu için bu işlemi manuel proxy oluşturmadan yapabileceğiniz tek yoldur. Temel olarak bir MITM'dir, bu nedenle herhangi bir yasal konunun ele alınması önemlidir.

Gördüğünüz diğer soru hakkında birkaç öneri daha var: şeffaf SSL proxy efsaneleri ve gerçekleri . Ve Squid'i şeffaf bir SSL proxy olacak şekilde nasıl yapılandıracağınızı açıklayan bu bağlantı var. Aradığın şey bu değil, ama en azından neyin yanlış gidebileceğine dair bir fikir verebilir.

İptables kuralları iyi görünüyor, ama kullandığınız proxy yazılımı yapmaya çalıştığınız şeyi yapabiliyorsa hiçbir fikrim yok. Belgeler kesinlikle bunun böyle olduğunu iddia ediyor.

Bruno'nun çözümüne eklemek için biraz araştırdım ve ideal olmayandan daha hızlı bir çözüm bulduğumu paylaşmak istedim.

Bu iptables'ı ayarladıktan sonra, 1338 numaralı bağlantı noktasına bir ters proxy yerleştirebilir ve 1337 numaralı bağlantı noktasında localhost'a iletebilirim. 1337 numaralı bağlantı noktası şeffaf bir http proxy olduğundan ve verilerin şifresi çözüldüğünden, ana bilgisayar üstbilgisini alıp hedef yapmasını sağlar konak.

En büyük dezavantajı, aslında her sunucu ile çalışmayan bir https bağlantısı http - dönüştürdüm (bundan açığa çıkardığım güvenlik deliğinden bahsetmiyorum).

Yazılımımın sınırları dahilinde çalışıyordum. Bruno'ya göre daha temiz bir çözümün 1338'deki tüm trafiğin şifresinin çözülmesi gerektiğini varsayacağına inanıyorum. Şifre çözme işleminden sonra, hedef ana bilgisayarı inceleyin ve ardından SSL kullanarak isteği proxy yapın.