I confirmed that building Xymon 4.3.13 against OpenSSL 1.0.1e 11 Feb 2013 fixes my previous issues. Those two servers are no longer showing any issues.

However, I have different issue now that seems to be on a group of similarly configured servers with self signed certificates:

Error output: Unspecified SSL error in SSL_connect to 58148/tcp on host 66.170.1.42: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error Unspecified SSL error in SSL_connect to 64288/tcp on host 66.170.1.43: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error Unspecified SSL error in SSL_connect to 64288/tcp on host 66.170.1.44: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error Unspecified SSL error in SSL_connect to 64288/tcp on host 66.170.1.46: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error

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?

Regards, Henrik

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.

On Mon, Jan 13, 2014, at 2:29, henrik at hswn.dk wrote:

Den 11.01.2014 18:44, Mark Felder skrev:

...

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.

Just to finish this thread: In 4.3.14 I have implemented a global option for xymonnet "--sni=[on|off]" to globally enable/disable SNI for SSL tests. Default is OFF. In addition there are two now tags for hosts.cfg, "sni" and "nosni" so regardless of the global option you can override it per host.

I think that is the best way to avoid unnecessary surprises when upgrading, while still making SNI available for those who need it.

Thanks Henrik!