ADH is susceptible to MITM attacks, but I can't seem to turn it off.
I've tried various permutations of
tls_preempt_cipherlist = yes
tls_high_cipherlist (with !DH and !ADH)
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high
I'm running 2.9.6 on Debian Wheezy.
An
Am 20.05.2014 13:03, schrieb Colin Fowler:
> ADH is susceptible to MITM attacks, but I can't seem to turn it off.
>
> I've tried various permutations of
>
> tls_preempt_cipherlist = yes
> tls_high_cipherlist (with !DH and !ADH)
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
> smtpd_tls_mandat
On 20-05-2014 12:16, li...@rhsoft.net wrote:
Am 20.05.2014 13:03, schrieb Colin Fowler:
ADH is susceptible to MITM attacks, but I can't seem to turn it off.
I've tried various permutations of
tls_preempt_cipherlist = yes
tls_high_cipherlist (with !DH and !ADH)
smtpd_tls_mandatory_protocols =
On Tue, May 20, 2014 at 12:03:29PM +0100, Colin Fowler wrote:
> ADH is susceptible to MITM attacks, but I can't seem to turn it off.
Opportunistic TLS, which is all that is possible for SMTP without
DANE (DNSSEC with TLSA records for SMTP) is vulnerable to multiple
MiTM attacks, and turning off N
* li...@rhsoft.net 2014.05.20 13:16:
> a few days ago we had a genius with troubles caused by !SSLv3
Nice one. Not really sure your slander is the result of your language skills or
you actually gain something from calling other people names. In any case you
miserably failed to elaborate how to
Am 20.05.2014 14:25, schrieb Thomas Leuxner:
> * li...@rhsoft.net 2014.05.20 13:16:
>
>> a few days ago we had a genius with troubles caused by !SSLv3
>
> Nice one. Not really sure your slander is the result of your language
> skills or you actually gain something from calling other people na
On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
> In any case you miserably failed to elaborate how to mitigate
> the issue other than stating 'revert the change'.
Without defending the tone of that advice, I'd like to affirm its
technical content. Receiving MTAs should not disab
* Viktor Dukhovni 2014.05.20 14:44:
> Most other "hardening" configuration changes are likely to reduce,
> rather than improve SMTP transport security.
Thank you for your detailed explanation Viktor!
signature.asc
Description: Digital signature
Thank you Viktor for your reply!
On 20-05-2014 13:44, Viktor Dukhovni wrote:
On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
In any case you miserably failed to elaborate how to mitigate
the issue other than stating 'revert the change'.
Without defending the tone of that advi
On 20.05.2014 15:11, Colin Fowler wrote:
> Thank you Viktor for your reply!
>
> On 20-05-2014 13:44, Viktor Dukhovni wrote:
>> On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
>>
>>> In any case you miserably failed to elaborate how to mitigate
>>> the issue other than stating 'reve
Am 20.05.2014 15:11, schrieb Colin Fowler:
> Is it not true though that allowing weak features merely
> gives the illusion of security? It could be argued that a
> weak method is technically no better than no encryption
not in reality
with no encryption at all any boy sharing the same
WLAN i
On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
> >Opportunistic TLS is sometimes counter-intuitive, attempting to
> >make it stronger by removing weaker features actually makes it
> >weaker. Don't give in to the urge to tweak TLS settings, they
> >are largely fine as they are.
> >
Thank you Viktor (and other commenters)
One of the primary reasons I use {ostfix is because of its great track
record in security (its stability, performance and feature set are also
great too). It would be foolish of me to disregard the devs who have
achieved helped give Postfix its recommend
On Tue, May 20, 2014 at 02:35:04PM +0100, Colin Fowler wrote:
> BTW, this whole thing came about from me testing using
> https://starttls.info/ which scored what I thought was a well secured server
> quite badly. I see now that the testing site is itself the problem, not my
> original config.
Yep
As the initiator of https://starttls.info/ (developed and run by Einar
Otto Stangvik), let me just say that I've e-mailed this list earlier on
this topic.
While Viktor shows very clearly why starttls by itself is insufficient
through his IETF draft, I still personally vote for disabling SSLv2 and
"Useless" and "Clueless" is rather harsh Viktor, and you most certainly
don't us what we're trying to accomplish.
Fact is we've achieved quite a lot by launching this service, several
ISPs have implemented STARTTLS, same goes for large companies and
government organisations after launch and media
On Tue, May 20, 2014 at 03:58:22PM +0200, Per Thorsheim wrote:
> I still personally vote for disabling SSLv2
Which is the default in Postfix.
> and ANON ciphers used with STARTTLS as we do today. My reasoning is simple:
And simply wrong:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with
On 20 May 2014, at 15:25, Viktor Dukhovni wrote:
> On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
>
>> I've heard anecdotes of clients not using the best mutually supported
>> encryption and instead just using whatever's first in the list of methods
>> accepted by the server. I do
On Tue, May 20, 2014 at 02:21:22PM +, Viktor Dukhovni wrote:
> Please change your site to reflect the correct risk model (opportunistic
> TLS). You should also add support for DANE, so that DANE-capable
> MTAs are not mis-identified as insecure (for example DANE-EE(3)
> certificate usage obvi
On 20.05.2014 16:21, Viktor Dukhovni wrote:
We did discuss and
change the scoring soon after the service launched, while originally
being based on the scoring system from Ivan Ristic @ Qualys at
ssllabs.com for https. Yes, perhaps stupid, but it seemed better than
creating our own scoring system.
Hi Viktor,
On Tue, May 20, 2014 at 14:21:22 +, Viktor Dukhovni wrote:
> Facebook made the same mistakes you did:
>
> http://www.metzdowd.com/pipermail/cryptography/2014-May/021344.html
In that thread you say that CA certs are futile for SMTP servers.
I think that the statement is untrue
On Wed, May 21, 2014 at 08:51:48AM +0200, David Schweikert wrote:
> Hi Viktor,
>
> On Tue, May 20, 2014 at 14:21:22 +, Viktor Dukhovni wrote:
> > Facebook made the same mistakes you did:
> >
> > http://www.metzdowd.com/pipermail/cryptography/2014-May/021344.html
>
> In that thread you s
Hi Viktor,
On Wed, May 21, 2014 at 14:09:16 +, Viktor Dukhovni wrote:
> The unstated context is "at Internet scale". I know about the
> "secure" level, after all I developed that feature for Postfix,
> while also serving as postmaster for a large company with many SMTP
> secure TLS peering re
On Wed, May 21, 2014 at 05:16:54PM +0200, David Schweikert wrote:
> > The problem with "secure" is that it requires bilateral coordination.
> > Thus O(n^2) effort for a network of size n. This cannot and will
> > not secure SMTP by default.
>
> I was wondering about the scalability of DANE, when
Hi Viktor,
On Wed, May 21, 2014 at 15:31:20 +, Viktor Dukhovni wrote:
> Yes, you benefit from "herd immunity". When one sending site defers
> mail to a destination, it is that sending site's problem. When
> everyone defers mail to a destination, it is the destination site's
> problem. Break
On Wed, May 21, 2014 at 05:44:10PM +0200, David Schweikert wrote:
> > You can use "dane" or "dane-only" per-destination if you like to
> > simplify the configuration management, no matching rules to define.
> > However, I would encourage senders en-masse to enable DANE, and
> > expect receiving sy
26 matches
Mail list logo
