Subject: [websec] On CIPHER-SUITE pinning

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sat, 7 Dec 2013 14:31:29 +0000

Hi,

To let old browsers connect to a host most hosts will support
weak or broken ciphers for the forseable future.

A feature to pin the CIPHER SUITE would be desirable.

It would allow a client to learn a set of 'strong' ciphers available
on client and host side. Any downgrade attack to a weaker cipher
would fail.

This feature could be optional or mandatory to be configured on the host.

Please discuss. Opinions welcome.

regards,

ralf

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sat, 7 Dec 2013 15:06:36 +0000

Hi,

On Sat, Dec 7, 2013 at 3:01 PM, Tobias Gondrom
<[email-masked]>wrote:

>  Hi Ralf,
>
> trying to understand what functionality you are seeking.
> Should this be:
> a) only a pinned "announcement" of the supported cipher suites on the
> server or
> b) "enforced" on the server?
>

That is open for discussion. My personal preference is that server
announces a set of 'STRONG' ciphers
to the client. The client will fail to connect on future connections if
none of the announced ciphers is no
longer available (downgrade attack under way).

>
> In case of b) would this mean that the server fails any insecure cipher
> connection attempts.
>
> Best regards, Tobias
>
>
> Ps.: btw. on a personal note: I found that the underlying paradigm we had
> in browser web servers of "weak encryption would be better than no
> encryption" from back in the day of weak algorithms due to export
> regulations in the US is part of or even the root of the problem. IMHO this
> allows the downgrading attacks. In my view we should on server side shift
> to a paradigm of "either strong encryption or no encryption at all".
>

I'm with you on this one. The big corporates who value their customers
(including the 5% still using SSLv2/v3) are not. Currently the 95% of users
are taking a security hit to let the 5% of all users still connect to the
websites. It will be like this for the foreseeable future :/

regards,

ralf

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Sat, 7 Dec 2013 16:43:49 +0000

On Sat, Dec 7, 2013 at 3:21 PM, Tobias Gondrom
<[email-masked]>wrote:

>  On 07/12/13 15:06, Ralf Skyper Kaiser wrote:
>
> Hi,
> [...]

>
> Maybe one question: as the browser already has the information about all
> cipher suites offered in a TLS connection and could possible cache this
> information from previous connections already without pinning. Would
> pinning this via an http header or file add much value over this?
>
> What do you think?
>
>
My feeling is that the server should announce to the client that
CIPHER-SUITE-pinning is supported. The client should only pin the cipher
suite if it has been announced by the server (similar to certificate
pinning).

Using the cache to determine which cipher to use might not be sufficient.
The ServerHello only contains 1 cipher that the server picked from the
ClientHello. In this case the server admin would have no chance to upgrade
to a stronger cipher.

Instead the server should send a list of 'preferred strong ciphers' to the
client. If the client (TLS connection) is not using any of these ciphers
then the connection should fail.

If the client uses one of these ciphers then the client should pin the
'preferred strong cipher' list. The pinned list should be updated on every
successful connection.

For future communication the client should fail the connection if the
negotiated TLS cipher is not part of the pinned ' preferred strong cipher'
list.

This would allow the server admin to add new and stronger ciphers to the
list and slowly remove old or broken ciphers.

regards,

ralf

---

From: Adam Langley <[email-masked]>
Date: Sat, 7 Dec 2013 12:55:02 -0500

> A feature to pin the CIPHER SUITE would be desirable.

What attacks do you believe will be prevented by this? TLS has cipher
suite negotiation so weak ciphersuites will only be used if it's the
best that the client and server support.

TLS negotiation can be somewhat subverted by version fallback, as
implemented in browsers, because certain cipher suites depend on a
minimal TLS version. (I.e. AES-GCM needs 1.2 and ECDHE suites need 1.0.)

However the solution to that is to solve fallback issues. We've tried
just requiring certain TLS versions for servers that we know support it
and that didn't work because there are lots of buggy MITM boxes. So I'm
trying an SCSV now:
https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Sat, 7 Dec 2013 16:17:09 -0500

On Sat, Dec 7, 2013 at 4:10 PM, Tobias Gondrom
<[email-masked]> wrote:
> I am not sure that the main mechanism of the ID of merely "the client
> indicating that the current connection attempt is only a fallback" is
> sufficient to protect against downgrading. It could help a little, but
> is potentially limited, as evil MitM boxes can potentially strip out
> parameters from the requests.
> E.g. Moxie's SSL strip tool does already strip out various http headers,
> secure cookie flags, etc.
> Having said that, I can still see that scsv could be useful.
> Just my 5cents, Tobias

An SSL MITM (i.e. one with a valid certificate for the site in
question) can certainly still implement downgrade. But, if it has a
certificate for the site in question, then it can do anything it wants
really.

A MITM without a valid certificate can tweak the ClientHello, but the
hash of the handshake is verified by the Finished messages and so any
changes will be discovered.

SSL strip certainly still works in the same way that it always has: by
avoiding TLS completely. But we already have HSTS to address that.

Cheers

AGL

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 07 Dec 2013 21:10:29 +0000

> https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01

Hm, just a quick thought:

Ps.: IMHO the benefit of pinning would be that once you have the pin,
your browser is resistant to downgrading as it _knows_ that stronger
versions/algorithms are in fact available. It might actually even be
worthwhile considering to have both scsv and pinning in tandem.

>
> Cheers
>
> AGL
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 07 Dec 2013 15:21:47 +0000

On 07/12/13 15:06, Ralf Skyper Kaiser wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Ralf,
>
>     a) only a pinned "announcement" of the supported cipher suites on
>     the server or
> to the client. The client will fail to connect on future connections
> if none of the announced ciphers is no

I see your point. Like a "soft migration" patter for strong clients,
while keeping old browsers accessible.
I understand that this would only be enforced on the client and not on
the server (noting your comment at the end). So, it is worth noting that
this would still have some residual risks with all the old browsers and
expired pins (which may be acceptable).
Pinning this information in the browser could indeed help against a
number of attack vectors in face of corporations unwilling to shut down
the old algorithms / versions. 
As mentioned the procedure of pinning itself could be achieved
relatively easy.

What do you think?

Cheers, Tobias

>
>  
>
>
>     In case of b) would this mean that the server fails any insecure
>     cipher connection attempts.
>
>     Best regards, Tobias
>
>
>     Ps.: btw. on a personal note: I found that the underlying paradigm
>     we had in browser web servers of "weak encryption would be better
>     than no encryption" from back in the day of weak algorithms due to
>     export regulations in the US is part of or even the root of the
>     problem. IMHO this allows the downgrading attacks. In my view we
>     should on server side shift to a paradigm of "either strong
>     encryption or no encryption at all".
>
>
> (including the 5% still using SSLv2/v3) are not. Currently the 95% of
> users are taking a security hit to let the 5% of all users still
> connect to the websites. It will be like this for the foreseeable
> future :/
>
> regards,
>
> ralf
>

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 07 Dec 2013 15:01:19 +0000

Hi Ralf,

Best regards, Tobias

Ps.: btw. on a personal note: I found that the underlying paradigm we
had in browser web servers of "weak encryption would be better than no
encryption" from back in the day of weak algorithms due to export
regulations in the US is part of or even the root of the problem. IMHO
this allows the downgrading attacks. In my view we should on server side
shift to a paradigm of "either strong encryption or no encryption at all".