I have a server running Rundeck to handle a large amount of various integration tasks.
The scheduled tasks each make a curl request to a given URL on our intranet system - essentially Rundeck just runs a temporary bash script.
About 99% of the time, this works fine - but we're seeing curl fail intermittently with Error 35: Unknown SSL protocol error in connection.
I've tried specifying the ssl protocol explicitly, with a known-good protocol, but we're still experiencing the issue.
We have a pretty high volume of requests going out - I'm not sure if that could have something to do with it. There is a chance we could have ~3 curl processes running at any given time.
Any advice would be appreciated.
curl --version
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
I've figured this out myself.
I ended up using wireshark to watch the communication on the server side of the SSL connection. The only anomaly I could see in the trace of the failures was that our Diffie-Hellman Public Key was 127 bytes, when typically it would be 128.
It looks like IIS didn't know how to handle this, and terminated the communication.
I'm not 100% clear on what the root cause of the issue was, but forcing a non-DH TLS cipher suite completely stopped the error messages.
Check This Article On Security.StackExchange For More Information
Related
When I try to execute this curl command :
curl -v --key some_key_file.key --cert certificate_file.pem --show-error --header "Content-Type: application/json;charset=UTF-8" https://some-api/service
I get the following error : curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
And the full execution log :
I have searched this error online and haven't found anyone explaining what it really meant.
Do you have any idea what the source cause could be ?
And do you know if there is a way to get more information about the error ?
Turns out the problem was with my curl version which, for some reason didn't accept the arguments --cert and --key.
To solve the problem, I installed a completely new curl version and ran it from the instllation folder and it worked.
Run the command from the path where you have curl package.
if you place in c:\curl goto this path and run the curl command it will work.
I also try installing latest curl (given below) but it didn't solve my issue.
curl 7.77.0 (x86_64-pc-win32) libcurl/7.77.0 OpenSSL/1.1.1k (Schannel)
zlib/1.2.11 brotli/1.0.9 zstd/1.5.0 libidn2/2.3.1 libssh2/1.9.0
nghttp2/1.43.0 libgsasl/1.10.0 Release-Date: 2021-05-26 Protocols:
dict file ftp ftps gopher gophers http https imap imaps ldap ldaps
mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli gsasl HSTS HTTP2 HTTPS-proxy IDN
IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI TLS-SRP
Unicode UnixSockets zstd
This error happens when you are behind a 7 layer firewall (i.e Palo Alto) that Allow SSL connections only via application, so you have to configure 2 rules in such solution.
Allow 443 or whatever port with higher priority
Allow Application SSL with lower priority
I'm running an nginx server with SSL enabled.
My protocol / cipher settings are fairly secure, and I've checked them at ssllabs.com, but --
-- since this is a web service which is called by http clients that I have no control over, I have concerns about compatibility.
To the point:
Is there a way to log SSL handshake failures as they happen (if they happen) in my nginx logs?
For example, I've got SSLv3 disabled, and if I try to "curl -3" (forcing SSlv3) to my server, then I get this:
NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
Cannot communicate securely with peer: no common encryption algorithm(s).
Closing connection 0 curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).
I would like to log this type of error in server logs too, with the default nginx settings, there is nothing.
Enabling "debug" log level for the error log does what I want, will log SSL handshake errors -- but unfortunately it also logs too much other stuff, making the log too bloated, drowning out other potentially useful info.
You can use the info log level.
I'm setting up a server with a couple of web services in Jboss 4.2.2. When I disable the SSL verification on the connector, all calls go through in SoapUI as well from a python script containing the same payload as the SoapUI script.
But when I enable the SSL verification with a connected keystore on the connector, all requests from SoapUI gets refused, with the following error:
Error getting response; org.apache.http.conn.HttpHostConnectException: Connection to https://1...8:2443 refused
My python-script still runs and successfully recieves the response as expected.
I have also linked the same keystore to the SSL settings in SoapUI, but without luck. I'm not familiar enough with SoapUI to know what I'm missing.
Anyone got an idea?
2443 isn't the default https connector port. Check it out on your server configuation. You can check the ports on which jboss is listening too using netstat, or directly use telnet to probe the connection.
I'm been desperately trying to get my MQTT clients to connect to a MQTT broker which is set up with a certificate from a CA. (Letsencrypt: https://pypi.python.org/pypi/letsencrypt/0.4.1) I'm using the same certificate for my https site, and that seems to work fine. I'm not sure if that holds any connection, though.
I've used this guide to set-up the certificates for the broker (http://mosquitto.org/2015/12/using-lets-encrypt-certificates-with-mosquitto/)
The broker, v1.4.8 seems to work fine with the following config:
cafile chain.pem
certfile cert.pem
keyfile privkey.pem
[ ok ] mosquitto is running.
Clients attempting to connect to this broker with debug message yields:
Client mosqsub/42074-titan sending CONNECT
On my broker's side log I recieve this error message:
1457358950: New connection from NOT.TELLING.YOU.OBVIOUSLY on port 8883.
1457358950: OpenSSL Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
1457358950: Socket error on client <unknown>, disconnecting.
I've searched high and wide for a solution to this, sadly there is little to nothing out there.
Any help would be greatly appreciated! Thank you!
I ran into this problem with the paho.mqtt.c MQTT client library when I was using tcp as a protocol instead of ssl.
So I had to use
ssl://1.2.3.4:56789
instead of
tcp://1.2.3.4:56789
Also when using paho.mqtt.c make sure you are linking against the libs with SSL support and that the libs with SSL support are actually built with SSL support! There used to be a bug in a CMake file in which a define was missing (OPENSSL) and thus the SSL libraries did not offer SSL support...
My guess is that you've not enabled TLS mode - did you pass --cafile to mosquitto_sub?
This worked for me just to test out a simple secure publish-subscribe.
I used https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh to generate the certificates (in /share/mosquitto), simply:
generate-CA.sh
I configured mosquitto.conf (including full logging) with:
log_dest file /var/log/mosquitto.log
log_type all
cafile /share/mosquitto/ca.crt
certfile /share/mosquitto/localhost.crt
keyfile /share/mosquitto/localhost.key
I subscribed (with debug enabled) with:
mosquitto_sub -h localhost -t test -p 8883 --insecure -d --cafile /share/mosquitto/ca.crt
I published with:
mosquitto_pub -h localhost -t test -p 8883 --cafile /share/mosquitto/ca.crt -m "Hi" --insecure
I started getting this issue very recently on my one of the Cloud mosquitto broker.
Im connecting to this broker from another VPS with python client and I am using paho.mqtt.client library for python.
Everything was working until one fine day it all broke. Cause might be regular updates or something else, but it suddenly started giving me handshake error and exactly same error mentioned by OP.
Client connection from AREA51 failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol.
At my client in python I am using transport=tcp and connecting to secure MQTT port using tls. This was working fine earlier. After having this issue I have updated Openssl to latest, but it could not resolve this issue.
My problem was my broker was allowing all ssl/tcp and websocket connection from all other clients. Even same Python code was working fine on my local machine.
So It was clear that something wrong with transport mechanism on my other VPS (Client)
Tapping into Python MQTT library, I found that we can try changing transport mechanism.
hence simply changing client code to :
client = mqtt.Client(transport="websockets")
which earlier was:
client = mqtt.Client(transport="tcp")
resolved my issue.
I do have to change the port in connection where my secure websocket was running.
I hope this might help someone in similar situation.
I am trying to use an SSL connection with x11vnc (VNC server) and noVNC (VNC client). Whenever I try to connect, I get the error "Unsupported Security Types: 19,18" from noVNC and "SSL: ssl_helper[2957]: exit case 2 (ssl_init failed)
SSL: accept_openssl: cookie from ssl_helper[2957] FAILED. 0" from x11vnc. If I turn off SSL for x11vnc, the client is able to connect with no problem.
I do realize that x11vnc does come packaged with a java based applet viewer. However, I'm more interested in the HTML5 based noVNC.
Both x11vnc and noVNC both run on the same machine, using the commands:
x11vnc:
x11vnc -forever -shared -unixpw_cmd [cmd] -ssl [pem]
noVNC: ./utils/websockify --ssl-only --cert=[pem] --web=./ 6080 localhost:5900
Note: Both are pointing to the same pem. I use websockify instead of noVNC's launch.sh to have more options such as --ssl-only.
The encrypt option for noVNC seems to have no effect on connecting to the server (the results are the same whether it's on or off).
I am most concerned about a secure connection. As of now, it does not seem like turning on noVNC's encrypt option does much if x11vnc's SSL must be turned off (the encrypt option makes noVNC use wss:// instead of ws://). If this does create a secure connection, please let me know. Else, how can I get noVNC and x11vnc working with SSL?
First some clarifications:
noVNC and websockify are actually separate projects:
websockify is a generic proxy/bridge that allows WebSocket connections (e.g. from a browser) to connect to raw TCP socket services (e.g. a VNC server).
noVNC is the HTML5 VNC client.
If the VNC server supported WebSocket connections then websockify would not be needed. The only VNC server that currently supports direct WebSocket connections is this fork of libvncserver. websockify is included in noVNC since most VNC servers do not yet support WebSocket clients, but websockify is a separate project.
You are dealing with two different network connections each of which has separate encryption options:
noVNC (browser) to websockify - using WebSocket protocol
websockify to x11vnc (VNC server) - direct TCP socket connection
The WebSocket protocol supports unencrypted connections (ws://) and SSL/TLS encrypted connections (wss://).
The RFB protocol (Remote Frame Buffer) used in VNC has the ability to upgrade during the initialization to use an encrypted connection. There are several encryption methods supported such as TLS (security type 18), VeNCrypt (security type 19).
Now to your question:
When you pass -ssl PEM to x11vnc this enabled RFB/VNC encryption. noVNC does not support RFB/VNC encryption. Javascript is not fast enough to do encryption/decryption fast enough to be usable for noVNC. There is some discussion about adding a crypto API to Javascript which would enable noVNC to support this type of encryption.
When you enabled encryption in noVNC you are enabling WebSocket encryption (wss://). This encrypts the connection between the browser and websockify. As long as the connection between websockify and the VNC server are over a trusted network (e.g. running both on the same server) and use WebSocket encryption in noVNC then no unencrypted data will be exposed. However, if you run websockify on the same system as your browser and the VNC server is remote then the VNC traffic from you client to the server system will not be encrypted (unless noVNC gets RFB/VNC VeNCrypt encryption support in the future).
The output from websockify will indicate whether the WebSocket connection is encrypted or unencrypted.