Ahoj,
Dňa Sat, 16 Mar 2024 16:53:23 +0100 Marco Moock via mailop
napísal:
> Forwarding (e.g. forwarding as attachment etc.) is still a thing and
> if it is about security, I only trust e2e encrypted mails to be not
> eavesdropped. Everything else is just a guess and nothing else.
TLS is *Transp
Am 14.03.2024 um 11:58:24 Uhr schrieb Slavko via mailop:
> Dňa 14. 3. o 10:21 Andrew C Aitchison via mailop napísal(a):
>
> > Given that TLS encryption in SMTP is hop-by-hop rather than
> > end-to-end, I am not convinced that this is a significant reduction
> > in security.
>
> Of course, SMTP
On 14/03/2024 15:15, Matus UHLAR - fantomas via mailop wrote:
Doesn't this mean that if we disable weak ciphers and exchanges, there
are still some secure options left even with tls 1.0/1.1 ?
You'd be left with one (two-ish), ECDHE+CBC+SHA1+AES128 or AES256. CBC
being the "weakest" part in th
On 13/03/2024 16:43, Bill Cole via mailop wrote:
What is "poor" or "weak" about TLSv1.0 and TLSv1.1 which is relevant
in the context of SMTP, other than their easily-disabled support for
weak ciphers?
On 13.03.24 18:09, Taavi Eomäe via mailop wrote:
If you disable all the weak ciphers
> Of course, in some (most?) cases the target MX host will not be final
> delivery target and will forward message to some MDA, eventually over
> multiple MTAs, but i will consider that as internal thing (secured by
> some way).
> IMO in most cases it is reasonable to forget about hop-by-hop n
Dňa 14. 3. o 10:21 Andrew C Aitchison via mailop napísal(a):
Given that TLS encryption in SMTP is hop-by-hop rather than end-to-end,
I am not convinced that this is a significant reduction in security.
Of course, SMTP is hop-by-hop by design, but how important is that
hop-by-hop nowadays? Ope
>
> That's precisely the problem: As long as you don't enforce STARTTLS, you
> do not raise the bar or improve security by disabling TLS 1.0 or 1.1,
> because the least secure "protocol", namely no encryption at all, is still
> enabled.
>
Yes! I entirely agree with that!
Le jeu. 14 mars 2024 à 10
>
> Given that TLS encryption in SMTP is hop-by-hop rather than end-to-end,
> I am not convinced that this is a significant reduction in security.
>
Wouldn't it be because you assume that at some point, the security will be
either non-existent or low (TLS 1.0/1.1 or fallback to unsecured
transacti
On 14.03.2024 at 09:37 Cyril - ImprovMX via mailop wrote:
> We previously were accepting only TLS 1.2 and higher and I was surprised to
> see the amount of senders not being able to find common ciphers (I had mostly
> encounters with Cisco users), so we decided to also accept TLS 1.0 and 1.1.
>
On 13.03.2024 at 18:25 Kai Bojens via mailop wrote:
> On 2024-03-13 00:09, Andrew C Aitchison via mailop wrote:
>> Given that the advice for SMTP is often to allow tls 1.0 and 1.1,
>> rather than have it revert to unencrypted, this will is something to
>> watch out for.
> TLS 1.0/1.1 have been de
On Thu, 14 Mar 2024, Marco Moock via mailop wrote:
Am 14.03.2024 schrieb Cyril - ImprovMX via mailop :
But in my opinion, moving the needle upward by not accepting
deprecated versions would force those users to be compliant and
improve the general security.
Most of them will simply fall back
Am 14.03.2024 schrieb Cyril - ImprovMX via mailop :
> But in my opinion, moving the needle upward by not accepting
> deprecated versions would force those users to be compliant and
> improve the general security.
Most of them will simply fall back to no encryption. That is the
default setting and
We previously were accepting only TLS 1.2 and higher and I was surprised to
see the amount of senders not being able to find common ciphers (I had
mostly encounters with Cisco users), so we decided to also accept TLS 1.0
and 1.1.
But in my opinion, moving the needle upward by not accepting depreca
On 13.03.24 18:55, Slavko via mailop wrote:
> Dňa 13. marca 2024 16:32:42 UTC používateľ Andrew C Aitchison via mailop
> napísal:
>
>> Has anyone checked what traffic is still using TLS 1.0 or TLS 1.1 ?
>
> Yes, some infected machines from DZ, BR, AR, ID and so :-)
So we are removing a perfec
Dňa 13. marca 2024 18:22:55 UTC používateľ Robert Giles via mailop
napísal:
>Sort of surprising, but I don't think JPMorgan Chase (large U.S. bank) is able
>to do TLS 1.2+
Seems, that Central Europe banks are in better TLS condition ;-)
regards
--
Slavko
https://www.slavino.sk/
___
...on 2024-03-13 12:47:22, Marco Moock via mailop wrote:
> I don't see a reason for supporting older versions anymore.
Useless bit of trivia: OpenSSL 1.0.2 can do TLS 1.2
That version should be plenty backwards compatible - most of the
cleanup work that removed support for old systems and comp
On 2024-03-13 at 14:30:40 UTC-0400 (Wed, 13 Mar 2024 20:30:40 +0200
(EET))
Harald Hannelius via mailop
is rumored to have said:
Are there SMTP-"clients" that actually are able to back down from
STARTTLS and continue unencrypted?
I'm not aware of anyway to de-escalate after a STARTTLS on the
On 2024-03-13 at 14:22:55 UTC-0400 (Wed, 13 Mar 2024 13:22:55 -0500)
Robert Giles via mailop
is rumored to have said:
Sort of surprising, but I don't think JPMorgan Chase (large U.S. bank)
is able to do TLS 1.2+ from their outbound JavaMail infrastructure in
159.53.111.0/24:
I can confirm th
On 2024-03-13 at 10:56:53 UTC-0400 (Wed, 13 Mar 2024 15:56:53 +0100)
Marco Moock via mailop
is rumored to have said:
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
Without one, disabling them is a cargo-cult praxis that is worse than
any false sense of security provided to oblivi
On Wed, 13 Mar 2024, Gellner, Oliver via mailop wrote:
Sending MTAs which do not support modern crypto on the other hand are
going to fall back to a unencrypted connection as soon as you disable
older cipher suites. This allows any, even passive MITM to read and/or
modify the messages. A clai
On 3/13/2024 at 12:55, Slavko via mailop wrote:
Has anyone checked what traffic is still using TLS 1.0 or TLS 1.1 ?
Yes, some infected machines from DZ, BR, AR, ID and so :-)
I checked last 90 days log now, i found only small number of plain
text deliveries to me, but no one legitimate host wi
Dňa 13. marca 2024 16:32:42 UTC používateľ Andrew C Aitchison via mailop
napísal:
>Has anyone checked what traffic is still using TLS 1.0 or TLS 1.1 ?
Yes, some infected machines from DZ, BR, AR, ID and so :-)
I checked last 90 days log now, i found only small number of plain
text deliveries t
On Wed, Mar 13, 2024 at 05:24:37PM +0100, Marco Moock wrote:
> Am 13.03.2024 um 17:06:03 Uhr schrieb Johann Klasek via mailop:
>
> > Is it not condescending to question to reason why someone has not
> > already the opportunity to switch to TLS 1.2?
>
> Can you name some reasons?
> I currently don
On 2024-03-13 00:09, Andrew C Aitchison via mailop wrote:
Given that the advice for SMTP is often to allow tls 1.0 and 1.1,
rather than have it revert to unencrypted, this will is something to
watch out for.
TLS 1.0/1.1 have been deprecated in March 2021 (RFC 8996). Systems that
are unable to
On Wed, 13 Mar 2024, Marco Moock via mailop wrote:
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
Without one, disabling them is a cargo-cult praxis that is worse than
any false sense of security provided to oblivious peers who can't do
TLSv1.2 or better.
What are legitimate re
Am 13.03.2024 um 17:06:03 Uhr schrieb Johann Klasek via mailop:
> Is it not condescending to question to reason why someone has not
> already the opportunity to switch to TLS 1.2?
Can you name some reasons?
I currently don't know one.
--
Gruß
Marco
Send spam to 1710345963mu...@cartoonies.org
_
On 13/03/2024 16:43, Bill Cole via mailop wrote:
What is "poor" or "weak" about TLSv1.0 and TLSv1.1 which is relevant
in the context of SMTP, other than their easily-disabled support for
weak ciphers?
If you disable all the weak ciphers and key exchanges you're not left
with a sign
On Wed, Mar 13, 2024 at 12:45:08PM +, Michael Irvine via mailop wrote:
> I'm in agreement. I don't see an issue. All the largest providers are
> minimum TLS. 1.2. We have had many years to migrate.
The internet does not consist just out of the "largest provider".
Is it not condescending to
Dňa 13. marca 2024 14:43:27 UTC používateľ Bill Cole via mailop
napísal:
>Every time I see this argument, I am struck by an important question:
>
> What is "poor" or "weak" about TLSv1.0 and TLSv1.1 which is relevant
> in the context of SMTP, other than their easily-disabled support for
>
On Wed, 2024-03-13 at 15:54 +0100, Marco Moock via mailop wrote:
> Although, older SSL/TLS versions have some weaknesses and when they are
> not offered, they can't be used, not even for downgrading attacks. Many
> clients support an option to enforce TLS/STARTTLS. That will fail in
> such a situa
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
> Without one, disabling them is a cargo-cult praxis that is worse than
> any false sense of security provided to oblivious peers who can't do
> TLSv1.2 or better.
What are legitimate reasons today not to use TLS 1.2 or 1.3?
--
Gruß
Ma
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
> Without one, disabling them is a cargo-cult praxis that is worse than
> any false sense of security provided to oblivious peers who can't do
> TLSv1.2 or better.
What are legitimate reasons today not to use TLS 1.2 or 1.3?
--
Gruß
Ma
Am 13.03.2024 um 08:39:33 Uhr schrieb Michael Orlitzky via mailop:
> Whose sense of security is improved by sending those messages in
> plaintext?
None. If you want to transfer something making eavesdropping possible,
encrypt the content end to end. Everything else must be considered as
insecure.
On 2024-03-13 at 07:28:18 UTC-0400 (Wed, 13 Mar 2024 11:28:18 + (UTC))
L. Mark Stone via mailop
is rumored to have said:
> FWIW, our view is that poor encryption can be worse than no encryption, as it
> can give the participants a false sense of security. This seems like a good
> move to u
]
"Empowering Your Business Through Technology"
Original message
From: Marco Moock via mailop
Date: 3/13/24 06:51 (GMT-06:00)
To: mailop@mailop.org
Cc: "L. Mark Stone"
Subject: Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are
forcefully disab
On 13.03.2024 at 12:28 L. Mark Stone via mailop wrote:
> FWIW, our view is that poor encryption can be worse than no encryption, as it
> can give the participants a false sense of security. This seems like a good
> move to us.
> We have configured Postfix in our Zimbra MTA servers to do only TLS
On Wed, 2024-03-13 at 11:28 +, L. Mark Stone via mailop wrote:
> FWIW, our view is that poor encryption can be worse than no encryption, as it
> can give the participants a false sense of security. This seems like a good
> move to us.
>
> We have configured Postfix in our Zimbra MTA servers
Am 13.03.2024 um 11:28:18 Uhr schrieb L. Mark Stone via mailop:
> FWIW, our view is that poor encryption can be worse than no
> encryption, as it can give the participants a false sense of
> security. This seems like a good move to us.
>
> We have configured Postfix in our Zimbra MTA servers to
Stone, Founder
North America's Leading Zimbra VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs
- Original Message -
From: "Matus UHLAR - fantomas via mailop"
To: "mailop"
Sent: Wednesday, March 13, 2024 7:04:22 AM
Subject: Re: [mailop] Ubu
Am 13.03.2024 um 12:04:22 Uhr schrieb Matus UHLAR - fantomas via mailop:
> Iirc sendmail honored these settings, postfix hasn't.
8.18.1/8.18.1 2024/01/31
OpenSSL version 3.0.x is supported. Note: OpenSSL 3 loads by
default an openssl.cnf file from a location specified
On 12.03.24 23:09, Andrew C Aitchison via mailop wrote:
https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890#tls-10-11-and-dtls-10-are-forcefully-disabled-13
(which is mostly a template) suggests that TLS 1.0, 1.1 and DTLS 1.0
are "forcefully disabled" in the upcoming Ubuntu release
https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890#tls-10-11-and-dtls-10-are-forcefully-disabled-13
(which is mostly a template) suggests that TLS 1.0, 1.1 and DTLS 1.0 are
"forcefully disabled" in the upcoming Ubuntu release
(due next month at a guess).
Apparently this is not new
42 matches
Mail list logo
