[62018] in North American Network Operators' Group
Re: Microsoft announces new ways to bypass security controls
daemon@ATHENA.MIT.EDU (David Lesher)
Mon Sep 15 11:35:35 2003
From: David Lesher <wb8foz@nrk.com>
To: nanog@merit.edu (nanog list)
Date: Mon, 15 Sep 2003 11:32:05 -0400 (EDT)
In-Reply-To: <6.0.0.22.2.20030915100308.0262f698@mail.amaranth.net> from "Daniel Senie" at Sep 15, 2003 10:40:14 AM
Reply-To: wb8foz@nrk.com
Errors-To: owner-nanog-outgoing@merit.edu
Speaking on Deep Background, the Press Secretary whispered:
>
>
>
> 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.
While the approval process for other certs in Eudora is obscure,
it at least works. I ran into a brick wall trying to get Infernal
Exploder for the Mac to accept same; the Windows version was not
a problem.
> 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.
Note Eudora 6.0 has a public configuration setting for the flavor
of SSL.[1] Yes, it should be automagic but "the nice thing about
standards in this industry..." applies lots of places...
> 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?
WhatHeSaid.
We really need to do a better job of begging/cajoling/requiring encryption. I
know one ISP that requires POP/SMTP be on SSL unless you're on their dialup,
and I've heard Worldnet does too. [true?] The rest?
[1] At least in the Mac version I can lay hands on..
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
