Hi, On Wed, Jun 15, 2016 at 8:12 PM, Jason Greene <jason.gre...@redhat.com> wrote: > Here is an H2 example: > > The ClientHello expressing interest in both h2, and h1, and lists the ciphers: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > So in this case the client is expressing a preference for a CBC cipher using > stronger keys, but is blacklisted by h2 due to not being GCM, but this is > allowed by h1. The JDK will follow the client hello as the TLS spec > describes, and so it will select TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, and > the protocol stack will incorrectly select h1. > > Now technically H2 clients can avoid this by ordering h2 compliant ciphers on > top, but they might not do so. > > The flaw really starts to show when you have multiple alternative protocols > with completely different requirements. As an example, if you have a > hypothetical protocol which does not perform certificate based > authentication, and instead utilizes pre-shared keys or anonymous ciphers, > that protocol can never be selected unless those algs are on the top of the > list, if they are on the top of the list then h2 can’t be selected. >
I'm not sure what you want to show here. If you want to prefer ciphers, you have to give up on protocol and viceversa, that's normal business. If there is no decision, then there is a conflict; if there is a decision, then the solution I propose works equally well to what you guys propose. There is no "flaw", it is just undecidable. What am I missing ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
