Mailing List CGatePro@mail.stalker.com Message #106999
From: Tom Rymes trymes@rymes.com <CGatePro@mail.stalker.com>
Subject: Re: TLS Sessions - current state of affairs
Date: Mon, 29 Oct 2018 08:46:16 -0400
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
Well, the complaints that we get aren't about encryption, they are about deliverability. Namely:

"I am waiting on an e-mail from this large potential customer so we can close a big deal. They tell me that our server keeps kicking back their messages. They aren't some tiny company that doesn't know what they are doing, and they say that they don't have this problem with anyone else. They can send me messages at my personal Gmail account, so it's definitely not a problem on their end. What is wrong with our server that they can't send us mail?"

At the end of the day, e-mail is about enabling communication, and when the message doesn't get through, that's all anyone cares about. It's my job to find a way to make that happen without degrading security.

Tom

PS: Unless I am forgetting something, every problem we have encountered was resolved by enabling the option "CBC Ciphers for old TLS", which allows SSL 3.0 and TLS 1.0 to use newer/stronger ciphers than their respective RFCs technically allow. Many large companies have not been able to upgrade to systems that support TLS > 1.0, but have enabled the use of CBC ciphers on their TLS 1.0 systems, and CGP pukes when trying to negotiate cryptography with one of these hosts unless this option is enabled. IMHO, it should be enabled by default, as even though it is not technically RFC compliant, it does not reduce security (one could even say it improves it).


On 10/28/2018 9:18 PM, Shaun Gamble listrdr@redco.com.au wrote:
Mark,

I agree. Wholeheartedly :-)


On 29/10/2018 9:47 AM, Mark Strawcutter mjstraw@iup.edu wrote:
I don't understand the need for encrypted smtp between servers.

The email system I managed for 30+ years never did, and it wasn't a problem.

If someone expressed a concern about security during transport (could count number of incidents on one hand) we suggested they encrypt the messages of concern.

Mark

------ Original message------
*From: *Shaun Gamble listrdr@redco.com.au
*Date: *Sun, Oct 28, 2018 6:06 PM
*To: *CommuniGate Pro Discussions;
*Cc: *
*Subject:*Re: TLS Sessions - current state of affairs

I have had to place a number of sites in the exemption section so no
encryption is used at all. These are major players in online bookings in
the tourism sector world wide (online hotel bookings etc.).

Whilst I would love to enforce encrypted connections, it is not
practical in the real world. If I were to refuse non-encrypted
connections, we would miss out on bookings from some of the largest
online hotel booking systems. It doesn't matter how much I complain, I
am only a small player to them. So my settings are similar to yours
Ralf, with the addition of exclusions.


