Dmitry Alexandrov <[email protected]> writes: > Greg Troxel <[email protected]> wrote: >> Dmitry Alexandrov <[email protected]> writes: >> >>>> Are you using TLS for SMTP/IMAP? >>> >>> He apparently uses opportunistic encryption (STARTTLS) for some >>> reason. In such a case a paranoid default behaviour of a server might >>> be understandable (yet not tolerable, if is not optional). >> >> I think it's necessary to separate: >> >> 1) connect and just be unencrypted >> 2) connect, try STARTTLS, and continue on success or failure >> 3) connect, try STARTTLS, and disconnect on failure >> 4) connect via forced-on TLS (a la https) >> >> I don't see that 3 is worse than 4. 1 is obviously bad, and 2 should >> give confidentiality from eavesdroppers but fails with active attackers. >> However, a typical wifi has an active attacker called a captive portal. > > You are judging from a client point of view, while we are discussing > what is reasonable for a _server_. Their trust has asymmetricity, > originating from a flaw of centralised trust model of X.509, a flaw > not technical but social, yet not less fundamental: a client can and > normally shall verify server’s public key, but the server in practice > cannot do the same, because a client typically has none.
I didn't realize y'all were talking about servers; I thought the OP was worried about his client. A fair point that I am thinking about clients. If you have a situation where the server operator has security concerns that the client does not have or does not grasp, then what you say makes sense. This is basically the company/etc. situation and maybe ISPs. > So all server knows, that there is an encrypted connection. Whether > it came from the other end, or from an attacker in the middle, that > stripped STARTTLS negotiation or even downgraded proper TLS to plain > connection, which passed unnoticed by a client, that accepts > unencrypted connections, — it can only guess. And it _do_ guess > basing on a collected knowledge of this very user’s habits. Even with non-STARTTLS forced-on SSL/TLS, it still doesn't know. It just knows that it got a connection and that the password appears. Consider a client that tries forced-on SSL/TLS (e.g. IMAP on 993) and then falls back to unencrypted. A MITM blocks 993, steals the unencrypted connection and then makes SSL to 993. > Knowing, that the user _does not use_ proper TLS, and that connection > came form a place he’d never been before, an overwatchful server > suggests the worst. ok, but if the client doesn't behave safely, I think you're just doomed. >>> Anyway, you really do not want to use STARTTLS instead of full-plate >>> TLS, if your server supports it (if they are so concerned about >>> security, they ought to). >> >> Why, if the client ... disconnects if TLS is not negotiated? > > Because server doesn’t know that, and goes paranoid voiding a password. I am unaware of servers disabling people's accounts because of STARTTLS usage. Does any mail provider actually do that? -- You received this message because you are subscribed to the Google Groups "K-9 Mail" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
