On 5/10/2004 3:02 AM, RL 'Bob' Morgan wrote:
So a "secure ports only" policy has very little to do with security and very much to do with organizational power relationships, and making your computing environment dysfunctional.
Somebody check my math on this please, but it seems to me that the whole STARTTLS approach is succeptible to a specific attack which the secure socket model is not.
Specifically, a man-in-the-middle can "blank out" the STARTTLS feature advertisement, and thus make the client believe that TLS is not available. For example:
server-A MitM client-C | 250-DSN | 250-DSN +--> 250-AUTH +-> 250-AUTH 250-STARTTLS 250 ok [...pad...] 250 ok
The client, seeing that TLS is not available, dumbs down to cleartext. Most clients would probably do that invisibly without even barking at the user, or not doing so in a way that most of them would appreciate.
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.
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. STARTTLS is harder to mount than blocking a "secure port". Thus, the "secure ports policy" makes the MITM's job easier.
BTW, sometimes the MITM in the "secure ports only" scenario is a clueless firewall admin at any point in the transit. The STARTTLS method is not susceptible to this unintentional-but-still-deadly downgrade attack.
Any client that is willing to back down to non-secure mode is susceptible to a MITM attack, regardless of the protocol.
--Paul Hoffman, Director --VPN Consortium
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf