From: Niall G. <gal...@ya...> - 2010-05-10 20:07:15
|
Hi Fabio, For what you want you DO NOT want HTTP CONNECT. You want to scan the traffic in a HTTPS conversation. This is VERY easy to do. All you have to do is convince your browser your talking to the origin HTTPS server. The implementation is simple, your friends here are your /etc/hosts (and the windows equivenalt, which I can't remember). You will find some REALLY BAD code I have written here, this scans GWT RPC traffic to an uncontrolled foreign server. I am able to scan the traffic from my browser to this server and dump the messages. This is what you want, no? The code is here, but beware it is a real hack job. The class your looking for is an inner class named ProxyContainer. https://simpleweb.svn.sourceforge.net/svnroot/simpleweb/trunk/src/demo/java/org/simpleframework/http/search/SearchServer.java Here all you have to change, is the connection, give it your SSL context and your browser will have a HTTPS conversation with it. The proxy container will decrypt and then your internal client will re-encrypt. You can snoop the conversation in the middle. Niall --- On Mon, 5/10/10, Fábio Matos <fab...@gm...> wrote: From: Fábio Matos <fab...@gm...> Subject: Re: [Simpleweb-Support] SSL Handshake problem To: "Simple support and user issues" <sim...@li...> Date: Monday, May 10, 2010, 12:21 PM Hi, Heres a dumbed down hello world example for replicating the problem. Bruno is right: "Sure, because your browsers sends an HTTP CONNECT where your proxy server seems to expect a ClientHello for starting the SSL handshake (different layer): that's what triggers the exceptions you get." The problem is that simple does support SSL, but does not support HTTP CONNECT... its a shame. Could this be in a future release? Bruno, i'll try to use one of your workarounds. Thanks. 2010/5/10 Bruno Harbulot <Bru...@ma...> Hi Fabio, On 10/05/2010 19:09, Fábio Matos wrote: > Hi Bruno, > > Thanks for your patience. I'l try be more clear about what I want to do. > > I want a HTTPS proxy that acts as a man-in-the-middle for logging purposes. > > > Browser ----- (1) ------ Simple "Proxy" (2) ------- (3) ------- Server > > (1) Traffic *encrypted *with *Proxy Certificate* > (2) Traffic *decrypted *with *Proxy Certificate* and *logged* > (3) Traffic *encrypted *with *Server Certificate* > > So, with the proxy configured in the browser, when the client connects > to a server page using HTTPS, it should be presented NOT the server > certificate BUT the proxy certificate. > When the encrypted data arrives at the proxy, because it was encrypted > with its proxy and not the server one, it can decrypt the data and log it. > After that it encrypts the data with the server certificate and sends it. > The response follows the same logic, but backwards. > The problem I currently have with Simple is that if defined as a proxy > in the users browser, the handshake process does not work, > so it never receives the request encrypted with its certificate to be > logged. Sure, because your browsers sends an HTTP CONNECT where your proxy server seems to expect a ClientHello for starting the SSL handshake (different layer): that's what triggers the exceptions you get. > This is different than a tunnel, like you referred, as in a tunnel the > proxy only makes two SSLSockets (browser-proxy and proxy-server) and > connects them, never seeing whats is the data flowing through, because > its encrypted with the server certificate. Sure, but that's the way HTTP proxy servers handle HTTPS traffic. That's part of the protocol and you can't really get away from that. You have to realise that what you're trying to do isn't an HTTP/HTTPS proxy and thus won't be usable as such from the browser point of view. You could achieve what you're trying to do by connecting to the proxy explicitly, having it relay the connections to the actual server in the back-end. By this I mean connect to https://your.proxy:8888/ instead of https://your.jboss.server:8443/. If you want this to be transparent from the browser's point of view (whether or not using HTTP proxy server settings), you won't be able to do it using some standard configuration, but you're going to have use some tricks at least on one side: - If you have control over your JBoss server, you could make it think it's serving a port on which it's not actually listening. That's more or less the same trick as what's used to run a Java server on a non-privileged port and redirecting to it via iptables on a Linux box (except that you wouldn't necessarily use iptables for the redirection, but your proxy). For example, you can currently run a number of Java containers on port 8443, but have them serve requests as if they were on port 443 (logically). The actual forwarding between ports 443 and 8443 would be done with iptables. What you'd need to do is the same idea, but have your proxy do the redirection instead of iptables. That could actually let you use the actual server certificate if you let your proxy server have access to it. - If you have control over your browser instead, you might be able to use to iptables trickery to make it think it's sending traffic to your JBoss server when it's actually sending it to your proxy. Of course, the proxy would sent its certificate instead of the original server. This option can probably be a bit messy to set up. Best wishes, Bruno. > 2010/5/10 Bruno Harbulot <Bru...@ma... > <mailto:Bru...@ma...>> > > Hi Fabio, > > I'm not sure you see how HTTP proxy servers work. If you've configured > your browser to use 127.0.0.1:8888 <http://127.0.0.1:8888> as a > proxy, it will use CONNECT for > HTTPS connections. CONNECT must relay the entire TCP traffic upon which > is the SSL connection for this to work. An HTTP proxy server that > supports HTTPS doesn't have to support SSL itself. > > If you want your proxy to behave like an HTTP proxy with regards to > HTTPS servers, it's CONNECT you need to implement, this has absolutely > nothing to do with SSL or any SSLContext as far as this proxy server is > concerned. It's just tunnelling the connection (no HTTP involved after > the CONNECT request/response itself). > > If, alternatively, you want it to act like a reverse proxy, which would > relay the requests to your JBoss AS (I'm not sure if that's what you're > trying to do), then you'd need your browser to assume it's the actual > server (and thus not configure your browser to use it as an HTTP proxy). > > It's not clear from what you're saying which of these two scenarios > you're trying to achieve. They're completely different. > > Best wishes, > > Bruno. ------------------------------------------------------------------------------ _______________________________________________ Simpleweb-Support mailing list Sim...@li... https://lists.sourceforge.net/lists/listinfo/simpleweb-support -- Fábio Matos -----Inline Attachment Follows----- ------------------------------------------------------------------------------ -----Inline Attachment Follows----- _______________________________________________ Simpleweb-Support mailing list Sim...@li... https://lists.sourceforge.net/lists/listinfo/simpleweb-support |