I have a C++ SSL server and a Java windows client trying to connect to it by TLSv1. (jre used is 1.6)
Through openssl command I am connecting to sever which is showing logs fine (as attached),
but when I am trying to connect through windows client ,it is throwing error.
"ciphertext sanity check fails'
Please if you can help what can be probable caused of this ?
This doesnot happen when server is TLSv1+SSLv3 enabled ,but when i disable SSLv3 this message starts coming .
Related
I have, unsuccessfully, been trying to install RavenDB 5 on a Win 2012R2 server in secure mode, however, getting error messages that are not in Raven's documentation under troubleshooting. I have seen similar errors and applied all their suggestions - they blame port numbers being blocked on firewalls (disabled firewall completely - so no luck there) or IP address binding (when I set it up in unsecure mode, it worked fine - so no luck there).
I am using the downloaded version Free Community version. I think maybe that Windows Server 2012R2 does not support TLS1.2 or there's a configuration issue
Here's the message
Setting up RavenDB in Let's Encrypt security mode failed.
System.InvalidOperationException: Setting up RavenDB in Let's Encrypt security mode failed.
---> System.InvalidOperationException: Validation failed.
---> System.InvalidOperationException: Failed to simulate running the server with the supplied settings using: https://a.******.ravendb.community:60443
---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: Authentication failed because the remote party sent a TLS alert: 'HandshakeFailure'.
---> System.ComponentModel.Win32Exception (0x80090326): The message received was unexpected or badly formatted.
--- End of inner exception stack trace ---
Besides disabling the firewall in WinServer completely (tried opening every port that may be a problem including 60443, 38888, 8080 (I know, it's not there, but), 80, 443, but that did nothing, so I disabled the firewall (bad form - yes, I know).
Since I use Let's Encrypt on IIS for a couple of other sites with other port #s and have not had any problem with auto-renewals, I figure that maybe it's a Kestrel configuration issue (so looking into this). The ambiguity of this error: HandshakeFailure could mean hundreds of different things, so it's hard to determine what.
It looks like RavenDB is running a simulation "Failed to simulate running the server" and, perhaps it's a bug on their end (perhaps LetsEncrypt does not recognize the simulation?).
Anywho, before saying to heck with this DB (which has raving reviews) and moving on to another NoSQL database like FoundationDB or CouchDB, I'd love to figure out how to secure it. It DOES WORK in nonsecure mode fine!!
Any ideas?
The issue is that Windows Server 2012R2 lacks the ciphers that are required by RavenDB.
To fix that, please make sure you enabled TLS 1.2 and add the following ciphers:
You can use IIS Crypto to add the ciphers, please see:
https://stackoverflow.com/a/63274439/11341261
Turns out, Windows Server 2012R2 does not come with the following cipher suites:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Because of this, it's not possible to use Let's Encrypt (as configured for RavenDB) on a Windows 2012R2 Server.
I have recently installed an OpenVPN service on my Google Cloud Platform (Debian 10 Server) in order to test connecting to internet on this VPN protocol. The config file that is created by the server, however, fails to connect to internet when I import it in Windows 10 OpenVPN Client that I currently use to connect to internet using other config files. During set up, I installed ufw firewall and chose a password-less user and UDP connection according to a search in Google. Anyways, the config files that I have created this way all fail to connect from Windows returning a "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)" as noted in the log.
Does this TLS error mean my Windows client can't reach the server due to some wrong permission/firewall settings on the server side (I have already allowed OpenVPN Client for Windows on my firewall on my Windows client)?
What changes should I make to the OpenVPN set up during installation on the server to make it work? Any suggestions?
Thanks in advance.
I'm trying to access an SSL URL from a Windows browser to another machine running Tomcat and I am seeing error 36887 from Schannel in the System event log on the Windows machine with this description:
The TLS protocol defined fatal alert code is 70
According to MS documentation:
I've turned up Schannel logging (max=7) on the Windows machine and I can see that an SSL handshake was negotiated correctly, this from the event log:
An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.
Protocol: TLS 1.2
CipherSuite: 0xC028
Exchange strength: 256
This seems to contradict the code 70 error.
Cipher suite 0xC028 is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. I've checked on the Tomcat machine and can see that this is available, and TLS1.2 is also enabled on both machines so the successful handshake makes sense.
The process ID associated with the code 70 error belonged to lsass.exe - my Windows knowledge is quite limited so I have no idea what that does.
I can find nothing in the catalina.out log on the Tomcat machine, the code 70 seems to be happening before the request is actuall sent. I am certain that the certs are all configured correctly as I can access the URL successfully from other machines.
How can I progress from here?
The issue turned out to be that one of our client apps was using .NET 4.5.2 and defaulting to TLS1.1, which had been disabled at the server end by some patching. Ultimately a .NET update to 4.7.2 fixed the issue.
It means communication with the server was attempted using a recognized but unsupported TLS version. If your server is set to accept only communications using TLS 1.2 or newer, for example, then anything that tries to communicate via TLS 1.1 or lower will throw this error.
Two computers have to agree on a method of communication before they can actually do the communication. That is why this error message can occur and then the computers appear to communicate just fine... the first method was tried and rejected, and then a newer one was tried and succeeded, that's all.
I have a website using tls1.2,1.1 and 1.0(ssllabs) . I am using websense proxy to access it. Have enabled tls1.1 and tls1.2 on the WCG. I am still getting Peer disconnected error. The website worked once and is giving the error randomly. I have websense 8 and the URL in question is https://rem2.piiapps.com/site/login. It works fine with websense 7. I dont have a ssl bypass option due to security restrictions. Sometimes the browser indicates that the certificate is broken and sometimes it is healthy.
I did some analysis and found that this URL was using a real time communication protocol which is not supported by deafult in websense. It has to be tunneled in the incident list.
We are facing a problem and I am sure this is the right place. We have a load balancer (cisco's) and for various reasons the SSL configuration on the load balancer (the server) side is set to use "SSLv3" protocol version. Now after setting the same, when I access the load balancer in CHROME browser, I am able to access the pages but I do see the below message when I click on their security icon.
"connection had to be retried using ssl 3.0" - I looked at the packet capture using wireshark and I see that browser tries TLSv1 and receives a "fatal alert" from the server saying "protocol_version" and then immediately browser tries SSLv3 version and finishes the handshake. So browser is able to negotiate this as a client.
However when I set up a stand alone java (tried using 1.6 as well as 1.7) client from eclipse and try connecting to the server I am getting the below exception.
: Received fatal alert: protocol_version javax.net.ssl.SSLException: Received fatal alert: protocol_version
As per various documentations, I saw two options I have
to set https.protocol system property to SSLv3. [this works for us, but the problem is it is affects the outbound SSL calls globally. I have another outbound SSL call to another server which does not work with SSLv3]
setEnabledprotocols() - this works as well but sometimes, we dont have access to the socket directly (sometime we generates stubs using third party and the stub takes care of the low level connection stuff, so no access to that socket).
But my actual question is, If by default TLSv1/SSLv3 and SSLv2Hello(just the format I believe) are enabled in java, why is JSSE implementation not able to negotiate like how chrome browser is able to negotiate. Is this expected? If browser is doing it, I believe it should be part of some SSL RFC and if that is the case, same functionality of this "negotiation" should be provided by java itself right?
I did go through this http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java and was not able to find any part for this negotiation during handshake.
Is there a possibility of issue from the server side (load balancer) that i. I see that server sends fatal alert but that being cisco I believe the ssl implementation should be perfect and that is expected. Am I wrong?
Issue happens both in java 1.6 and 1.7. Do let me know if more information would be required to answer, will be happy to help.