On 5/10/2004 10:31 AM, Paul Hoffman / VPNC wrote: > At 9:38 AM -0500 5/10/04, Eric A. Hall wrote: >> Using an encrypted port just means an attack can only produce >> failure, rather than inducing fallback. >> >> Unless that's wrong for some reason, I'd say that a "secure ports >> policy" actually is more secure. > > In many cases, a client for a "secure ports policy" protocol will fall > back to the insecure port instead of telling the user "you can't > communicate". That's not true for HTTPS, but it is true for secure POP, > secure SMTP, and so on. This is a fair enough point, and I should have accounted for it, but I don't think its absence weakens the merits of the first point any. I'm not even sure they are similar arguments. I mean, the argument against SSL is that *if* an SSL connection is blocked, and *if* an alternative clear channel exists, and *if* that channel accepts clear-text logins, and *if* the client fallsback through all of that, then the session will be exposed. I'll grant that it's easy enough to interfere with somebody establishing a session, and that there's a measurable percentage of services that maintain clear channel alternatives, and that PLAIN/LOGIN are still the only things that work everywhere, and that there are probably clients which fallback invisibly. I can also argue some of those points to some degree -- that people who have setup SSL versions are likely to have eliminated access to the clear channel, for example -- so instead of any of those things being certainties, we should agree that this is a question of overlapping probabilities. On the other hand, STARTTLS *requires* a clear channel that the client MUST *already* be using. So whereas the attack on SSL *might* succeed in putting the client in touch with an unencrypted service, TLS is *guaranteed* to be using such a service already anyway. The only question is whether or not a decipherable login can be used, which is a probability mask that also applies to the SSL scenario. Given the collection of probabilities, therefore, starting with an SSL channel and refusing connections to a backup clear channel eliminates most of the probability from the MitM attack model. Conversely, those attributes are prerequisites to the very existence of TLS. Ergo, TLS is weaker against this particular vector, by design. I don't think it really matters given the other problems (see below). > A man-in-the-middle can more easily block the secure port than he/she > can elide the STARTTLS messing in the client's start-up. That's true. On the other hand, channeling clients through a proxy is easy, especially if they are on a foreign network. The client can be tricked into using a different host via DNS attacks, or can simply be routed through proxies, NATs, firewalls, or any number of 'transparent' proxies that can be easily deployed. STARTTLS can be disabled by any of these, using a two-bit attack (literally: borrow one bit from the T and hand it to the S, causing the service to be advertised as "TSARTTLS" -- I've seen worse than that from unintentional bugs and intentional features alike). > Any client that is willing to back down to non-secure mode is > susceptible to a MITM attack, regardless of the protocol. agreed on that -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf