[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5278DDCE.5040806@redhat.com>
Date: Tue, 05 Nov 2013 13:00:14 +0100
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: openssl default ciphers
On 11/04/2013 09:37 PM, Reed Loden wrote:
> The Mozilla opsec guys wrote up some good guidelines recently on what
> they consider a good TLS cipher suite choice should be, but even if you
> didn't want to go all-out by making the default ultra-secure (with
> full PFS, etc.), they explain their choices fairly well, so should be
> useful in trying to figure out a middle ground that makes most people
> happy.
>
> https://wiki.mozilla.org/Security/Server_Side_TLS
Personally, I find the push towards PFS rather odd. TLS with PFC is
structured in a way that PFS does not unconditionally enhance security.
Without PFC, part of the session key handshake is encrypted to the
server's public key. With PFC, the entire DH handshake is unencrypted,
and the server signs its part. This means that a potential attacker
gains another angle, targeting the DH handshake, and it also shifts the
picture somewhat as far as the server's public key operation is
concerned (decryption vs signing). There is also the possibility that
the asymmetric protection of the DH handshake is insufficient. (In this
discussion, I'm ignoring DSA server certificates in this discussion
because they are so rare.)
In short, I think it's fairly likely that PFS cipher suites offer weaker
security compared to their non-PFS counterparts. I suspect most PFS's
attractiveness stems from its spelled-out name, not its actual technical
merits in the context of TLS.
--
Florian Weimer / Red Hat Product Security Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
