Configure your client so it *requires* start-tls, and it will error out
if this attack is attempted. The same attack is possible against SASL,
if you remove DIGEST-MD5 and add PLAIN. The defense is to configure
your client to only allow non-plaintext SASL mechanisms.
--
Joe Hildebrand
Denver, CO, USA
On May 10, 2004, at 8:38 AM, Eric A. Hall wrote:
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.
_______________________________________________
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf