Re: SSL

["Paul D. Robertson" <proberts () patriot net>]

On 18 Oct 2001, Eric Rescorla wrote:
> Frederick M Avolio <fred () avolio com> writes:
> > firewall. It is possible to do, but few customers (Paul Roberson) ask for it.

Since Fred went and drug me into this... ;)[1]

> It's only possible to do this if the client cooperates. Otherwise, it
> gets blocked by the same mechanisms that stop a man-in-the-middle
> attack on SSL.

That's not true if you control both DNS and the ability to make yourself a
trusted CA on the client, which most corporate administrators can.
                                                       
Processor speeds are getting to the point where generating certificates on
the fly is doable, especially with custom-built accelerators, but even
with generic SMP machines we're at the point where generating a
self-signed certificate for a random site is doable on the fly.  If you're
doing outbound authentication for SSL, the wait isn't even noticable to
the end-user, since by the time they've gotten through the authentication
dance, you've generated the certificate.  You only need to generate the
cert once per site, so "first time" visits are the only ones that will
even seem strange to the user- take away the entropy gathering bit 
and it's pretty quick especially if you pin cert generation to its own
CPU.  

[Insert evil "modify the browser upgrade in transit" thoughts here.]

I never dug enough into the proxy specs to see if there was an even easier
way to do it- you can also do URL rewriting for 99% of the cases anyway if
my old proxy logs were typical where you rewrite any https URL that comes
into the proxy to an HTTP one, and rewrite it again on outbound client
activity from the proxy- that only leaves you with people who start at an
https:// URL the first time a site is ever visited- if you time that one
out while generating the cert and updating the DNS you're pretty much
there.  I'm still not sure that there isn't a redirect or proxy rewriting
trick that wouldn't cover that case as well, I just never dug far enough
into the specs.

Since I required pre-approving sites that I'd let people talk SSL to,
certificate generation probably would have been my solution if I'd had to
implement such protection measures.  Rewriting always seemed like much
more fun though code-wise- since I thought forcing browser plug-ins or
custom browsers was too difficult to admin at the desktop (though I did
think that mitm:// would have been the ultimate rewrite for inbound https
AND force the initial visit problem to go via user educaion and cover the
ECPA issues[2].)

Stopping MITM requires pre-shared private keys or an unbreakable trusted
introducer model.  The trusted introducer's public key sitting on the
filesystem of a 9x box isn't unbreakable, the ability to add new trusted
introducers, lack of trusted DNS, and ability manipulate the routing path
all add up to MITM in my book.

Paul
[1] The inability to stop active content via proxy servers is an old rant
of mine, and even the scent of such conversation is likely to get me to
jump into the middle of it.
[2] The idea wasn't to monitor, but to be able to do malcode and active
content removal/detection with the option to monitor people who did bad
things upon request.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards