[Ach] Vote for new Cipherstring B [Was: Issue with OpenSSL >0.9.8l]
torsten.gigler at owasp.org
Wed Jun 4 16:23:33 CEST 2014
... sorry, of course:
Perhaps it could be an idea to have a 'CipherString C' for latency Servers.
Perhaps there you could place ECDHE with higher priority than DHE, and
AES-128 higher than AES-256.
2014-06-04 16:19 GMT+02:00 Torsten Gigler <torsten.gigler at owasp.org>:
> may I suggest to write a policy how to setup the cipher string and the
> order of its ciphers.
> From the most important to the less important rule (e.g. like from Perfect
> Secrecy ... Bit len of the Hash).
> I see, that it may take a while to change chipher strings, if you maintain
> a lot of systems. So I'd prefer to include reliable ciphers that are
> planned for future use, even if they are not or rarely supported by
> browsers today (e.g. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384).
> Perhaps it could be an idea to have a 'CipherString C' for latency
> Servers. Perhaps there you could place ECDHE with higher priority than DHE,
> and AES-256 higher than AES-128.
> ... only my 2 cents...
> Kind regards
> 2014-06-04 15:24 GMT+02:00 Aaron Zauner <azet at azet.org>:
>> Hi Philip,
>> Philipp Gühring wrote:
>> > Hi,
>> > I dont't mind dropping *256, but I currently believe that SHA384 is the
>> > only secure hash in the SHA2 family, all other hashes leak their
>> > complete internal state. Length-Extension-Attack...
>> > From security point of view, I would drop SHA2-256 and SHA2-512, and
>> > promote SHA2-384.
>> > But I do not know what that means interoperability-wise.
>> There is no support for SHA384 with 128 bit symmetric ciphers in TLS:
>> So,.. keeping them is completely useless if we drop *256.
>> Ach mailing list
>> Ach at lists.cert.at
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ach