How do I upgrade Ubuntu 14.0.4 to use a version of openssl that does not use sslv3?
Clash Royale CLAN TAG#URR8PPP up vote
0
down vote
favorite
I am trying to connect to an API site from a Ubuntu 14.0.4 system, using a python-based api. This API makes an https connection to the API's server (using just standard python requests calls, with parameters that lead to an invocation of the API method being called. The python code of the API cares nothing about TLS, SSH, etc. but relies on what is made available by the OS.
When I connect, following the API's documentation I get an error saying
[Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure.
Evidently, openssl is trying to use sslv3, which is NOT supported by the server I'm trying to account.
Somewhere, I saw the following as a diagnostic suggestion:
$ openssl s_client -connect bryce.cp.bsd.net:443 -tls1
This produces the same handshake failure but with a further message that
Secure Renegotiation IS NOT supported
which illustrates the nature of the problem. The first method it tries gets a handshake failure, then subsequent tries aren't made.
I think I need a newer version of OpenSSL or some way to configure the existing one which is stock OpenSSL v1.0.1f, which is very old.
It seems that Ubuntu does not provide upgrades for this package on 14.0.4. So I would have to build and install this myself.
I'm looking for advice as to the the best way to do this.
UPDATE:
I see that it's easy enough to run the make file that ships with openssl. And I see that it installs openssl into different directories than the official package. So simply installing it won't mess with what I have. But how do I tell Ubuntu to use this new version, rather than the one that it shipped with?
14.04 upgrade openssl
asked May 4 at 18:23
Steve Cohen
1013
add a comment |Â
up vote
0
down vote
favorite
I am trying to connect to an API site from a Ubuntu 14.0.4 system, using a python-based api. This API makes an https connection to the API's server (using just standard python requests calls, with parameters that lead to an invocation of the API method being called. The python code of the API cares nothing about TLS, SSH, etc. but relies on what is made available by the OS.
When I connect, following the API's documentation I get an error saying
[Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure.
Evidently, openssl is trying to use sslv3, which is NOT supported by the server I'm trying to account.
Somewhere, I saw the following as a diagnostic suggestion:
$ openssl s_client -connect bryce.cp.bsd.net:443 -tls1
This produces the same handshake failure but with a further message that
Secure Renegotiation IS NOT supported
which illustrates the nature of the problem. The first method it tries gets a handshake failure, then subsequent tries aren't made.
I think I need a newer version of OpenSSL or some way to configure the existing one which is stock OpenSSL v1.0.1f, which is very old.
It seems that Ubuntu does not provide upgrades for this package on 14.0.4. So I would have to build and install this myself.
I'm looking for advice as to the the best way to do this.
UPDATE:
I see that it's easy enough to run the make file that ships with openssl. And I see that it installs openssl into different directories than the official package. So simply installing it won't mess with what I have. But how do I tell Ubuntu to use this new version, rather than the one that it shipped with?
14.04 upgrade openssl
asked May 4 at 18:23
Steve Cohen
1013
Those error messages happen for all of the protocols up through TLS 1.2. According to Qualys, the target server only supports TLS 1.1 and TLS 1.2, so-tls1won't help you with your tests. "Secure Renegotiation" also does not indicate the lack of TLS, the core issue is the handshake failed (usually means some misconfiguration problem on their side), and also that no certificates were presented properly (again, a server side config issue), which is why it says "Secure Renegotiaton IS NOT Supported" because the TLS handshakes failed.
– Thomas Ward♦
May 4 at 18:44
Thanks. So are you telling me that the server is just misconfigured? I do not discount that possibility but I would assume that it must be connectible from some systems. There is a web page that lets me see that calls from other clients succeeded. It seems that the browsers have something installed that solves this for them. Are you saying that upgrading is a waste of time? And do you have a recommendation of what I can try?
– Steve Cohen
May 4 at 18:52
You indicate that "Secure Renegotiation" also does not indicate the lack of TLS", but I never thought it did, either on the server or my client. The error message says only that sslv3 was tried. It says nothing one way or the other about tls. I am assuming that that means that some combination of old openssl and server misconfiguration led to TLS never even being tried. I guess that fixing the server (beyond my means) or installing newer openssl could get over this problem.
– Steve Cohen
May 4 at 19:03
installing newer OpenSSL will break your system, so that's not an option (I've tried, trust me since everything relies on the SSL libraries and isn't updated to work with 'newer' library versions in 14.04, it will break everything). I would suggest trying a VM or container of 16.04 or 18.04 to see if the issue happens there as well. If it does happen in 16.04 and 18.04 then the issue is server-side and there's not much you can do to fix it regardless. I would suggest upgrading from 14.04 as well, since it will EOL next year.
– Thomas Ward♦
May 4 at 19:16
Fun fact, those error messages you see show up when you force TLSv1.2 withopenssl s_client. Interesting to note the upstream location returns a 403 Forbidden error too, so that may be part of the issue at some level. As well I would not suggest continued use of this server, because they all have F ratings due to being vulnerable to DROWN
– Thomas Ward♦
May 4 at 19:17
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am trying to connect to an API site from a Ubuntu 14.0.4 system, using a python-based api. This API makes an https connection to the API's server (using just standard python requests calls, with parameters that lead to an invocation of the API method being called. The python code of the API cares nothing about TLS, SSH, etc. but relies on what is made available by the OS.
When I connect, following the API's documentation I get an error saying
[Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure.
Evidently, openssl is trying to use sslv3, which is NOT supported by the server I'm trying to account.
Somewhere, I saw the following as a diagnostic suggestion:
$ openssl s_client -connect bryce.cp.bsd.net:443 -tls1
This produces the same handshake failure but with a further message that
Secure Renegotiation IS NOT supported
which illustrates the nature of the problem. The first method it tries gets a handshake failure, then subsequent tries aren't made.
I think I need a newer version of OpenSSL or some way to configure the existing one which is stock OpenSSL v1.0.1f, which is very old.
It seems that Ubuntu does not provide upgrades for this package on 14.0.4. So I would have to build and install this myself.
I'm looking for advice as to the the best way to do this.
UPDATE:
I see that it's easy enough to run the make file that ships with openssl. And I see that it installs openssl into different directories than the official package. So simply installing it won't mess with what I have. But how do I tell Ubuntu to use this new version, rather than the one that it shipped with?
14.04 upgrade openssl
asked May 4 at 18:23
Steve Cohen
1013
I am trying to connect to an API site from a Ubuntu 14.0.4 system, using a python-based api. This API makes an https connection to the API's server (using just standard python requests calls, with parameters that lead to an invocation of the API method being called. The python code of the API cares nothing about TLS, SSH, etc. but relies on what is made available by the OS.
When I connect, following the API's documentation I get an error saying
[Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure.
Evidently, openssl is trying to use sslv3, which is NOT supported by the server I'm trying to account.
Somewhere, I saw the following as a diagnostic suggestion:
$ openssl s_client -connect bryce.cp.bsd.net:443 -tls1
This produces the same handshake failure but with a further message that
Secure Renegotiation IS NOT supported
which illustrates the nature of the problem. The first method it tries gets a handshake failure, then subsequent tries aren't made.
I think I need a newer version of OpenSSL or some way to configure the existing one which is stock OpenSSL v1.0.1f, which is very old.
It seems that Ubuntu does not provide upgrades for this package on 14.0.4. So I would have to build and install this myself.
I'm looking for advice as to the the best way to do this.
UPDATE:
I see that it's easy enough to run the make file that ships with openssl. And I see that it installs openssl into different directories than the official package. So simply installing it won't mess with what I have. But how do I tell Ubuntu to use this new version, rather than the one that it shipped with?
14.04 upgrade openssl
asked May 4 at 18:23
Steve Cohen
1013
edited May 4 at 18:56
asked May 4 at 18:23
Steve Cohen
1013
asked May 4 at 18:23
Steve Cohen
1013
asked May 4 at 18:23
Steve Cohen
1013
1013
Those error messages happen for all of the protocols up through TLS 1.2. According to Qualys, the target server only supports TLS 1.1 and TLS 1.2, so-tls1won't help you with your tests. "Secure Renegotiation" also does not indicate the lack of TLS, the core issue is the handshake failed (usually means some misconfiguration problem on their side), and also that no certificates were presented properly (again, a server side config issue), which is why it says "Secure Renegotiaton IS NOT Supported" because the TLS handshakes failed.
– Thomas Ward♦
May 4 at 18:44
Thanks. So are you telling me that the server is just misconfigured? I do not discount that possibility but I would assume that it must be connectible from some systems. There is a web page that lets me see that calls from other clients succeeded. It seems that the browsers have something installed that solves this for them. Are you saying that upgrading is a waste of time? And do you have a recommendation of what I can try?
– Steve Cohen
May 4 at 18:52
You indicate that "Secure Renegotiation" also does not indicate the lack of TLS", but I never thought it did, either on the server or my client. The error message says only that sslv3 was tried. It says nothing one way or the other about tls. I am assuming that that means that some combination of old openssl and server misconfiguration led to TLS never even being tried. I guess that fixing the server (beyond my means) or installing newer openssl could get over this problem.
– Steve Cohen
May 4 at 19:03
installing newer OpenSSL will break your system, so that's not an option (I've tried, trust me since everything relies on the SSL libraries and isn't updated to work with 'newer' library versions in 14.04, it will break everything). I would suggest trying a VM or container of 16.04 or 18.04 to see if the issue happens there as well. If it does happen in 16.04 and 18.04 then the issue is server-side and there's not much you can do to fix it regardless. I would suggest upgrading from 14.04 as well, since it will EOL next year.
– Thomas Ward♦
May 4 at 19:16
Fun fact, those error messages you see show up when you force TLSv1.2 withopenssl s_client. Interesting to note the upstream location returns a 403 Forbidden error too, so that may be part of the issue at some level. As well I would not suggest continued use of this server, because they all have F ratings due to being vulnerable to DROWN
– Thomas Ward♦
May 4 at 19:17
add a comment |Â
Those error messages happen for all of the protocols up through TLS 1.2. According to Qualys, the target server only supports TLS 1.1 and TLS 1.2, so-tls1won't help you with your tests. "Secure Renegotiation" also does not indicate the lack of TLS, the core issue is the handshake failed (usually means some misconfiguration problem on their side), and also that no certificates were presented properly (again, a server side config issue), which is why it says "Secure Renegotiaton IS NOT Supported" because the TLS handshakes failed.
– Thomas Ward♦
May 4 at 18:44
Thanks. So are you telling me that the server is just misconfigured? I do not discount that possibility but I would assume that it must be connectible from some systems. There is a web page that lets me see that calls from other clients succeeded. It seems that the browsers have something installed that solves this for them. Are you saying that upgrading is a waste of time? And do you have a recommendation of what I can try?
– Steve Cohen
May 4 at 18:52
You indicate that "Secure Renegotiation" also does not indicate the lack of TLS", but I never thought it did, either on the server or my client. The error message says only that sslv3 was tried. It says nothing one way or the other about tls. I am assuming that that means that some combination of old openssl and server misconfiguration led to TLS never even being tried. I guess that fixing the server (beyond my means) or installing newer openssl could get over this problem.
– Steve Cohen
May 4 at 19:03
installing newer OpenSSL will break your system, so that's not an option (I've tried, trust me since everything relies on the SSL libraries and isn't updated to work with 'newer' library versions in 14.04, it will break everything). I would suggest trying a VM or container of 16.04 or 18.04 to see if the issue happens there as well. If it does happen in 16.04 and 18.04 then the issue is server-side and there's not much you can do to fix it regardless. I would suggest upgrading from 14.04 as well, since it will EOL next year.
– Thomas Ward♦
May 4 at 19:16
Fun fact, those error messages you see show up when you force TLSv1.2 withopenssl s_client. Interesting to note the upstream location returns a 403 Forbidden error too, so that may be part of the issue at some level. As well I would not suggest continued use of this server, because they all have F ratings due to being vulnerable to DROWN
– Thomas Ward♦
May 4 at 19:17
Those error messages happen for all of the protocols up through TLS 1.2. According to Qualys, the target server only supports TLS 1.1 and TLS 1.2, so
-tls1 won't help you with your tests. "Secure Renegotiation" also does not indicate the lack of TLS, the core issue is the handshake failed (usually means some misconfiguration problem on their side), and also that no certificates were presented properly (again, a server side config issue), which is why it says "Secure Renegotiaton IS NOT Supported" because the TLS handshakes failed.– Thomas Ward♦
May 4 at 18:44
Those error messages happen for all of the protocols up through TLS 1.2. According to Qualys, the target server only supports TLS 1.1 and TLS 1.2, so
-tls1 won't help you with your tests. "Secure Renegotiation" also does not indicate the lack of TLS, the core issue is the handshake failed (usually means some misconfiguration problem on their side), and also that no certificates were presented properly (again, a server side config issue), which is why it says "Secure Renegotiaton IS NOT Supported" because the TLS handshakes failed.– Thomas Ward♦
May 4 at 18:44
Thanks. So are you telling me that the server is just misconfigured? I do not discount that possibility but I would assume that it must be connectible from some systems. There is a web page that lets me see that calls from other clients succeeded. It seems that the browsers have something installed that solves this for them. Are you saying that upgrading is a waste of time? And do you have a recommendation of what I can try?
– Steve Cohen
May 4 at 18:52
Thanks. So are you telling me that the server is just misconfigured? I do not discount that possibility but I would assume that it must be connectible from some systems. There is a web page that lets me see that calls from other clients succeeded. It seems that the browsers have something installed that solves this for them. Are you saying that upgrading is a waste of time? And do you have a recommendation of what I can try?
– Steve Cohen
May 4 at 18:52
You indicate that "Secure Renegotiation" also does not indicate the lack of TLS", but I never thought it did, either on the server or my client. The error message says only that sslv3 was tried. It says nothing one way or the other about tls. I am assuming that that means that some combination of old openssl and server misconfiguration led to TLS never even being tried. I guess that fixing the server (beyond my means) or installing newer openssl could get over this problem.
– Steve Cohen
May 4 at 19:03
You indicate that "Secure Renegotiation" also does not indicate the lack of TLS", but I never thought it did, either on the server or my client. The error message says only that sslv3 was tried. It says nothing one way or the other about tls. I am assuming that that means that some combination of old openssl and server misconfiguration led to TLS never even being tried. I guess that fixing the server (beyond my means) or installing newer openssl could get over this problem.
– Steve Cohen
May 4 at 19:03
installing newer OpenSSL will break your system, so that's not an option (I've tried, trust me since everything relies on the SSL libraries and isn't updated to work with 'newer' library versions in 14.04, it will break everything). I would suggest trying a VM or container of 16.04 or 18.04 to see if the issue happens there as well. If it does happen in 16.04 and 18.04 then the issue is server-side and there's not much you can do to fix it regardless. I would suggest upgrading from 14.04 as well, since it will EOL next year.
– Thomas Ward♦
May 4 at 19:16
installing newer OpenSSL will break your system, so that's not an option (I've tried, trust me since everything relies on the SSL libraries and isn't updated to work with 'newer' library versions in 14.04, it will break everything). I would suggest trying a VM or container of 16.04 or 18.04 to see if the issue happens there as well. If it does happen in 16.04 and 18.04 then the issue is server-side and there's not much you can do to fix it regardless. I would suggest upgrading from 14.04 as well, since it will EOL next year.
– Thomas Ward♦
May 4 at 19:16
Fun fact, those error messages you see show up when you force TLSv1.2 with
openssl s_client. Interesting to note the upstream location returns a 403 Forbidden error too, so that may be part of the issue at some level. As well I would not suggest continued use of this server, because they all have F ratings due to being vulnerable to DROWN– Thomas Ward♦
May 4 at 19:17
Fun fact, those error messages you see show up when you force TLSv1.2 with
openssl s_client. Interesting to note the upstream location returns a 403 Forbidden error too, so that may be part of the issue at some level. As well I would not suggest continued use of this server, because they all have F ratings due to being vulnerable to DROWN– Thomas Ward♦
May 4 at 19:17
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1032101%2fhow-do-i-upgrade-ubuntu-14-0-4-to-use-a-version-of-openssl-that-does-not-use-ssl%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Those error messages happen for all of the protocols up through TLS 1.2. According to Qualys, the target server only supports TLS 1.1 and TLS 1.2, so
-tls1won't help you with your tests. "Secure Renegotiation" also does not indicate the lack of TLS, the core issue is the handshake failed (usually means some misconfiguration problem on their side), and also that no certificates were presented properly (again, a server side config issue), which is why it says "Secure Renegotiaton IS NOT Supported" because the TLS handshakes failed.– Thomas Ward♦
May 4 at 18:44
Thanks. So are you telling me that the server is just misconfigured? I do not discount that possibility but I would assume that it must be connectible from some systems. There is a web page that lets me see that calls from other clients succeeded. It seems that the browsers have something installed that solves this for them. Are you saying that upgrading is a waste of time? And do you have a recommendation of what I can try?
– Steve Cohen
May 4 at 18:52
You indicate that "Secure Renegotiation" also does not indicate the lack of TLS", but I never thought it did, either on the server or my client. The error message says only that sslv3 was tried. It says nothing one way or the other about tls. I am assuming that that means that some combination of old openssl and server misconfiguration led to TLS never even being tried. I guess that fixing the server (beyond my means) or installing newer openssl could get over this problem.
– Steve Cohen
May 4 at 19:03
installing newer OpenSSL will break your system, so that's not an option (I've tried, trust me since everything relies on the SSL libraries and isn't updated to work with 'newer' library versions in 14.04, it will break everything). I would suggest trying a VM or container of 16.04 or 18.04 to see if the issue happens there as well. If it does happen in 16.04 and 18.04 then the issue is server-side and there's not much you can do to fix it regardless. I would suggest upgrading from 14.04 as well, since it will EOL next year.
– Thomas Ward♦
May 4 at 19:16
Fun fact, those error messages you see show up when you force TLSv1.2 with
openssl s_client. Interesting to note the upstream location returns a 403 Forbidden error too, so that may be part of the issue at some level. As well I would not suggest continued use of this server, because they all have F ratings due to being vulnerable to DROWN– Thomas Ward♦
May 4 at 19:17