bcgit/bc-java — pull request #100 by sake (2014-12-10 14:51:35+00:00)
Title: Modify ServerHello check to not fail when a named_curve extension is received by the TLS client

We found a server (https://www.eservice-drv.de) which is not able to communicate with the BC TLS client because it sends the named_curve extension in its ServerHello message as you can see in the following picture.

![serverhello](https://cloud.githubusercontent.com/assets/154311/5377440/5cd61b6e-8082-11e4-871b-6bc1265c416b.png)

It is clear that this behaviour of the server is not very good with respect to RFC 4492, which states in sec. 5.2 that the ServerHello must contain the ECPointFormat extension, but does not mention the named_curve extension. However RFC 5246 states in sec. 7.4.1.4: An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello.
In my interpretation that means it is forbidden that named_curve appears in the ServerHello message if it is not in the ClientHello message, but it is not forbidden to send it there.

You can also observe that a lot of other clients accept this sloppy behaviour of the server. I tested with FF and Chrome. I also found a bug report for the load balancer F5 (propably the one in front of the problematic site) where they mention a patch for GnuTLS adding support for this.
https://devcentral.f5.com/questions/disable-supported-elliptic-curves-extension-from-server

To sum it up, in my interpretation of the RFCs it would be ok to accept the extension in case it has been sent in the ClientHello.

A note to the change. I suppose it would be better to compare each sent extension against the ones received and name explicitly forbidden extensions in the processServerExtensions function. But the sent extensions are not available in the AbstractTlsClient. A bigger change possibly with API changes would be needed for that. If that is desireable I can make a proposal.