I setup my jdk provider by
Security.addProvider(new BouncyCastleFipsProvider()).
Set it in the Grpc client by:
SslContextBuilder sslContextBuilder = SslContextBuilder.forClient()
.sslProvider(SslProvider.JDK)
.applicationProtocolConfig(new ApplicationProtocolConfig(
ApplicationProtocolConfig.Protocol.ALPN,
ApplicationProtocolConfig.SelectorFailureBehavior.NO_ADVERTISE,
ApplicationProtocolConfig.SelectedListenerFailureBehavior.ACCEPT,
Collections.singletonList("h2")));
When trying to establish the connection, After successful ssl handshake I get:
UNAVAILABLE: Failed ALPN negotiation: Unable to find compatible protocol
Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
I'm using grpc 1.44 version + bc-fips.jar 1.0.2 version.
Running my app by java 11.0.15 compiled by jdk1.8.0_291.jdk.
It looks like BouncyCastleFipsProvider, by its SSLParamertesUtil class, somehow remove the "h2" from the suggested application protocols list.
increasing grpc version to 1.46 didn't help.
Any suggestions please?
Thanks.
Related
We have a MySQL task that is connecting to a 5.7.22 MySQL DB just fine in Airflow 1.10.15 using SSL (Extra: {"ssl": {"ca": "ca.pem"}} ). However, once we upgraded to Airflow 2.0.2 the task fails with (2026, 'SSL connection error: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol'). Does anyone have any ideas about this behavior?
Below are the python packages for both before and after
Airflow 1.10.15
mysqlclient==1.3.14
Airflow 2.0.2
mysql-connector-python==8.0.22
mysqlclient==2.0.3
I think the problem might be because Airflow 2 uses a newer Debian which does not support TLS v1.
I am not 100% sure how you should configure your MySQL/Client but this sounds awfully similar to MySQL ERROR 2026 - SSL connection error - Ubuntu 20.04
The solution is either to disable SSL (not recommended) or decrease security level of Debian (not recommended) or make sure that you use TLS v2
Apparently this can be done via changing your MySQL seetings and restarting it:
[mysqld]
tls_version=TLSv1.2
Server SSL Protocols: TLS 1.1, TLS 1.2 are enabled in the server
Works with REDCapR library which is using the same handshake protocol. I've verified the request headers with the fiddler tool. This proves that the server is accepting sslv3 alert handshakes successfully. I'm not sure why RCurl is failing for the same protocol.
Let me know if you need any more information. Thanks in advance!
Curl - Version 3.2,
RCurl - Version 1.95-4.11,
httr - Version 1.3.1,
openssl - Version 1.1
I'm trying to fetch the following URL via various libraries and command-line tools, but running into a SSL handshake error.
> curl https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
I've seen here it may be fixed by reducing possible ciphers, but trying this less strict call with restricted ciphers doesn't fix it.
curl -vlkL "https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts" --ciphers DHE-RSA-AES256-SHA
Any ideas how I can fix this? It's a shared account, ie no root available.
The server supports only TLS version 1.2, i.e. no TLS 1.0 or even SSL 3.0. My guess is that the curl you use is simply too old to use TLS 1.2, but without further details about the version you use this guess can not be verified.
To determine the version of curl use curl --version. If you see it is compiled with OpenSSL than it should show at least version 1.0.1 of OpenSSL to have TLS 1.2 support.
curl -vlkL ... --ciphers DHE-RSA-AES256-SHA
This is not a cipher supported by the server. One of the ciphers supported is AES128-SHA but again, no chance if your curl does not support TLS 1.2.
I'm having trouble with setting up Sentry server in HTTPS mode. Every now and then, reasonably often while seemingly random, this error message gets written by Raven (Sentry client) into log files:
Unable to reach Sentry log server: <urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol> (url: https://$(valid_server)/)
Web UI works fine. Vast majority of the messages from Raven are received fine and Sentry processes them into usable output. However, due to these errors, something gets lost from time to time.
I have tried to figure this one out, but dead ends seem to follow another. Basically it seems a lot like this:
Python Requests requests.exceptions.SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
But when testing my Sentry server with similar s_client query using TLS 1.2, it leads to a valid session unlike with the example there.
It's also not about this, since SNI isn't used:
python-requests 2.0.0 - [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
I'm not able to reproduce the error coherently. Raven's tests are passed and nothing is acutely wrong, until an error pops up in the log.
My set up is: Raven 4.2.1 in Python 2.7.5, Nginx 1.6.0 as reverse proxy handling HTTPS, and finally Sentry 6.4.4 with default Gunicorn 0.17.4. Nginx configs are pretty much similar to official documentation (http://sentry.readthedocs.org/en/latest/quickstart/nginx.html) with a few alterations due to HTTPS.
I ran into the same issue and got it fixed by installing the following dependencies:
On Ubuntu:
sudo aptitude install libffi-dev
And then via pip:
pip install pyopenssl ndg-httpsclient pyasn1
The problem seems to be that Python 2.X doesn't support SNI (which is needed for TLS) out of the box as explained here.
I read that 3.5 client should be able to connect to 4.0 server.
However, when I tried to connect, I got this log:
NX> 203 NXSSH running with pid: 4468
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: x.y.z on port: 42228
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
NX> 204 Authentication failed.
Then, I looked at:
https://www.nomachine.com/DT12I00037#3.1
It seems like 4.0 needs some setup for the authentication part. With 3.5, installing the rpm is the only step.
Any idea?
The client 3.5.0 connects to a server by SSH protocol and NoMachine login (public key authentication), while NoMachine 4 (free) supports only connections by NX protocol.
To be able to connect with NX client 3.5.0, you need to install any of the NoMachine Terminal Server or Enterprise products v. 4 that supports SSH connections.
More about this is available here: https://www.nomachine.com/AR04H00561
Alternatively, install NoMachine client (version 4) on the computer you are connecting from and use the NX protocol to connect.