Quote:
Originally Posted by dgcom
Well, I might have not explained this properly, but what I meant was that if server-to-server SMTP started and negotiated encryption after issuing STARTTLS, but that ended up failing due to supported ciphers, that server should not retry again and ignore STARTTLS completely.
(BTW, it was a late night when I wrote the part you quoted, so I am not even sure now what I meant but the second bullet - most probably that it _should_ support same level of encryption)
If transmission was over unencrypted channel, I can see that in headers and decide how much I should trust this message accordingly, especially knowing that other side should be perfectly capable of good encryption.
When client submitted message - event if it made sure the connection was properly encrypted, it is now out of its control and he has to trust provider to deliver the message to other end over the best possible link... If Google or even Yahoo would refuse delivery (or acceptance) over SSLv3 and won't retry completely unencrypted, I feel that is better for me than FastMail just using weak cipher and call it a day.
I perfectly understand your choice, do not get me wrong! I am just thinking that if major providers chose to disable SSLv3 and you have couple of clients holding you up to this for some strange reason, I'd rather follow industry. Unless those clients are the main income producers  |
Obviously, senders can refuse to deliver based on whatever combination of rules they want. The point is that it doesn't matter what FastMail advertises.
I repeat. _it_does_not_matter_. Because an active proxy can rewrite that however it likes, offering SSLv3 only, or offering plaintext only. So the only thing that will stop those being used by an active attacker is senders refusing to send at all in those cases.
We probably will follow the industry pretty soon. I'd love to be able to lead the industry in these cases, but the simple fact is that we're not big enough to unilaterally stop accepting SSLv3. Now that Google have done so we probably can too and just tell out customers to tell their senders to upgrade:
http://www.infoworld.com/article/307...ers-gmail.html
(June 16 apparently)
You have probably read the explanation of why we only support the SSL/TLS ports and not the StartTLS ports for IMAP/POP to avoid clients downgrading to plaintext and sending their passwords across the wire in the clear. We can reject that, but it doesn't stop the password having already been sent! In the theory vs practice world, not listening on port 143 provides better security, but not offering SSLv3 is just wishful thinking while plaintext fallback is a thing.
Of course we haven't even started addressing the other elephant in the room, which is that nobody verifies client certificates for SMTP, so even if we enforce that the connection to our servers users the latest and greatest algorithms, we don't know who the other endpoint is. They could be an active proxy offering plaintext back to the real sender and we'd never know.