Re: HTTP2 allowed ciphers

well okay, that makes sense but even the blacklist will probably change
over time when new stuff comes in
(e.g. if the h2 blacklist would have been made before EC was a thing,
probably any EC+RC4 would have to have been added later on, or another
example, chacha/poly probably comes in the future, but nobody wants to have
anon+chacha/poly that's why it will have to get kicked into oblivion as
well)
because all combinations with RC4, MD5 other and stuff have to be avoided,
so technically it might be simpler for the blacklist to say that anything
RC4, SHA1 and so on is forbidden, also since some servers seem to have
shortcuts for that.

so TLDR:
instead of

TLS_DH_anon_WITH_RC4_128_MD5
> TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
> TLS_DH_anon_WITH_DES_CBC_SHA
> TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
> TLS_KRB5_WITH_DES_CBC_SHA
>
and so on.
just use

Key exchange:
> PSK, anon
>
> Cipher:
> RC4, DES, 3DES
>
>
Mac:
> MD5, SHA1
>
and so on.

that makes it a lot easier to consume and understand why a lot of the
ciphers are there even though they might look well at first glance.

also such a shortcutted list makes it a lot easier to read and makes the
server configs shorter meaning they can be easier to understand without
having a to check why there are 276 blacklisted ciphers and later relaizing
"oh that just the h2 blacklist"

Regards

2016-04-29 14:17 GMT+02:00 Amos Jeffries <squid3@treenet.co.nz>:

> On 29/04/2016 10:33 p.m., Philipp Junghannß wrote:
> > I have read the forbidden ciphers for HTTP2 (appendix A) which is quite a
> > long list and I think it might be intresting to see what ciphers actually
> > ARE allowed, also because whitelisting a small number of ciphers might be
> > more efficient than blacklisting everything that's listed there
> (especially
> > concidering the different naming conventions among servers.
> >
>
> The result of that test depends on your library and its age. IIRC you
> will find that AEAD, EC, DH or AES GCM based ciphers are almost the only
> allowed ones. Those are all fairly recent developments and not available
> on OS more than a few years old.
>
> (One would expect that any OS getting updated to software doing h2 is
> also capable of getting security library updates. But weirder things
> have happened in HTTP.)
>
> The blacklist set is fixed, whereas the whitelist is variable and must
> also cope with a group of not-yet-invented ciphers. Figuring out that
> variable part on the go can be a lot less efficient than using a static
> blacklist and leaving the details to the library.
>
> It is up to you how to implement of course. Just saying blacklist is
> actually the easy way. You can also shortcut the list somewhat - notice
> that CBC, RC4, etc. are common occurance on the forbidden so just making
> your software avoid old cruft will get you a long way towards compliance
> and will help with general HTTPS security as well.
>
> Amos
>
>
>