Hello,

I have to use a http proxy whose operators I do not trust (the company
I work for . When I connect via HTTPS through this proxy, can I by
100% sure that the proxy operators cannot intercept my HTTPS sessions
(i.e. read passwords etc transmitted)?

I use a client certificate (2048 bit RSA) to connect to my (own)
server, using an AES-256 SSL/TLS session.

TIA,

Peter

[ Post a follow-up to this message ]

In article <1106692860.437165.149150@f14g2000cwb.googlegroups.com>,
<plmuon@gmail.com> wrote:
>
>I have to use a http proxy whose operators I do not trust (the company
>I work for . When I connect via HTTPS through this proxy, can I by
>100% sure that the proxy operators cannot intercept my HTTPS sessions
>(i.e. read passwords etc transmitted)?
>
>I use a client certificate (2048 bit RSA) to connect to my (own)
>server, using an AES-256 SSL/TLS session.

Do you have total control over the machine the browser runs on?
If not, I would say this presents more of a security problem than
the proxy server.

Rob

[ Post a follow-up to this message ]

No, the local machine is another problem. At least I use a firefox
master password and do not keep the certificate file on disk (except
stored in firefox). I have to trust that my keystrokes aren't being
sniffed, I shut down any service I don't know. I'll install vmware
later to work in a trusted (linux) environment, so yes I think I can
trust the local (virtual) machine by then.

Remains the question if HTTPS is encrypted end-to-end so that the proxy
operators cannot intercept anything.

Thanks,

Peter

[ Post a follow-up to this message ]

In article <1106692860.437165.149150@f14g2000cwb.googlegroups.com>, plmuon@gmail.com writes:

>
> I have to use a http proxy whose operators I do not trust (the company
> I work for . When I connect via HTTPS through this proxy, can I by
> 100% sure that the proxy operators cannot intercept my HTTPS sessions
> (i.e. read passwords etc transmitted)?

I haven't investigated this in any depth myself (SSL is complicated
enough on its own; HTTPS adds more complications; proxies are yet
more trouble), but Rescorla has a section (9.16) on it in _SSL and
TLS_.[1]

If I'm reading Rescorla's discussion correctly, the proxy could only
mount a man-in-the-middle attack with client cooperation.  It has to
present a wildcard certificate, and since (as Rescorla points out) no
commercial CA is going to sign a wildcard cert, that would have to be
signed by a private CA, which the client won't accept unless it has
the root cert installed.  So unless the proxy operators can trick you
into installing their CA cert, you should be safe from a proxy MITM.

(This assumes there aren't other possible MITM attacks due to
implementation errors in your client.)

Basically, your guarantee that the proxy isn't reading your traffic
comes from your client's validation of the server certificate.  If it
gets a certificate that actually corresponds to the content server,
then the encrypted channel runs through the proxy and the proxy can
only forward encrypted traffic.

So by practicing good CA-cert hygiene you can effectively prune this
particular attack branch.

--
Michael Wojcik                  michael.wojcik@microfocus.com

Then a good friend got very ill, and it made Pernsteiner realize that
"life is short. This was an opportunity to be silly."

[ Post a follow-up to this message ]