I'm resending this because I've been having mailer problems.
Sorry if you get it twice.
Carlos Vicente <[EMAIL PROTECTED]> writes:
> Browsing through the archives I found this post of yours. I am now
> working exactly on the same kind of SSL proxy you described, and I'm
> stuck exactly on the same problem. It's clear that browsers initiate
> the SSL session --sending the ClientHello message-- as soon as they are
> pointed to a https:// adress, so this kind of approach won't work. I
> believe this cannot be bypassed in the browsers, so I was thinking there
> might be some workaround using the "CONNECT" http method and somehow
> tricking the browser to think it is establishing the SSL session with
> the remote server. Anyway, it doesn't seem easy.
There are two main approaches:
1. Use the CONNECT method, as you suggest. You tell the browser that
it is to do it's SSL through a proxy. Netscape calls this a "security
proxy". Basically, it will do a CONNECT as described in RFC 2817. At
this point it expects to make an SSL connection to the remote machine.
You man-in-the-middle attack the connection and then form whatever
kind of connection you like to the remote machine. In order for this to
work properly, you'll need a certificate with "*" in the CN. Obviously,
no CA will issue you such a cert so you'll need to make your own CA
that does this and then add it to the CA list. C2 Net's SafePassage
SSL proxy used to do this.
2. The second approach is to rewrite the HTML as well. If you're
already intercepting the HTTP traffic, you can decode the HTML
and replace all http:// links with http://. You'll actually need
to do something a little more exotic because the proxy needs to
be able to tell. The best approach is to use some distinguished
address and then pickle the actual domain name. E.g. map
https://www.example.com/ ->
http://my-proxy-address/special-prefix-b64-encode(https://www.example.com/)
Then, whenever your proxy sees a "special-prefix" URL it decodes it
and performs the HTTPS fetch.
This is very tricky to get right because you must never miss an https
anchor which means your parser has to be good. Also, the client will
give the user warnings about how you're trying to submit a form over
an insecure link. I don't recommend this technique unless you're
really desperate.
There's no way to tell the browser to treat an https:// URL as
if it were http://. That doesn't make any sense. It's a whole
different protocol. It's like telling it to treat an ftp://
URL as if it were http://
-Ekr
[Eric Rescorla [EMAIL PROTECTED]]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
