Microsoft announces new ways to bypass security controls

For those not keeping up with Microsoft, because so many people have
started blocking Netbios, RPC, SMB, etc; Microsoft announced yet another
way to bypass security.

On August 1, Microsoft introduced Exchange 2003. With Outlook 2003 this
introduces an new implementation fo Exchange's MAPI protocol over HTTP
allowing clients to natively connect to Exchange servers without using a
virtual private network (VPN).

Steve Conn, Microsoft's Product manager was quoted as "Since we have got a
good implementation, we're going to keep supporting it." Microsoft will
evangelise the new protocol, and developers of other mail clients and
servers will be encouraged to implement it.

http://www.microsoft.com/office/ork/xp/beta/three/ch8/OutC07.htm

"Outlook 2003 now offers a better alternative to VPN connections -- RPC
over HTTP. With this feature, users can have security-enhanced access to
their Exchange Server accounts from the Internet when they are working
outside your organization's firewall. Users do not need any special
connections or hardware, such as smart cards and security tokens, and they
can still get to their Exchange accounts even if the Exchange server and
client computer behind the firewall are on different networks."

By the way, Microsoft's RPC-Over-HTTP uses one of the ports in another
Microsoft security advisory concerning RPC vulnerabilities. Extending
the list of dangerous ports to include 593, RPC-over-HTTP. A suggested
work around, use a virtual private network (VPN).

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.

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.

Below this we see IMAP, IM, telnet (rare) and a storm of snmp from
windows machines trying to manage HP printers.

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?