Terminating SSL on the web proxy
Florian Weimer
terminate SSL connections on the web proxy, so that the proxy receives
requests in the clear (and handles the certificate verification)?
Nelson Bolyard
I think, but am not certain, that you're describing something like this:
Intranet public Internet
[browser]----------[proxy]---------------------[server]
plain SSL
and you're asking if the browser can be configured so that when it
attempts to fetch an https URL, it does not use SSL itself, but sends
the request unencrypted as an http request to a proxy on the client's
side of the Internet, and SSL is used between the proxy and the server,
but not between the browser and the proxy.
If that's what you're asking, the answer is: no. The browser cannot be
configured to fetch an https URL without using SSL itself.
You might be asking about either of these alternatives, both of which
assume that the browser is attempting to fetch an https URL:
1. The Man-In-The-Middle proxy
Intranet public Internet
[browser]----------[proxy]---------------------[server]
SSL SSL
In this picture, the browser is using SSL to talk to the proxy, and
the proxy is using SSL to talk to the server. The SSL is not
"end to end". The proxy decrypts everything coming in one side and
encrypts it before sending it outside the other. This is called a
"Man In The Middle" (as I'm sure you know). It is possible to
configure a browser to work with such a proxy, by configuring the
browser to accept certificates from a pseudo-CA that operates in the
proxy. In the absence of such configuration, the browser should be able
to detect all attempts to do this, as being attacks on the secure
communications. (I'm sure you know this.)
2. The Server Side Proxy (a.k.a., Reverse Proxy)
Public Internet Intranet
[browser]---------------------[proxy]----------[server]
SSL plain
Here the proxy acts as the server, as seen by the Internet. The browser
connects to the proxy via https with SSL, and the proxy sends the
request on to the true "back end" server as an ordinary http request, in
plain text, unencrypted. This sort of thing happens all the time, and
requires no special browser configuration. The browser simply thinks
that the proxy is the server in the https URL, and contacts it normally
with SSL.
If you're asking about something else, please explain.
Bruce Keats
2. The Server Side Proxy (a.k.a., Reverse Proxy)
Public Internet Intranet
[browser]---------------------[proxy]----------[server]
SSL plain
In this case, does the proxy have to convert the URIs from browser as well
as terminate the SSL connection? Specifically, does the proxy have to
convert the URI from the browser by changing https:// to http:// to the
server? Does the proxy have to convert the URI from the server by changing
http:// to https:// when going in the reverse direction?
Thanks,
Bruce
On Dec 7, 2007 6:35 PM, Nelson Bolyard <NOnels...@nobolyardspam.com>
wrote:
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Nelson Bolyard
> I was curious about the last scenario.
>
> 2. The Server Side Proxy (a.k.a., Reverse Proxy)
>
> Public Internet Intranet
> [browser]---------------------[proxy]----------[server]
> SSL plain
>
> In this case, does the proxy have to convert the URIs from browser as well
> as terminate the SSL connection?
Terminate the SSL connection? Yes.
Convert the URIs? No.
> Specifically, does the proxy have to convert the URI from the browser
> by changing https:// to http:// to the server?
No. An https request is simply an http request sent over SSL.
The "scheme" part of the URI (https:// or http://) is not sent.
But the proxy does need to send the requests to the http port of the
back end server.
> Does the proxy have to convert the URI from the server by changing
> http:// to https:// when going in the reverse direction?
Generally, no, for two reasons. First: relative links don't require any
scheme, so there's no conversion to be done. Second, the creator
of the web pages in the back end creates them so that any non-relative
links to this server use the https scheme. In other words, the web
pages are designed with the fact in mind that the server will be
accessible only through a reverse SSL-terminating proxy.
/Nelson
Umesh Bywar
You may want to look at Paros. Its an open source proxy where you can
see the HTTPS traffic in plain text.
Best Regards.
Umesh.
----- Original Message -----
From: "Bruce Keats" <bruce...@gmail.com>
To: <dev-tec...@lists.mozilla.org>
Sent: Monday, December 10, 2007 9:28 PM
Subject: Re: Terminating SSL on the web proxy
>I was curious about the last scenario.
>
> 2. The Server Side Proxy (a.k.a., Reverse Proxy)
>
> Public Internet Intranet
> [browser]---------------------[proxy]----------[server]
> SSL plain
>
> In this case, does the proxy have to convert the URIs from browser as well
> as terminate the SSL connection? Specifically, does the proxy have to
> convert the URI from the browser by changing https:// to http:// to the
> server? Does the proxy have to convert the URI from the server by
> changing
> http:// to https:// when going in the reverse direction?
>
> Thanks,
> Bruce
>
> On Dec 7, 2007 6:35 PM, Nelson Bolyard <NOnels...@nobolyardspam.com>
> wrote:
>
>> _______________________________________________
>> dev-tech-crypto mailing list
>> dev-tec...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
Florian Weimer
> Florian Weimer wrote, On 2007-12-07 02:54:
>> Is it possible to configure NSS (or, more precisely, Firefox) to
>> terminate SSL connections on the web proxy, so that the proxy receives
>> requests in the clear (and handles the certificate verification)?
>
> I think, but am not certain, that you're describing something like this:
>
> Intranet public Internet
> [browser]----------[proxy]---------------------[server]
> plain SSL
Yes, exactly.
> If that's what you're asking, the answer is: no. The browser cannot be
> configured to fetch an https URL without using SSL itself.
Oh, how unfortunate. Is it possible to disable all certificate checks?
Nelson Bolyard
> NOTE2: None of the proxy nelson mentioned will work if the user is using
> SSL client auth.
I would say two things about that:
1) SSL client auth is generally controlled by the server, not the client.
2) There are reverse proxy products that will do SSL client auth, IIRC.
/Nelson
Florian Weimer
>> Oh, how unfortunate. Is it possible to disable all certificate checks?
> So the question naturally arises: "why do you want this?".
I want to get rid of the HTTPS confirmation dialogs for testing
automation purposes, preferably without patching the source code. (The
latter is always an option, of course, but I'd rather avoid it due to
its overhead.)
> I've seen proposals for this kind of gateway back in the early 90's as
> a way of providing secure email access for browsers which did not
> support https:.
IIRC, Netscape 3 or 4 had some kind of "extend trust to proxies" option.
Nowadays, the problem is solved by transparently issuing fake
certificates from a special CA (or browser helper objects in IE land).
But I don't plan a large-scale, interoperable deployment, so I'd prefer
patching the source.
Robert Relyea
> * Robert Relyea:
>
>
>>> Oh, how unfortunate. Is it possible to disable all certificate checks?
>>>
>
>
>> So the question naturally arises: "why do you want this?".
>>
>
> I want to get rid of the HTTPS confirmation dialogs for testing
> automation purposes, preferably without patching the source code. (The
> latter is always an option, of course, but I'd rather avoid it due to
> its overhead.)
>
into your database. That would be much easier than trying to build a
proxy to do basically the same thing.
>
>> I've seen proposals for this kind of gateway back in the early 90's as
>> a way of providing secure email access for browsers which did not
>> support https:.
>>
>
> IIRC, Netscape 3 or 4 had some kind of "extend trust to proxies" option.
>
Netscape 3/4 days;).
bob
Florian Weimer
>>> I've seen proposals for this kind of gateway back in the early 90's as
>>> a way of providing secure email access for browsers which did not
>>> support https:.
>>>
>>
>> IIRC, Netscape 3 or 4 had some kind of "extend trust to proxies" option.
>>
> Not when it comes to SSL;). (some of us are still around from the
> Netscape 3/4 days;).
Hehe. No, I've seen such a setup in the late 90s. Perhaps it was a
customized version. This was when the crypto regulation debate was in
full swing over here.