niedziela, września 14, 2008

CONNECT i tunele

Próbowałem wczoraj zbudować tunel... nie taki zwykły, a elektryczny ;-) a dokładniej chciałem dodać do stworzonego przeze mnie jakiś czas temu serwera proxy możliwości tunelowania połączeń HTTPS.
Bazuję na dokumencie Tunneling TCP based protocols through Web proxy servers, a chcę doprowadzić do tego, żeby mój serwer proxy mógł obsługiwać aplikacje takie jak Google Chrome, Safari czy Spik Wirtualnej Polski, które miewają problemy we współpracy z serwerami proxy NTLM. Dzięki temu aplikacje będą rozmawiały z najnormalniejszym HTTP proxy, które będzie przekazywało ich żądania do proxy NTLM....
Są programy, które to robią, ale są duże i jakieś takie nieporęczne. No i nie są moje ;-)

Problem jest jednak taki, że jakoś obsługa CONNECTa mi nie wychodzi. Niby wszystko robię tak jak trzeba, czyli gdy przychodzi żądanie z metodą CONNECT to próbuję połączyć się ze wskazanym przez to żądanie hostem, melduje klientowi [czyli przeglądarce], że wszystko jest OK.... ale nie jest ;-) próba czytania z gniazda serwera, z którym się łączę i z gniazda klienta po odczytaniu żądania kończą się wyjątkami..........
Na razie działam tak, że w momencie CONNECT przesyłam je do serwera docelowego i w tym może tkwić problem....... Ale jeszcze go nie potrafię obejść ;-) Niestety sniffer nie podsłuchuje dobrze ruchu na interfejsie lokalnym...

Do tego dochodzi to, że niestety choć Java wspiera używanie różnych proxy, to jednak właściwości http.proxyHost, http.proxyPort i ich wersje dla HTTPS nie wpływają na połączenia oparte o sockety. Na nie wpływa tylko właściwość socketProxyHost i socketProxyPort. Oznacza to, że będę musiał zrezygnować z używania socketów na rzecz używania HttpURLConnection.

Wyżaliłem się :-)


Podobne postybeta
Proxy :-)
Przymiarki do Nowego Gadacza
A może by tak wsparcie dla Zoho w OpenOffice.org2GoogleDocs?
NTLM działa z OpenOffice.org2GoogleDocs :-)
Złe proxy... złe... czyli jak nie należy przekombinowywać ;-)