hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From steve labar <steve.labarbera....@gmail.com>
Subject Re: SSL and HTTPService
Date Sun, 20 Nov 2011 21:51:54 GMT
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!

On Sat, Nov 19, 2011 at 10:28 PM, Asankha C. Perera <asankha@apache.org>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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message