Safari needcerts hack catches Chrome on OSX

[andersk]

Our User-Agent match​ for the Safari needcerts hack also catches Chrome on OS X, which was not intended. In Chrome < 33, this triggers an SSL3 fallback if the visitor presents no client certificate, breaking SNI. (​Upstream bug, though davidben says it’s out of date.)

There is some question of whether the non–Safari behavior was a good idea in the first place (for less important reasons), but I’ll leave that for another ticket.

Waaah, SSL.

[davidben]

(Er, to be clear, that bug is about client auth failure and fallback conditions stomping on each other in general. The way scripts happens to set things up, it happened to be fixed by this change.

​https://code.google.com/p/chromium/issues/detail?id=326618 )

[quentin]

When testing this, I believe you'll find that the version of OS X (really, the version of Core Foundation) is relevant for this, as well as Safari vs. Chrome. So just because you can't reproduce it with a current machine doesn't mean it's not a problem on e.g. Snow Leopard or Lion.

[davidben]

I'd be very surprised if the version of OS X affected Chrome here. Chrome hasn't used the platform's SSL library for several years now.

[quentin]

Huh, okay. It sure looks like the Core Foundation client cert selector, so I thought it might be using other parts of the CF SSL stack as well.

[davidben]

Yeah, server certificate verification, the client cert selector, and the certificate and key store are all from the platform. But the SSL implementation itself is NSS with a patch to let it use platform code for client certificates and such on Windows and OS X. It used to use the platform one on Windows and OS X before that patch. (There was a brief period of amusement where it would switch SSL stacks from NSS to native when client auth was needed.)