Microsoft announces new ways to bypass security controls

Mon Sep 15 14:40:14 UTC 2003

At 03:22 AM 9/15/2003, Mans Nilsson wrote:

>Subject: Microsoft announces new ways to bypass security controls Date: 
>Sun, Sep 14, 2003 at 10:03:32PM -0400 Quoting Sean Donelan (sean at donelan.com):
> > Of course, Microsoft isn't the only one with mail protocol security
> > weaknesses.
> >
> > POP3 is probably responsible for more cleartext passwords being
> > transmitted over the Internet than any other network protocol.
>
>That statement is nicely supported by my dnsiff logs from various
>networking conferences -- the top three have always been:
>
>POP
>webmail without SSL
>other http apps without SSL.

We see that even when we offer POP with SSL and SMTP AUTH with SSL, few 
customers wind up using it. That there are continuing problems with the 
commercial certificate infrastructure doesn't help matters.

Examples of the problems:

1. Eudora contains root certificates only for Verisign and Thawte, and uses 
its own root certificate store, whereas Microsoft client tools (for all 
their other weaknesses) include a much broader array of root certificates. 
If you want to buy certs from someone other than Verisign (since they own 
Thawte) you have to talk users through integrating other root certs (or 
your cert) into their copies of Eudora. Or just use a private CA and talk 
your customers through importing the root cert from your private CA.

2. SSL incompatabilities: Eudora changed their method of negotiation with 
Eudora 5.2 and later. The result is an inability to negotiate TLS with 
Sendmail/Openssl. A configuration parameter in Eudora gets it to go back to 
the "old way" in their code, which works fine. But now we're talking about 
another case of talking an end user through a configuration. Might be OK 
for a corporate setting, but it gets pretty problematic for the ISP.

We've clearly got the mechanisms to allow encryption on the most important 
of the protocols. However the infrastructure and compatability issues make 
them more difficult to employ than should be the case.

That these problems show up at networking conferences (IETF, NANOG, etc.), 
though, really points to a larger problem. If network research, engineering 
and operations folks can't manage to get encryption deployed for 
themselves, how likely is it that end customers will use them?