On Thu, Jan 9, 2014, at 15:20, Henrik Størner wrote:
Den 09-01-2014 15:46, Mark Felder skrev:
[snip problem report]
I'm not comfortable with pushing this update into the FreeBSD ports tree at this time; there's too much potential for headaches. The SNI support a great feature but it seems there are some very rough edges that have not been discovered until now.
I am not quite sure what the best way forward is. As I understand your analysis (and I am very grateful that you've taken the time to investigate it!), then this really is a server-side problem that we need to provide a workaround for.
Making SNI configurable at compile-time is simple, but rather heavy-handed. I can certainly imagine situations where you want to do SNI on some servers, but have one or two where it breaks.
So it must be configurable at least per hosts.cfg-entry. Should we default SNI support to off (which it has been until now) and require everyone to explicitly enable it if they need it? Or should it default to ON and have people with the problem-servers turn it off themselves?
Defaulting to "off" would be the easiest for all users, since everything will work the way it did before 4.3.13. On the other hand, it doesn't seem right to have a perfectly valid protocol disabled, just because of some random crappiness.
I lean towards defaulting it to ON, and then asking admins to add a flag to explicitly disable SNI on those hosts that need it. As attached. Any comments?
Well I think there are a few levels of problems here. Consumers of Xymon may have wildly different experiences based on which version of OpenSSL their OS is providing or the package maintainer has targeted.
My own experience:
- 0.9.8: SNI was only causing issues with two servers. I almost feel like it would be better if SNI was off by default -1.0.0+: SNI issue was fixed, but the HTTPS check was not gracefully falling back to SSLv3. If that was fixed, it could certainly be on by default.
The difference is that I can better control the experience of FreeBSD Xymon users. I have the ability to dictate that the next update pulls in OpenSSL 1.0.0+. I think you're going to find a lot of Linux distributions still running OpenSSL 0.9.8, which may be a problem.
I think the safe solution everywhere is "off by default", and further testing of the HTTPS checking code with OpenSSL 1.0+ against servers that don't support the latest TLS, or maybe not even TLS at all -- just SSLv3. You're going to have users with appliances that can't be upgraded but they still should be able to get monitored.