Thanks for considering the idea Tony
> On Aug 27, 2018, at 7:12 AM, Xuelei Fan <xuelei....@oracle.com> wrote: > > Hi Tony, > > I thought about to limit the workaround to TLS 1.2 and prior version. > However, just as you noticed that the implementation is not effective as it > is needed to wait and check for the supported_versions extension if it > presents. As may make the workaround a lot complicated. I would prefer to a > simple change for now. > > Thanks, > Xuelei > >> On 8/26/2018 2:35 PM, Anthony Scarpino wrote: >> The change looks fine but I have a question about restricting it. >> This sounds like a problem with servers using 1.2 or before, does it make >> sense to throw an error for 1.3? I don’t like allowing buggy implementation >> to continue because we will never be able to undo this workaround. It would >> be nice if when someday 1.2 is removed, this change won’t persist in our >> code base. I realize this maybe a lot to ask given the decision of the >> protocol version hasn’t been made yet I believe. If it’s unreasonable, that >> is ok. I’m fine with the change as is. >> Tony >>> On Aug 26, 2018, at 7:39 AM, Xuelei Fan <xuelei....@oracle.com> wrote: >>> >>> Hi, >>> >>> Please review a compatibility fix for SunJSSE provider: >>> http://cr.openjdk.java.net/~xuelei/8209965/webrev.00 >>> >>> There are servers that send the supported_groups extension in the >>> ServerHello handshake message. It does not comply to the specification. >>> However, as there are a few deployments already with the buggy >>> implementation, we may want to tolerate this behavior in JDK. >>> >>> Note that although this extension is allowed in the ServerHello, it should >>> be ignored and have no impact on the client behavior. >>> >>> The problem was reported and the fix was tested in OopenJDK: >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-August/018005.html >>> >>> >>> Thanks, >>> Xuelei
