hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Speirs <bill.spe...@gmail.com>
Subject Re: SSL and HTTPService
Date Mon, 21 Nov 2011 01:56:57 GMT
You might be able to learn on your own by doing a bit more research,
maybe this can get you started.

You need to configure the browser so that HTTP traffic goes to your
proxy server on one port, and HTTPS traffic on another port. Proxying
the HTTP traffic is "easy", you just need to be careful with the
hop-by-hop headers.

Handling SSL traffic is slightly harder. Fidder and other such
programs install a self-signed cert into your browser (or system's)
certificate store. This enables them to properly sign request/response
that your browser will trust. This takes a bit more setup and
configuration, but it is doable.

Hope this points you down the right path...

Bill-

On Sun, Nov 20, 2011 at 4:51 PM, steve labar
<steve.labarbera.one@gmail.com> 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!
>
> 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
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message