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
Related
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
I have configured a ListenHTTP 1.7.0 processor in NiFi 1.7.0-RC1. It is listening on a custom port behind a reverse proxy. I have configured a StandardRestrictedSSLContextService with a JKS keystore and have added the keystore password. We have not configured the truststore as we don't expect to need mutual TLS. The certificate is signed by an internal enterprise CA and is (or should be!) trusted by the client.
When I test this with Chrome I receive the following:
This site can’t provide a secure connection
my.server uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
Troubleshooting:
We have tried both TLS and TLSv1.2 in the ListenHTTP processor.
We have treid using curl (Linux) and Invoke-WebRequest (Windows) but have received variations on the bad cipher/SSL version message above.
I don't see anything in the release notes suggesting that the ListenHTTP processor changed much since 1.7.0, so I'm assuming that I don't need to upgrade NiFi.
Can anyone suggest what to try next or explain why we see this error?
I have read the following:
https://www.simonellistonball.com/technology/nifi-ssl-listenhttp/
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes
Nifi: how to make ListenHTTP work with SSL
What version of Java are you running on? Java 11 provides TLSv1.3, which is the default offering if you have generic TLS selected, but NiFi 1.7.0 doesn't support TLSv1.3 (and doesn't run on Java 11). So assuming you are running on Java 8, recent updates have introduced TLSv1.3 but should still provide for TLSv1.2. This can also indicate that the certificate you have provided is invalid or incompatible with the cipher suite list provided by the client. You can use $ openssl s_client -connect <host:port> -debug -state -CAfile <path_to_your_CA_cert.pem> to try diagnosing the available cipher suites & protocol versions. Adding -tls1_2 or -tls1_3, etc. will restrict the connection attempt to the specified protocol version as well.
You should definitely upgrade from NiFi 1.7.0 -- it was released over 2 years ago, has known issues, and there have been close to 2000 bug fixes and features added since, including numerous security issues. NiFi 1.12.1 is the latest released version.
I have 100 HTTPS services running on a single server using SNI. (Actually, I don't have access to them. It's an assignment. All I know are their domain names N.xxx.yy where N is in range from 00 to 99.) The goal of the assignment is to evaluate security of every single connection to each of these servers. So some of the servers contain expired certificates, certificates with wrong CN, etc.
My problem is that I cannot get past the handshake on some of the servers. I have written my own application in C++ using OpenSSL, but I've also tried it with openssl s_client. This is how I connect to the server:
openssl s_client -host N.xxx.yy -port 443 -verify 1 -servername N.xxx.yy -CAfile assignment-ca.pem
And this is what I get:
139625941858168:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:s3_pkt.c:1493:SSL alert number 80
139625941858168:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
In Wireshark, I see that client sent ClientHello, server responded with ServerHello (choosing TLSv1.2 and ECDHE-RSA-AES256-GCM-SHA384) followed by Certificate and then it sent me Alert message containing Internal Error (80).
After trying different thing I have found out that if I run s_client with -tls1 or -tls1_1 I can successfully get past the handshake. -tls1_2 does not work. What is even stranger is that connection through Chrome/Firefox/any other browser succeeds even if TLSv1.2 is negotiated. From what I see, Chrome is sending a different cipher list than me or s_client but even after modifying the cipher list to match the one in Chrome (and making sure that server chooses ECDHE-RSA-AES128-GCM-SHA256), it does not work either. Chrome is sending these TLS extensions, which I don't but most of them seem empty:
Unknown 47802
renegotiation_info
Extended Master Secret
signed_certificate_timestamp
status_request
Application Layer Protocol Negotiation
channel_id
Unknown 6682
Can anybody explain me what is happening here? Unfortunately, I have no way to debug it on the server side so this is all I know.
UPDATE:
After playing around with forged ClientHello messages I managed to track it down to signature_algorithms extension. My app and s_client provide SHA384 + {RSA,DSA,ECDSA} but if I remove these and keep just SHA256 + {RSA,DSA,ECDSA}, as Chrome does, it works and I receive Server Key Exchange message successfully. Could it be that server somehow does not support it, but instead of providing meaningful error message, it just ends unexpectedly and gives me this internal error?
UPDATE 2:
I found answer to why it works with TLS versions prior to 1.2 in RFC5246. Question from the previous UPDATE still holds.
Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand.
Since you wrote that -tls1_2 does not work I assume either you and/or the server uses an older openssl library. The current version while writing this is 1.1.0e
There were quite some fixes since 0.9.8, which could often be seen on older systems.
For Version 1.0.1 there was this fix, which sounds like your problem:
`Some servers which support TLS 1.0 can choke if we initially indicate
support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA
encrypted premaster secret. As a workaround use the maximum permitted
client version in client hello, this should keep such servers happy
and still work with previous versions of OpenSSL.`
Maybe also notable:
Don't allow TLS 1.2 SHA-256 ciphersuites in TLS 1.0, 1.1 connections.
So I would suggest to update your openssl-Version and in case of the servers out of your control I would stick to the settings you already found.
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.
I'm having some problems getting openssl to consistently connect to some websites. pnc.com seems to have the problem almost every time. When I run the following command:
openssl s_client -bugs -msg -debug -connect www.pnc.com:443
The first time I will always get the following response:
CONNECTED(00000003)
write to 0x1095fa0 [0x11362d0] (112 bytes => -1 (0xFFFFFFFFFFFFFFFF))
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
If I run it a couple more times it will successfully connect and I can run a GET for the specific web site I'm looking for, but the connect never works on the first try. I've seen several posts with similar issues that have been solved by specifying SSLv3, or using the no_tls1_2 option, but neither of those have worked in this case. I have tried this from both a centOS box as well as my macbook, and using both openssl 1.0.0 and 1.0.1e.
I chased the problem to openSSL after initially suspecting it was the ssl_bump from my squid install. All I really need is for the webpage to open properly through the squid ssl_bump, so if I could get openSSL to connect properly the first time, or keep retrying until it was successful, or get squid to keep trying until the connection is established, I'd consider it working.
Has anyone else had this problem and found a solution for it?