North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Microsoft announces new ways to bypass security controls

  • From: Daniel Senie
  • Date: Mon Sep 15 11:07:58 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 ([email protected]):
> 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?