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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf