On 5/21/2015 10:48 AM, Akimiya wrote: > Thanks a lot, that was a great answer - the most is clear now. Just a few > things to clarify. > > As much I understood, if I set the `*_security_level` to `may` then the > `*_mandatory_ciphers` option is not even considered. Since the the mandatory > is for mandatory TLS and we set opportunistic TLS with `may`. So I think it > wont hurt to just let them on high, just to be sure? > On the other hand the options for the smtp(d)_tls_ciphers are according to > the README by default `export` but I think that medium should work out for > me. >
It's OK to leave the mandatory list at high. > Also can you somehow comment on how the list in smtp(d)_tls_exclude_ciphers > came to be? For those I used e.g. I know that RC4 is vulnerable to BEAST > attacks and SSL is also still insecure, similar to the other two. But for > those you list I kind of cant make up an explanation. I've looked up that > for some Microsoft Exchange Server with the corrupted 3DES there is only KC4 > possible so even when I don't really like it I will let RC4 pass. There was a discussion on this list not too long ago about appropriate settings for exclude ciphers. You can certainly set the mandatory exclude list more strict. > > Additionally can I somehow tell in which cases the mail would not be sent > and in which it will just go back to plain text? That depends on the "how" > TLS fails like you said would an explanation for that be possible? When sending mail, postfix can detect a failed TLS handshake and will retry plaintext. In some cases if the TLS handshake appears to complete but data transfer is not possible, the problem is unclear. When postfix is receiving mail, the decision to retry and/or to downgrade to plain text is under the control of the sender. > I talked > to my boss and it is the biggest priority that everything very secure as > long the trade-off is not too big. So it is fine if I can only talk to about > 95% of the server *AS LONG* I get a clear indication that the transfer > failed because no secure connection was possible. The logs will tell you when a transaction failed, but it's not always clear that it's due to a TLS problem, especially when postfix is the receiver. The logs may show only a connect/disconnect. > So a side question is > whether such applications like Thunderbird will make a clear indication when > sending the message was not possible? Your submission port should have separate TLS settings with encryption required. Don't confuse authorized user submission with general internet mail. > For those who only support plain text I'm ok with it being plain text (since > there is nothing I can do). Basically I want to use crypto wherever I can > and be sure that the best possible connection method is taken. Yes, those are the settings I described. > With the > `*_security_level` at `may` can I really be 100% sure that the best possible > is taken? When you're talking about opportunistic encryption, you have little control and no verification the other party is who you think they are. So don't sweat too much about what kind of encryption they're using. You can send to trusted peers/partners/customers using a secure channel configured with smtp_tls_policy_maps. All others are "best effort". > The way that my boss told me it felt like if there ever is a > problem with the security - since usually very confidential data is sent - I > will get a problem and a ratio of 95% acceptance is ok I understood. Secure your submission service for authorized users, set up secure outbound channels with smtp_tls_policy_maps as appropriate. For everyone else, "any" is better than "none". -- Noel Jones
