Re: encryption options for public networks?

On Jan 21, 2005, at 3:22 PM, Casey Halverson wrote:

> http://www.f5.com/f5products/products/FirePass/
> http://www.juniper.net/products/ssl/ra_500.html
>
> The concept is simple:  Open a web browser, and surf to the firepass 
> via
> HTTPS.  You get a login screen.  Enter your login and password, and
> something magical happens.....Depending on your platform, the next page
> contains a special ActiveX or Java applet.

Wow.  Do you *really* want a Java applet shimming its way into your IP 
stack?  Why is there an ActiveX version if the Java version is worth 
anything?  And how exactly does this method protect against spoofing 
APs?

Back to Michael's problem:  As far as protecting your mother's email 
goes, she should know that checking the "SSL" box on her POP or IMAP 
account in her email client is vitally important.  Ditto for making 
sure that the little key is lit up on her web browser before sending a 
credit card.  If her email provider won't do SSL for her, tell her to 
get one who does, or use Yahoo mail (and be sure to check the SSL box 
yet again before logging in).

Why do I bring up SSL instead of going into the myriad VPN solutions 
you could attempt to use to build a "public encryption system"?  First, 
it's already installed and really, really easy to use.  But most 
importantly:

(come on, join in, you know the words!)

SSL provides end-to-end, application layer encryption.

And it's not just the encryption that's important...  SSL has a 
certificate authority to verify that the keys being used are really 
from a trusted server, and not from Jane Q. Cracker posing as paypal or 
citibank.  SSL is the simple, mom-proof tool that's already installed 
on her laptop, PDA, and cell phone.  If she wants more protection than 
that, she's got to learn a bit about network security.

If you want to set up a public access, opportunistic encryption sort of 
server, you have a serious problem to solve:  key distribution.  If you 
give out the same password to anybody who asks for it, you run the risk 
of a badly implemented protocol that lets anyone with the key decrypt 
the entire session.  If you rely only on public key crypto, you run the 
risk of man-in-the-middle spoofing.  To be sure that you're not 
providing a false sense of security, you need to verify public keys 
after they're exchanged, preferably on both sides of the connection.  
SSL is useless without a CA, just as ssh is useless if you always type 
"yes" whenever a host key has changed.  Even PGP has this problem, 
hence paranoid pasty teenage boys who throw key signing "parties".  
(I've been to these parties, and trust me, it ain't a party if there 
aren't any girls.  =)

SSL has solved the key distribution problem, key verification problem, 
and the easy-to-use encryption problem for you.  Use it.

If you're *still* bent on building some security management nightmare, 
you're not going to be able to provide anything for users of open 
access points until you can prove without a shadow of a doubt that your 
AP (or some host on the Internet) is who it claims to be.  SSL can do 
that for you if you use certs signed by a trusted CA.  SSH can do that 
if you have a good cache of host key fingerprints already installed.  
PPTP *might* do that for you if it's a recent version using MS-CHAP v2, 
see http://www.microsoft.com/ntserver/support/faqs/VPNSec_FAQ.asp.  
IPSec can do that for you if you use trusted certs.

As far as I can tell, there is no magic green lightbulb that will light 
up in your menu bar or system tray that tells you that the network is 
"secure" without some user intervention.  Current wireless security 
protocols are just not designed for open networks.  If the association 
phase of a wireless connection used public keys signed by a well known 
CA and issues individual session keys to each user, you might have 
something...  802.1x still has the problem of managing unique 
credentials for your users.  You could build something tricky with a 
powerful AP (<ahem> Metrix Mark II <cough>) but you'll still have to 
distribute a key and likely a software client to your users.

In short, you're screwed if you're trying to provide a free, open, 
opportunistic encryption service.  Let Hotspot VPN sell their private 
service.  Let Linksys and the like sell little IPSec boxes for the 
home, and tell your users to buy one of them and install a good IPSec 
client.  Tell your mother to use SSL.  And let the knowledgeable users 
roll their own solution.  It's really not that hard from the user's 
side, but it's damned difficult for a public network provider.

--Rob

_______________________________________________
Dev mailing list
[email protected]
http://seattlewireless.net/mailman/listinfo/dev