On 26/10/2018 6:47 PM, Ralf Zenklusen, BAR Informatik AG
r.zenklusen@barinformatik.ch wrote:
> Hi Tom,
> sending is getting more difficult since quite some time.
> It seems that one or the other vendor changed the behaviour for TLS/SSL and they don't allow weak/old cyphers or TLS versions anymore.
> But I'm sure there're still many old system out there that need these weak/old cyphers and TLS's.
>
> Right now we still use "Secure wherever possible" with TLS 1.1 default. But with the above constellation the exception lists, to send plain, gets longer every day.
>
> We'll switch to "TSL 1.2 with strong cyphers only" soon. Maybe 1.1 - still needs some testing.
> This in combination with "Secure wherever possible" and the feature from 6.2.9 "decrease the security of the next delivery attempt until plain" should result in a good security with good compatibility.
> In that case you will use plain with old systems, but they don't care and you can't change it.
>
> Receiving is usually much less of a problem because CGate supports almost everything.
>
> In any case you can use CGate's "Send Encrypted", "Require TLS", client certs, DANE etc. to further improve security - if you need to.
>
> Regards
> Ralf
>
> -----Ursprüngliche Nachricht-----
> Von: CommuniGate Pro Discussions [mailto:CGatePro@mail.stalker.com]
> Gesendet: Freitag, 26. Oktober 2018 09:02
> An: CommuniGate Pro Discussions
> Betreff: Re: TLS Sessions - current state of affairs
>
> Thanks for your response, Tom. I’m well aware of the tradeoff. However, I’m curious if someone has recently experimented with settings other than the most lenient ones. I mean, it might be that, for example, dropping SSLv3 support wouldn’t be a significant tradeoff anymore.
>
>
>> On 25 Oct 2018, at 20:45, Tom Rymes trymes@rymes.com <CGatePro@mail.stalker.com> wrote:
>>
>> I don't think anything has changed? My understanding is that, in the context of a mail server, which will generally accept new messages in plaintext, fretting about the encryption strength of the TLS session is often considered to be excessive.
>>
>> The tradeoff is deliverability vs. encryption strength, as if you require encryption from everywhere, and/or require strong encryption, the list of servers that will be able to successfully exchange mail with your server will rapidly grow to be very short.
>>
>> It is up to each admin to choose the proper tradeoff for their needs?
>>
>> Tom
>>
>> On 10/25/2018 1:28 PM, Palvelin Postmaster postmaster@palvelin.fi wrote:
>>>> On 16 Oct 2018, at 10:09, Palvelin Postmaster postmaster@palvelin.fi <CGatePro@mail.stalker.com> wrote:
>>>>
>>>> I wonder what the current state of affairs is with the various TLS Sessions options regarding old/insecure ciphers.
>>>>
>>>> Can/should the CBS and Weak Ciphers options already be disabled and what should the Oldest Accepted option be set to?
> Palvelin.fi Hostmaster
> postmaster@palvelin.fi
>
>
> #############################################################
> This message is sent to you because you are subscribed to
>    the mailing list <CGatePro@mail.stalker.com>.
> To unsubscribe, E-mail to: <CGatePro-off@mail.stalker.com>
> To switch to the DIGEST mode, E-mail to <CGatePro-digest@mail.stalker.com>
> To switch to the INDEX mode, E-mail to <CGatePro-index@mail.stalker.com>
> Send administrative queries to <CGatePro-request@mail.stalker.com>
>
>
>
>
> #############################################################
> This message is sent to you because you are subscribed to
>    the mailing list <CGatePro@mail.stalker.com>.
> To unsubscribe, E-mail to: <CGatePro-off@mail.stalker.com>
> To switch to the DIGEST mode, E-mail to <CGatePro-digest@mail.stalker.com>
> To switch to the INDEX mode, E-mail to <CGatePro-index@mail.stalker.com>
> Send administrative queries to <CGatePro-request@mail.stalker.com>

-- Shaun
Fitzroy Island <http://www.fitzroyisland.com> Cairns, QLD
Destination Darwin NT <http://www.destinationnt.com> Darwin, NT
MOM Backpackers <http://www.momdarwin.com> Darwin, NT
Value Inn Hotel <http://www.valueinn.com.au> Darwin, NT
Crocosaurus Cove <http://www.croccove.com> Darwin, NT
Please do not send any unsolicited email. It is not wanted.


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <CGatePro@mail.stalker.com>.
To unsubscribe, E-mail to: <CGatePro-off@mail.stalker.com>
To switch to the DIGEST mode, E-mail to <CGatePro-digest@mail.stalker.com>
To switch to the INDEX mode, E-mail to <CGatePro-index@mail.stalker.com>
Send administrative queries to <CGatePro-request@mail.stalker.com>

-- Shaun
Fitzroy Island<http://www.fitzroyisland.com>  Cairns, QLD
Destination Darwin NT<http://www.destinationnt.com>  Darwin, NT
MOM Backpackers<http://www.momdarwin.com>  Darwin, NT
Value Inn Hotel<http://www.valueinn.com.au>  Darwin, NT
Crocosaurus Cove<http://www.croccove.com>  Darwin, NT
Please do not send any unsolicited email. It is not wanted.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster