HTTPS tests fails when TLS 1.1 and 1.2 only is enabled
I saw a post back that someone suggested to use "httpst://url" but that is not working either. I am running build .17 , not sure if upgrading to .18 or .19 will work, I'll read the notes.
Is there another way to fix?
Gab
On Tue, Apr 14, 2015, at 06:47, Dito wrote:
I saw a post back that someone suggested to use "httpst://url" but that is not working either. I am running build .17 , not sure if upgrading to .18 or .19 will work, I'll read the notes.
Is there another way to fix?
From hosts.cfg man page:
- "t", e.g. httpst://www.sample.com/ : use only TLSv1
Looks like we need to patch xymonnet to let us specify TLS 1.1 and 1.2
On Tue, Apr 14, 2015, at 07:50, Mark Felder wrote:
On Tue, Apr 14, 2015, at 06:47, Dito wrote:
I saw a post back that someone suggested to use "httpst://url" but that is not working either. I am running build .17 , not sure if upgrading to .18 or .19 will work, I'll read the notes.
Is there another way to fix?
From hosts.cfg man page:
- "t", e.g. httpst://www.sample.com/ : use only TLSv1
Looks like we need to patch xymonnet to let us specify TLS 1.1 and 1.2
I may have successfully created a patch to add this behavior, but I need to do some extensive testing. Adding specific options for TLS 1.1 and 1.2 means it could break the build in environments where the OpenSSL version does not recognize these protocols. I'm not sure we want to break compatibility, although my personal opinion is that we should encourage users to upgrade in the name of security....
that's exactly what we did, disabled TLS1.0 as well and SSL, HTTPST is only TLS1.0 we'll disabled TLS1.1 soon as well... in the name of security :)
I am thinking maybe an OpenSSL script could work in the meanwhile, instead of breaking things...
Gab
On Tue, Apr 14, 2015 at 9:11 AM, Mark Felder <feld at feld.me> wrote:
On Tue, Apr 14, 2015, at 07:50, Mark Felder wrote:
On Tue, Apr 14, 2015, at 06:47, Dito wrote:
I saw a post back that someone suggested to use "httpst://url" but that is not working either. I am running build .17 , not sure if upgrading to .18 or .19 will work, I'll read the notes.
Is there another way to fix?
From hosts.cfg man page:
- "t", e.g. httpst://www.sample.com/ : use only TLSv1
Looks like we need to patch xymonnet to let us specify TLS 1.1 and 1.2
I may have successfully created a patch to add this behavior, but I need to do some extensive testing. Adding specific options for TLS 1.1 and 1.2 means it could break the build in environments where the OpenSSL version does not recognize these protocols. I'm not sure we want to break compatibility, although my personal opinion is that we should encourage users to upgrade in the name of security....
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Tue, Apr 14, 2015, at 09:01, Dito wrote:
that's exactly what we did, disabled TLS1.0 as well and SSL, HTTPST is only TLS1.0 we'll disabled TLS1.1 soon as well... in the name of security :)
I am thinking maybe an OpenSSL script could work in the meanwhile, instead of breaking things...
I enabled SSL cipher logging in my nginx webserver. It does appear to use the best cipher available by default (TLS 1.2). I now strongly suspect the OpenSSL on your Xymon server doesn't speak TLS 1.1 or 1.2. Can you provide the OpenSSL version?
example:
% openssl version OpenSSL 1.0.1l-freebsd 15 Jan 2015
oh, I run yum update all the times, and openssl is still 0.9.8e-33.el5_11
Gab
On Tue, Apr 14, 2015 at 11:00 AM, Mark Felder <feld at feld.me> wrote:
On Tue, Apr 14, 2015, at 09:01, Dito wrote:
that's exactly what we did, disabled TLS1.0 as well and SSL, HTTPST is only TLS1.0 we'll disabled TLS1.1 soon as well... in the name of security :)
I am thinking maybe an OpenSSL script could work in the meanwhile, instead of breaking things...
I enabled SSL cipher logging in my nginx webserver. It does appear to use the best cipher available by default (TLS 1.2). I now strongly suspect the OpenSSL on your Xymon server doesn't speak TLS 1.1 or 1.2. Can you provide the OpenSSL version?
example:
% openssl version OpenSSL 1.0.1l-freebsd 15 Jan 2015
yeah I didn't realize I was that behind, I took over this box and it's Centos 5.11 I have 2 more versions to upgrade
Gab
On Tue, Apr 14, 2015 at 11:43 AM, Mark Felder <feld at feld.me> wrote:
On Tue, Apr 14, 2015, at 10:41, Dito wrote:
oh, I run yum update all the times, and openssl is still 0.9.8e-33.el5_11
OpenSSL 0.9.8 doesn't know anything about TLS 1.1 and 1.2. You need a minimum of OpenSSL 1.0.1.
On Tue, Apr 14, 2015, at 10:51, Dito wrote:
yeah I didn't realize I was that behind, I took over this box and it's Centos 5.11 I have 2 more versions to upgrade
I'm not certain CentOS 5.x has a new enough OpenSSL available. It appears CentOS 6.6 may be sufficient:
$ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago)
I would also advise you to be very careful if you consider manually adding OpenSSL 1.0.1+ to your system to solve this. Multiple OpenSSL versions on an OS is very problematic; things will either start breaking silently or very loudly.
On Tue, Apr 14, 2015 at 07:50:32AM -0500, Mark Felder wrote:
On Tue, Apr 14, 2015, at 06:47, Dito wrote:
I saw a post back that someone suggested to use "httpst://url" but that is not working either. I am running build .17 , not sure if upgrading to .18 or .19 will work, I'll read the notes.
Is there another way to fix?
From hosts.cfg man page:
- "t", e.g. httpst://www.sample.com/ : use only TLSv1
Looks like we need to patch xymonnet to let us specify TLS 1.1 and 1.2
Please see the attached patch. I can successfully build on FreeBSD 8.4 and 9.3 which use OpenSSL versions that don't support TLS 1.1 and 1.2, so I'm certain I have not broken that functionality.
Considering how simple this patch is, I expect it to work reliably. Using this patch you should be able to specify httpst1_1:// and httpst1_2:// to get TLS 1.1 and 1.2
The default for https:// connections is as follows:
default:
item->sslctx = SSL_CTX_new(SSLv23_client_method()); break;
And the OpenSSL docs[1] describe this method:
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods may understand the SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.
If extensions are required (for example server name) a client willsend out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3. A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. This is the best choice when compatibility is a concern.
So I would expect Xymon to try to use TLSv1.2 if it's available... is it possible your Xymon server's OpenSSL version is too old? This might require more investigation...
Anyway, I haven't proven it beyond building yet -- I need to reconfigure my webserver to print ciphers in the logs so I can ensure it's really working. Please feel free to give it a try.
On Tue, Apr 14, 2015, at 09:11, Mark Felder wrote:
On Tue, Apr 14, 2015 at 07:50:32AM -0500, Mark Felder wrote:
On Tue, Apr 14, 2015, at 06:47, Dito wrote:
I saw a post back that someone suggested to use "httpst://url" but that is not working either. I am running build .17 , not sure if upgrading to .18 or .19 will work, I'll read the notes.
Is there another way to fix?
From hosts.cfg man page:
- "t", e.g. httpst://www.sample.com/ : use only TLSv1
Looks like we need to patch xymonnet to let us specify TLS 1.1 and 1.2
Please see the attached patch. I can successfully build on FreeBSD 8.4 and 9.3 which use OpenSSL versions that don't support TLS 1.1 and 1.2, so I'm certain I have not broken that functionality.
Considering how simple this patch is, I expect it to work reliably. Using this patch you should be able to specify httpst1_1:// and httpst1_2:// to get TLS 1.1 and 1.2
It seems that to allow mixing of schemeopts they are intended to be single characters. My new schemeopts of "t1_1" and "t1_2" are not working correctly. If I simply change them to "x" and "y" they work successfully.
I'm not sure what to do here; TLS 1.3 is on the horizon and we certainly will have more protocols in the future. I could also enable DTLS as easy as TLS 1.1 and TLS 1.2, but that's not in large demand...
I will wait for JC to chime in. With that simple modification my patch will work if someone really needs to force a TLS version.
participants (2)
-
dito74@gmail.com
-
feld@feld.me