If you're fixing that then maybe standardising the errors makes sense too. My fingerprinter sees the following:
For an empty name: SNIEmptyName: *(301)alert:DecodeError:fatal| SNIEmptyName: *(301)alert:HandshakeFailure:fatal| SNIEmptyName: *(301)alert:IllegalParameter:fatal| SNIEmptyName: *(303)alert:UnexpectedMesage:fatal| SNIEmptyName: error:Unexpected EOF receiving record header - server closed connection| For a long name (x repeated 500 times): SNILongName: *(301)alert:HandshakeFailure:fatal| SNILongName: *(301)alert:IllegalParameter:fatal| SNILongName: *(301)alert:UnrecognizedName:fatal| SNILongName: *(303)alert:UnexpectedMesage:fatal| SNILongName: error:Unexpected EOF receiving record header - server closed connection| Rich. On 3 March 2016 at 22:44, Martin Thomson <martin.thom...@gmail.com> wrote: > On 4 March 2016 at 05:49, Adam Langley <a...@imperialviolet.org> wrote: > > (I think the lesson here is that protocols should have a single joint, > > and that it should be kept well oiled. For TLS, that means that > > extensions should have minimal extensionality in themselves and that > > we should generally rely on the main extensions mechanism for these > > sorts of things.) > > Big +1 > > Note that the NSS bug also entailed non-zero SNI name types > overwriting the actual SNI. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
