RE: SSL

["Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>]

> -----Original Message-----
> From: Ames, Neil [mailto:NAmes () anteon com]
>
> I am baffled by how a proxy would handle the SSL exchange.  
> Aside from all
> other issues related to this thread-such as defenses at the 
> client, or the
> break in end-to-end encryption

This is the basis of a tool called httpush, and my own derivation of it
called mangle. They are designed to "audit"/record the HTTP and HTTPS
traffic between a browser and any number of servers.

The way it works is as follows:

Browser uses the software as the HTTP and HTTPS proxy.

HTTP proxy is easy to handle, the app simply records the request and the
headers, and does whatever is required to the returned content.

e.g. Browser sends "GET http://www.nfr.com/ HTTP/1.1<CR>[Assorted headers:
values]<CR><CR>" The proxy fetches the requested URL from the named server,
Bob's your auntie.

HTTPS works as follows:
Browser connects to the proxy, says "CONNECT www.nfr.com:443
HTTP/1.1<CR>[Assorted headers: values]<CR><CR>".

Normally the proxy simply makes a TCP connection to the named server and
port, sends a "200 Successful" response to the browser, connects the browser
directly to the server, and gets out of the way, simply passing packets in
either direction.

Using this technique, one can establish TCP connections to fairly arbitrary
ports, depending on the configuration of the proxy.

Given that there is now a pseudo-direct TCP connection between browser and
server, they can now negotiate an SSL session, and be happy that they are
talking to who they think they are.

Now for the interesting part.

As before, browser connects to the proxy, says "CONNECT www.nfr.com:443
HTTP/1.1<CR>[Assorted headers: values]<CR><CR>".

Again the proxy sends the "200 Successful" response to the browser, but does
not connect the client to the server directly. Instead, the proxy shifts
into SSL mode, ready to start negotiating an SSL session with the client by
itself. Clearly, the proxy cannot have the appropriate SSL
certificate/private key to successfully fool the browser (one hopes!) and
the browser should alert the user. However, if the user accepts the invalid
certificate, the SSL session would be successfully negotiated, WITH THE
PROXY.

The proxy would then receive a "GET / HTTP/1.1<CR>etc" request, add that to
the already requested hostname and port, and make the request on the
client's behalf. 

In this way, the proxy is able to access the request and the returned
content, and do whatever it wants to with it.

As was mentioned in another response, a major issue if this option is
selected, is how one notifies the users of valid or invalid certificates
received from the actual server connected to by the proxy. That needs to
become a hard rule in the proxy itself, that if any upstream certs cannot be
verified, then the connection should be aborted, and a suitable message
returned.

But that's how such a proxy could work, if the problem was deemed severe
enough.

Hope that helped.

Rogan

> -----Original Message-----
> From: Ames, Neil [mailto:NAmes () anteon com]
> Sent: 18 October 2001 10:02
> To: firewall-wizards () nfr com
> Subject: RE: [fw-wiz] SSL
>
>
> I am baffled by how a proxy would handle the SSL exchange.  
> Aside from all
> other issues related to this thread-such as defenses at the 
> client, or the
> break in end-to-end encryption--what is right or wrong with 
> the following?
>
> 1) A user hits an SSL site with a cert (that the user's 
> browser may or may
> not trust, and the firewall's proxy may or may not trust).  
> 2) The proxy lets the user determine that the proxy is going 
> to trust the
> cert, according to some policy rule that allows that.
> 3) Proxy manages, somehow, to act as intermediary.  (This is 
> what I don't
> get.)
> 4) The proxy sets up the SSL tunnel with the remote site.
> 5) The proxy sets up the SSL tunnel with the users browser.
> 6) The proxy checks everything as it hands pieces of the user-Web site
> exchange, filtering according to policy.
>
> What am I missing, particularly in how steps 3 and 5 would work?
>
> Thank you,
>
> Fritz Ames
>
>
> -----Original Message-----
> From: Scott, Richard [mailto:Richard.Scott () BestBuy com]
> Sent: Wednesday, October 17, 2001 2:20 PM
> To: 'Crumrine, Gary L'; firewall-wizards () nfr com
> Subject: RE: [fw-wiz] SSL
>
>
> <snip>
>         Just a quick question on SSL.  If I allow SSL 
> outbound, and a user
> browses a web site that is corrupt with something harmful 
> like NIMDA, is it
> possible that they will infect my network... and will the 
> firewall not pass
> it along without checking?
>
>         If true, how can I combat this?  Is there a product 
> that will stop
> the packets and inspect them before being returned to the requester?
> <!snip>
>
> Gary,
>
> It all depends on what measures are in place and the 
> injection vector used
> in contaminate your network.  SSL, like most tunnels protects 
> from man in
> the middle attacks.  What ever data is passed through the 
> tunnel, travels
> through it from one end to the other.  Simply using SSL as a 
> mechanism does
> not prevent infections from hostile web code.  SSL prevents 
> the vector of
> attack performed by sniffing the data.
>
> In the instance of Nimda, one would have to look at the 
> injection vector,
> the method of attack.  Let's assume that it was a single vector, the
> malicious java script code and one is trying to protect the 
> user (client
> side).  This can be prevented by two popular mechanisms.  1) 
> educating users
> to switch of Javascripting in a browser or 2) Firewall packet 
> inspection.
> There are other methods, but assuming that you do not want the code to
> excute (rather than exploit a bug), these mechanisms would be 
> used.  There
> are politics to each mechanism, and there are better 
> protection mechanisms
> using signatures that are available.
>
> So to answer you question, you can do packet inspection 
> (processing could be
> very high), you can do SSL, you can educate users.  A good 
> security policy
> would involve many methods and the reason is simple.  
> Multi-pronged attacks
> that Nimda has. infected systems from servers to clients 
> using different
> vectors.  Using just one mechanism would not have prevented 
> your system
> getting infected (of course, you could have been on a Unix 
> platform, the
> only single mechanism that would have combated it).
>
> readinteh archives in this mailing list you can have a sense 
> of what the
> professionals are considering... if you want to do packet 
> inspection on SSL,
> you may need to proxy the SSL data to be able to inspect it.
>
> BTW - Does anyone have any pointers to be able to SSL packet 
> inspection on
> the data?
>
>
> Cheers
> r.
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards