PMFJI...
How does one utilize something like a Cisco PIX firewall in an SSL
environment? On option the firewall seems to offer is translation of
network addresses, so a message that might be routed to vvv.xxx.yyy.zzz (a
web-registered address) could rerouted to a private network address by the
firewall. But wouldn't that cause some grief at the SSL server when it's
fielding a message destined for some private network address, but it's
certificate is registered for vvv.xxx.yyy.zzz and an associated domain name?
Or is it only the client that is concerned with this match?
TIA
Harry
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tony Nelson
Sent: Monday, May 01, 2000 9:35 AM
To: [EMAIL PROTECTED]
Subject: Re: Proxy or Firewall
On Mon, May 01, 2000 at 08:44:17AM -0600, Mike Nigbor wrote:
> OK, so how does this differ from a "man-in-the-middle" attack?
>
> Since there are two SSL sessions, there must be two session encryption
keys
> and the proxy must be decrypting and re-encrypting everything it sees.
>
> If I'm a client, shouldn't I reject such a connection?
It doesn't .. it actually is a man-in-the-middle attack.. however, the
"attack"
is being done by the corporation that writes your paycheck.. and there are
very valid reasons for a company to be doing such things.. as a client,
(or server) you really have no way of detecting that this is happening..
Basically, you end up w/ this picutre..
-------- ------- ----------
| user | --- session 1 --- | f/w | --- session 2 --- | server |
-------- ------- ----------
Hope this helps,
Tony Nelson
TIS Worldwide, Firewall Admin
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of James Dabbs
> Sent: Saturday, April 29, 2000 6:41 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Proxy or Firewall
>
>
> I believe that many enterprises that do not allow an unbroken SSL
connection
> directly from the client throught the proxy/firewall to the remote server.
> This is because security policy may allows/disallow certain MIME types in
> the entity of the HTTP response. For this reason, SSL is "broken" at the
> proxy, and reestablished with a seperate SSL session between the proxy and
> the remote server. This is not quite as tansparent to the client, but
still
> fairly so. The proxy is much more complicated.
>
> It is my understanding that this scheme is becoming the prevailing
security
> strategy in large corporations, gaining favor over transparent SSL pass
> through. Am I wrong on this?
>
> James Dabbs
>
> James Dabbs
> [EMAIL PROTECTED]
>
> Director of Engineering
> TGA Technologies, Inc.
> Suite 140, 100 Pinnacle Way
> Norcross, GA 30071
>
> 770-441-2100 ext 126
>
> > -----Original Message-----
> > From: Hansknecht, Deborah A [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, April 28, 2000 2:57 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Proxy or Firewall
> >
> > A few comments included within...
> >
> > > -----Original Message-----
> > > From: James Dabbs [mailto:[EMAIL PROTECTED]]
> > > Sent: April 28, 2000 5:37 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Proxy or Firewall
> >
> > ..........deleted stuff........
> >
> > > HTTP over SSL, though, works transparently through almost any
> > > proxy. This
> > > is because the HTTP client knows that the proxy exists. It
> > > sets an SSL
> > > session up with the proxy, and tells the proxy to set up a
> > > seperate SSL
> > > session with the actual server. As long as requests are
> > > initiated by the
> > > client, everything is OK.
> >
> > Perhaps I missed some context in other messages that makes the above
> > statements correct (and I am probably veering off-topic), but as written
> > this is not true. HTTP works over SSL thru a proxy transparently because
> > the
> > client knows that a proxy exists, (that much is true) but it DOES NOT
set
> > up
> > an SSL session. The client sends HTTPS via CONNECT which the proxy just
> > passes on to the end server. Your standard HTTP proxy does not negotiate
> > any
> > SSL session with either client or server. (that is obvious if you
remember
> > that you do not need an SSL aware
> > proxy - i.e. Apache with mod-ssl or Apache-SSL - if all you want to do
is
> > proxy HTTP or HTTPS requests.) If you are "reverse-proxying" then the
> > proxy
> > DOES negotiate separate SSL sessions with client and server, but that is
> > an
> > entirely different bucket of worms and the client browser doesn't even
> > know
> > that you are using a proxy.
> >
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
--
Tony Nelson
www.gnupg.org keyid 136C5B87
- Standard Disclaimers Apply -
Boycott Amazon! - http://www.gnu.org/philosophy/amazon.html
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
