I am getting this warning on mobile devices, the full warning is:
The connection uses TLS 1.2
The connection is encrypted using AES_256_CBC, with HMAC-SHA1 for message authentication and ECDHE_RSA as the key exchange.
I am using a dedicated VPS for the website and I have used IISCrypto with best practices applied.
You can see the results of the site scanner with the link below.
Qualys Scan Results
The Schannels I am using are below:
Schannel configuration
Chipher Suit Configuration
The Server is Windows 2012 r2 with IIS
Any help would be very grateful.
Paul.
To cite from the Chromium documentation what you need to do to make this warning go away:
... prioritize an ECDHE cipher suite with AES_128_GCM or CHACHA20_POLY1305. Most servers will wish to negotiate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Looking at what Windows Server 2012 R2 actually supports on ciphers you'll find that it does not support CHACHA20_POLY1305 and that it supports GCM ciphers only with ECC certificates, i.e. it implements ciphers like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 but not ciphers like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
But, you are using an RSA certificate and not an ECC certificate which means that none of the GCM ciphers supported by your OS can be used with your certificate. The ciphers you need are only supported with Windows Server 2016.
Related
Vulnerability scan shows that my server (server1821) is currently vulnerable to TLS ROBOT
Server is AIX.
How do I check for this vulnerability and how to fix this?
I checked with my vender and I got the reply as :
Does the scan report which ports are vulnerable? Those applications using TLS protocol with RSA ciphers need to be altered so they no longer use RSA. We need to do this at the application level.
Not sure about this suggestion.
The TLS ROBOT advisory site ((https://robotattack.org/) doesn't have any answers with respect to AIX.
A simple command shows this"
serverl1821 2 % cat /etc/ssh/sshd_config |grep -i rsa
#HostKey /etc/ssh/ssh_host_rsa_key
serverl1821 3 %
Can anyone help me here?
Your application vendor is absolutely correct. First of all you have to ask you security guys, where they found the vulnerability. Not only the server name, but also the port.
Then the problem may be in one of the following component:
OpenSSH
OpenSSL
IBM GSKit
Java
Every of the components requires different tuning to disable RSA ciphers.
To make it more complex every application can come with their own SSL/TLS library and their own set of settings.
The vulnerability may have nothing to do with ssh. You should update GSKit package. This is the package which implement SSL/TLS in AIX. And do not forget to restart web/application server.
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.
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.
I am experiencing a strange issue with assigning a new SHA256 certificate to an IIS web server.
The server has SSL 3.0, TLS 1.0, 1.1 and 1.2 enabled and when using a server certificate on a site signed with RSA (rather than SHA256RSA) the client connects and negotiates TLS_RSA_WITH_AES_256_CBC_SHA for the TLS encryption.
The second the SHA256 certificate is used on the site it then tries to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
What is odd is that when checking using www.ssllabs.com server test I can see that completely different ciphers are presented from the server when the SHA256 certificate is used or is not.
Ciphers Suites presented when site using SHA1 certificate.
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECHDE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WTH_RC4_128_MD5
Ciphers Suites presented when site using SHA256 certificate.
TLS_ECHDE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
I can find no information to show why this happens but I was aware TLS_RSA_WITH_AES ciphers were TLS 1.2 compatible and there seems to be no literature to state if the server certificate is SHA256 that it enforces Elliptical Curve Diffie-Hellman Exchange for the key encryption.
Can anyone explain why this might be happening?
Kind Regards
James Tighe
I have now managed to resolve this issue in case anyone else is getting it.
It seems that it is to do with the Cryptography/Key Store Provider used to request the CSR.
If the CSR is generated on the Windows Server 2008 R2 machine using a Crypto API providers (such as Microsoft Strong Cryptographic Provider) and the KeySpec is not specifically mentioned when generated the CSR it sets the KeySpec = 2 AT_SIGNATURE. The KeySpec determines whether the key can be used for Signatures, Key Exchange (encryption) or both.
When setting the Cryptography provider to a Crypto API provider seems to cause the Windows Server 2008 R2 machine to complete the request but default to KeySpec = 2 In our case it was because we had generated a .INF file to be used with CERTREQ as IIS was not able to enforce the use of SHA256 as the signing algorithm.
If the KeySpec is set in the .INF file to KeySpec = 1 AT_KEYEXCHANGE then this should work although we resolved this issue a different way.
In order to resolve the issue we changed the .INF file to set the ProviderName = "Microsoft Software Key Storage Provider" (a CNG provider). When the certificate was completed it showed the KeySpec = 0 AT_NONE which is when the key store provider is set to CNG.
This issue was raised to Microsoft to help us get a better understanding and it appears that we were right in the KeySpec behaviour and the usage of the Cryptography Provider.
They confirmed that in the .INF file (or the customer template enrolment in Cert MMC) you need to ensure the KeySpec property is set to 1 AT_KEYEXCHANGE or else it will default to 2 AT_SIGNATURE. If you use a CNG provider it will instead default to use 0 AT_NONE and will work correctly.
I hope this can help other people that might be getting this annoying issue as it was quite hard to find a solution.
Kind Regards
James Tighe