Has anybody seen "httperf: connection failed with unexpected error 0" when running httperf with --ssl?
This is blocking my test on that domain. When I tested --ssl on https://google.com it worked fine.
On the other end of my "problematic" domain there is ELB, forwarding calls to heroku.
On my workstation: OSX 10.9.5 and httperf-0.9.0 (via brew)
I had the same issue, by looking at NGINX logs it turns out the SSL handshake fails because SSLv3 is disabled server side.
The project seemed a bit dead so I modified this file at line 924 :
I replaced SSLv3_client_method() with TLSv1_client_method()
Then the usual compilation stuff configure-make-install. Be sure to have openssl on your build machine.
Source : https://www.openssl.org/docs/ssl/SSL_CTX_new.html
The answer by #oto turned out be related to my fix as well. Basically, we stopped using SSLv3 on our server (and, apparently, all other ssl protocols used by httperf) due to the POODLE vulnerability, and httperf uses SSLv3, so it fails to connect.
Until they update httperf there seems to be no easy way around this. One way to fix it is to change from SSLv3 to TLSv1 by hand, as mentioned in the other answer.
I found this patch pull-request on GitHub. It changes the code so you can specify the ssl protocol with a flag, so I could force using TLSv1 instead of SSLv3.
For both fixes you will need to download the httperf source code, make the changes (like applying the patch), and then compile. I cloned the source from GitHub, so I had to run the autoreconf -i command before running make, but the instructions are pretty good. I had to use commit ed5c631 since the latest commits appear to be broken.
Related
I'm trying to hit an https endpoint to pull back some data using common-lisp(sbcl). For a while this worked without issue. Then one day I started receiving the following error
SSL error queue:
error:0A000152:SSL routines::unsafe legacy renegotiation disabled
[Condition of type CL+SSL::SSL-ERROR-SSL]
I've tried using both drakma and dexador, but see the same error from both. I've confirmed through openssl that the server I'm trying to connect to does not support renegotiation.
From openssl s_client -connect
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
I'm on OSX and my open ssl version is LibreSSL 2.8.3.
So to my understanding my client is trying to initiate renegotiation, but the server is rejecting it. I don't really know where to go from here and at this point I'm not even sure what level the problem is truly at, openSSL, CL+SSL, or the http client libraries built on top of CL+SSL. Is there some way to disable renegotiation, or force a new connection? Is there some setting I'm missing?
In Openssl 1.1.1, the SSL_OP_LEGACY_SERVER_CONNECT flag was turned on by default, but
It is turned off by default as of Openssl 3.0.0.
check the article below
SSL_CTX_set_options(ssl_ctx, SSL_OP_LEGACY_SERVER_CONNECT);
https://www.openssl.org/docs/man3.0/man3/SSL_clear_options.html
0-RTT doesn't work when secp384r1 is the only one enabled in a server with TLS.
I am using OpenSSL:
This happens in:
Apache with my own 0-RTT implementation (still in progress)
NGINX
If I add another curve to the list, like secp384r1:prime256v1 or secp384r1:X25519: 0-RTT starts to work.
By not working, I mean, when I connect to the server using s_client in OpenSSL, it says that Early data was rejected, but if I enable another curve like the ones mentioned above: I get Early data was accepted.
I am unable to find about this anywhere online except this https://trac.nginx.org/nginx/ticket/1969
The PHP version on my webserver was recently updated. Now I notice that when downloading external https URLs with Curl, for one specific server it fails, giving me this error:
SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Downloading https stuff from this server though Curl worked fine before.
Now the strange this is: it seems an SSL3 error, but as I understood from other cases regarding this error (also here on SO) it's due to SSL3 no longer being supported by updated versions of PHP or Curl. And rightly so, since SSL3 is insecure.
However, this particular webserver uses TLS1.2, and by no means SSL3.
So if my Curl is not using SSL3, and neither is the webserver, why am I still getting SSL3 related errors?
I already tried setting CURLOPT_SSLVERSION to 4, 5 or 6, and setting CURLOPT_SSL_CIPHER_LIST to TLSv1, all to no avail, error keeps coming up.
Although this error message looks like it is using SSL 3.0 it is probably not. Since TLS1.0 is practically SSL3.1 etc you will find lots of functions and error messages having the SSLv3 string within the TLS code path in OpenSSL. The problem with this specific server is probably something else and one would need to know the server hostname and your installed version of OpenSSL to find out more about the problem.
EDIT: Based on the comment the version of OpenSSL used with curl is 0.9.8b. Since the server can only do TLS 1.2 the handshake will fail, since TLS 1.2 is only supported since OpenSSL 1.0.1. Apart from that 0.9.8b is years out of support and has several security problems which got fixed in later versions.
Since a week or so I'm having a SSL problem on my Nginx server intermittently.
I know there are a few other topics on this problem on stackoverflow but none of those answers seem to apply
1 Its a real problem because when I'm working on the site it just suddenly dies on me and gives me SSL error in Chrome (Version 44.0.2403.155):
SSL connection error
ERR_SSL_PROTOCOL_ERROR
And it happens on FF as well.
2 Server isn't running out of memory (no sign of OOM ran and top all seems ok as well)
3 No updates available for either Nginx (1.8.0) or OpenSSL (OpenSSL 1.0.1e 11 Feb 2013) running on Debian (7.8)
4 I do not have any special 3rd party libraries installed (just the standard nginx, mariadb, php via fpm setup no email server)
My log has these entries:
[crit] 15592#15592: *317414 SSL_do_handshake() failed (SSL: error:1408A0D7:SSL > routines:SSL3_GET_CLIENT_HELLO:required cipher missing) while SSL handshaking,
Server has NTP installed to make sure server time is in sync (right?).
When I experience the problem and give it a few minutes and reload the page it works again but it keeps happening. It doesn't seem to be happening often to other people looking at my logs.
The solution I ended up with:
I had multiple server blocks using the same SSL cert for a few special subdomains and removing that solved the problem completely..
So basically it seems I can only use the CERT in one block (even though its a wildcard cert).. I think the problem is not with the cert but with Nginx accessing the CERT files or something. Using the cert or a regex for multiple subdomains did work (so having only 1 server block with the cert but then defining the domain as *.domain.com)
You could try and look into this to solve it.
https://forum.nginx.org/read.php?2,256373
I use a Tcl script to pull from several API's and all of a sudden some API's stopped working. eg:
set data [http_call_get https://api.vineapp.com/timelines/popular?page=1&anchor=1]
responds with the error:
SSL Channel "sock624": error: sslv3 alert handshake failure
It's odd that two of the five API's from different sites stopped working within an hour or each other so I feel that something changed with the compatibility of the tls1.6.3.1 tcl package which binding with "::http::register https 443 ::tls::socket"
I've tried on three different machines (2 x Windows and a ubuntu box).
The sites you are attempting to connect to have probably disabled sslv3 due to the poodle vulnerability.
I would guess your tcl script needs to use TLS instead.