Robert Wolf wrote:>> else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you >> have enabled something like cram-md5. > > Hi, > > exactly, this is the reason, why plain-text is still needed. You don't need > encryption for authentication, if you have secure authentication. Without > knowing original password, the MITM cannot generate correct hash for login, so > the connection can be plain-text.You don't need plaintext to use CRAM-MD5: there's no problem have *both* CRAM-MD5 and SSL (it's overkill, but works). And mail data is worth protecting too.> Of cource, if you then download your emails, the MITM can still read these > emails too, if these emails are plain-text (not encrypted using e.g. SMIME or > GPG). But he cannot misuse your login.No argument here about using end-to-end encryption, but protecting mail data and metadata is important too. Don't forget also, it's not just about the privacy (reading) of mail data, but it's also important to guarantee the authenticity of mail data from tampering. By the way, if we assume a hostile network where MITM is possible, then even closing STARTTLS ports will not guarantee confidential transport: the MITM attacker can merely open up a fake plaintext-only service port, then proxy that to the target server. The client must deny non-secured transport to be fully protected. Joseph Tam <jtam.home at gmail.com>
On 23/08/17 11:13, Joseph Tam wrote:> You don't need plaintext to use CRAM-MD5: there's no problem have *both* > CRAM-MD5 and SSL (it's overkill, but works). And mail data is worth > protecting too.The problem is, as I already pointed out, that using CRAM-MD5 or any other form of challenge-response password mechanism requires that the password be stored on the server in plain text. Furthermore just the advertisement of CRAM-MD5 in a response advertises to an attacker that you do indeed store the passwords as plain text. I would much rather store the password as a hash on the server and only offer up the PLAIN and LOGIN types on an encrypted connection.> No argument here about using end-to-end encryption, but protecting mail > data and metadata is important too. Don't forget also, it's not just > about the privacy (reading) of mail data, but it's also important to > guarantee the authenticity of mail data from tampering.Right, the most common means of doing that is to properly authenticate to the submission server and check TLS validity, then the submission server DKIM signs the message. Of course, this implies trust of the submission server.> By the way, if we assume a hostile network where MITM is possible, then > even closing STARTTLS ports will not guarantee confidential transport: > the MITM attacker can merely open up a fake plaintext-only service port, > then proxy that to the target server. The client must deny non-secured > transport to be fully protected.Yes, exactly! If the client accepts a non-secure connection then it doesn't matter what the server does. It's the client that must be vigilant here. That said, a client that is configured to port 465 would require a config change in order to accept a plaintext connection, but then so would a client that is configured to port 587 and mandatory encryption. Peter