Since some days ago, my MacOs/Safari client has stopped being able to access my Jupyter Notebook (placed in another server) over HTTPS.
One of the possibilities I am investigating is that Apple may have stopped accepting TLS1.0 cipher algorithms https://www.macrumors.com/2018/10/15/apple-ending-tls-1-1-1-0-support-march-2020/
When I connect to the same Jupyter server from MacOs/Firefox things DO work, but Firefox complains that I am using an insecure ciphering algorithm: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS1.0
I have confirmed "openssl ciphers -v" that my server's box accepts lots of algorithms up to TLS v1.2
How can I instruct Jupyter notebook server to use a higher version protocol?
I can see in Jupiter_notebook_config.py a section that might help:
## Supply SSL options for the tornado HTTPServer. See the tornado docs for
# details.
#c.NotebookApp.ssl_options = {}
What should I put here as ssl_options???
I can answer myself
c.NotebookApp.ssl_options={
"ssl_version": ssl.PROTOCOL_TLSv1_2
}
Solved the problem.
The solution that worked for me was:
import ssl
c.NotebookApp.ssl_options = {
'ssl_version': ssl.PROTOCOL_TLSv1_2
}
When I got back to call the jupyter notebook, it enabled the tls 1.2 and browser didn't argue about it with a valid let'sencrypt cert
Related
I'm trying to use a GRPC client which is TLS 1.3 enabled on my system (Ubuntu 20.04). I'd like to force it to connect over TLS 1.2: I don't see any options to control this, so I thought I'd try disabling TLS 1.3 system-wide.
How do I do this? I tried adding
MaxProtocol = TLSv1.2
to my /etc/ssl/openssl.cnf as this page seems to suggest*, but my GRPC traffic continues over TLS 1.3 (perhaps I'm not reloading the config or something?). I've heard mention of boringssl when it comes to GRPC as well, so perhaps that has something to do with things.
I added it as the second line, right after HOME = .: you can see the whole file here
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 find that in "SSL Report: google.com"
(P) This server prefers ChaCha20 suites with clients that don't have AES-NI (e.g., Android devices)
I tried to put all chacha20 ciphers at the beginning,doesn't work.
Then I tried to sort ciphers just like the report and it didn't work either.
How to sort the ciphers or configuration the nginx to get it?
Use boringssl to compile nginx.
Boringssl has Equal preference cipher groups
Set ciphers like below,you can get it.
ciphers [ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]
Cloudflare cdn services can also do this Cloudflare sslconfig
That's likely because you are using an nginx version that doesn't support those ciphers.
Nginx uses the ciphers implemented on OpenSSL, and Chacha20 was only implemented in OpenSSL 1.0.2, so the version of nginx that you have installed likely uses an OpenSSL version that doesn't have support for those ciphers. For example, nginx-extras 1.10.3 uses libssl1.0.0, so it doesn't support Chacha20.
You can either install a version of nginx that supports a newer release of OpenSSL, or build nginx manually to include such support, like demonstrated in this article.
My Nginx server has an SSL certificate that looks really good and works in most browsers perfectly. The server is https://live.evmote.com . You can "hit" the server by going to https://live.evmote.com/primus .
The SSL Cert check is here: https://www.ssllabs.com/ssltest/analyze.html?d=live.evmote.com
So far, so good. The problem is specifically on the Tesla Model S browser (the in-car browser). It gives a "Bad certificate" error. The Tesla browser is notoriously bad and has incomplete support. There's no way to view the cert chain or debug the problem from the Tesla. It's more like an appliance than a computer.
Here's the SSL support from within the Tesla:
http://i.imgur.com/EbIrClM.jpg
On the Nginx server, I'm getting this error in the log:
SSL3_GET_CLIENT_HELLO:no shared cipher
Now, clearly from the Tesla SSL report and the server report, there are shared ciphers. I would expect that they would handshake on this one:
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
I'm not sure how to troubleshoot from here.
Thanks,
Ryan
The error message might be misleading. What's definitely a problem is that the browser does not support SNI, but your web site requires it. At least it only serves the valid certificate (for live.evmote.com) for SNI capable browsers, all the others get a self-signed wildcard certificate which will not be accepted by a browser doing proper certificate validation.
We've hit similar problem from the Java client. The root cause was explicitly set protocols in SSL context (io.netty.handler.ssl.SslContext):
val ctx = io.netty.handler.ssl.SslContextBuilder.forClient()
...
.protocols("SSLv2Hello,TLSv1.2,TLSv1.3".split(","))
.build()
And precisely SSLv2Hello, that should be neither declared nor used here.
Unfortunately, we can't control all our clients. So further investigation showed this problem has appeared after OpenSSL upgrade to 1.1.*.
Once we downgraded OpenSSL to 1.0.* it do the trick. Nginx 1.18.0 + OpenSSL 1.0.2u could handle handshakes with SSLv2Hello without errors and with the highest protocol possible.
Is it possible to globally disable TLS 1.1 for an application that is indirectly using OpenSSL?
I would like to disable TLS 1.1 for a C application that makes soap HTTPS calls using gSOAP.
Disabling TLS 1.1 fixes a intermittent SSL connection problem I have been experiencing for the last few days (SSL routines:SSL3_GET_RECORD:wrong version number).
Currently TLS 1.1 is disabled by using a custom build of gSOAP but ideally I would like to disable the protocol using a config file or some code in my application.
Ubuntu 12.04.5 LTS
OpenSSL 1.0.1-4ubuntu5.20
gSOAP 2.8.4-2
Although there is a global OpenSSL config file it can not be used to restrict the default SSL version(s). And unfortunately there seems to be no API or configuration for the gSOAP library to restrict the SSL version. So you must probably live with your custom build version and hope that someday they provide an API to set the SSL version.
At a minimum you will need gSOAP 2.8.28. Use the SOAP_TLSv1_2 option with soap_ssl_client_context() and soap_ssl_server_context() to restrict the TLS protocol to TLSv1.2 only. TLS1.0/TLS1.1/SSLv3 are disabled. You can't combine the SSL/TLS protocol options, so only TLSv1.2 will be enabled with this option. This works with OpenSSL 1.0.1 or later and recent GNUTLS versions. Perhaps there will be new options in upcoming gSOAP releases to support subsets of protocols, which would be nice.