On Sun, Nov 20, 2011 at 01:51:54PM -0800, steve labar wrote: > So that is why the proxy becomes the endpoint for the browser. The SSL > handshake is done between the two of them. I know it can be done because > there are a number of proxy tools like fiddler,web scarab,paros proxy,burp, > etc that do just this. I wanted to try to create my own for learning and > practical purposes. Although I do admit it's a little bit over my head thus > far. > > I know the key is to establish an SSL handshake with the browser on a > specified port. Therefore to it you are considered the endpoint. Once you > receive the http request you can inspect it and look at it and then > establish the connection to the origin server on behalf of browser get the > data than pass it back to the browser just on the trusted channel. > > My problem is that initially when I establish the connection it is a > standard socket. So, when you receive connect request after everything is > negotiated the browser at some point is going to be passing you encrypted > data. now because the initial socket listening on 8080 is a normal socket > I'm assuming it will fail. However, when I tried to switch the socket SSL > on port 8080 other non-SSL traffic was also throwing exception. So I > absolutely know I'm doing something wrong just not sure exactly what it is. > I'm thinking it might be time to possibly higher someone to do that work. > I'm assuming it would only be an hour to work. Not entirely sure but I > figure this is the only way I'm going to learn is by having someone else do > it and look at their work. I'm open for suggestions! >
One cannot intercept SSL traffic and make it completely transparent to the client being eavesdropped upon. HTTP proxies can intercept encrypted data _ONLY_ if clients are OK with being monitored and explicitly trust the proxy. Effectively the proxy needs to intercept SSL/TLS protocol handshake and send its own certificate to the client (most likely generated on-the-fly) instead of that of the origin server. The proxy would have to receive encrypted data from the client, decrypt it, look at the message content, encrypt it and send it to the origin server and the reverse process would have to done with data transmitted in the opposite direction. One would effectively need to re-implement the entire SSL/TLS protocol handling engine. In my option, that would be an enormously difficult task, especially with Java NIO. Oleg > On Sat, Nov 19, 2011 at 10:28 PM, Asankha C. Perera <[email protected]>wrote: > > > Hi Steve > > > > 1. one thing that I might have failed to mention is this proxy needs to be > >> able to intercept and look at the request before it is being sent to the > >> origin server. The whole idea behind this proxy is to be a security tool > >> to > >> be able to look and manipulate the request that has been sent by the > >> browser before it gets sent to the origin server. Now having said that in > >> this case wouldn't the proxy server need to establish an SSL handshake > >> with > >> the browser so that the browser will trust and send that encrypted request > >> and your proxy will be able to decrypt the encrypted request? > >> > > The way SSL operates is that end to end the path would be secured from the > > client making the request to the actual endpoint its talking to. Hence, > > there is no possibility for the proxy to look at the actual request or > > manipulate it - as it violates the whole purpose of SSL. > > > > I am not sure of your exact requirement - but for example if your clients > > are within an intranet wanting to talk to an external endpoint, maybe a > > compromise is that they "explicitly" talk to a well known proxy server over > > SSL (for security), which can then look at or manipulate the > > requests/responses and forward them to the external proxy again over > > *another* SSL connection. Is this acceptable? > > > > cheers > > asankha > > > > -- > > Asankha C. Perera > > AdroitLogic, http://adroitlogic.org > > > > http://esbmagic.blogspot.com > > > > > > > > > > > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
