We have a WinServer 2019 machine that needs to make REST requests to a third party using TLS1.2 and Cipher Suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. From what I've read, this suite should be enabled by default for this OS version, however, when we make the REST call with Schannel logging enabled I see that it's using CipherSuite: 0xC028 which corresponds to TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (CBC vs GCM). In PowerShell I've tried running Enable-TlsCiphterSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" -Position 0 and this does add it to the value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\Functions. Though, when I run Get-TlsCipherSuite in PowerShell the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 suite that was supposedly enabled does not show up.
Is there another place that needs to be changed in order for this cipher suite to be truly enabled?
The simplest way to achieve this would be downloading a copy of IIS Crypto.
From there you can select the cipher suites tab, enable your chosen cipher and move it to the top as the preferred cipher.
Be aware that some clients may fallback to a weaker cipher if it is available.
Related
I am investigating FIPS compliance for our platform. nginx is one of the components and we use nginx 1.15.1. I found the documentation about nginx plus being FIPS compliant.
When NGINX Plus is executed on an operating system where a FIPS‑validated OpenSSL cryptographic module is present and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 with respect to the decryption and encryption of SSL/TLS and HTTP/2 traffic.
https://docs.nginx.com/nginx/fips-compliance-nginx-plus/
Does this apply to open source nginx as well? I did not find any documentation for the open source version. I have posted the query in nginx forum as well but checking it here as well in case folks have already done FIPS compliance with the open source version.
According to this blog post, it's not a "No" but more of a "We can't be sure" (emphasis mine):
NGINX tests and verifies that NGINX Plus operates correctly when it is run on a FIPS‑enabled OS that is running in FIPS mode. NGINX cannot make similar statements for NGINX Open Source...
https://www.nginx.com/blog/achieving-fips-compliance-nginx-plus/#FIPS-Compliance-with-NGINX-Open-Source
They can't make claims for the OS you compile on or the flags that you use to build. There's a lot going on in an OpenSSL build.
https://wiki.openssl.org/index.php/Compilation_and_Installation
And any deviation from the "trusted path" or "validated" build steps may invalidate your installation.
https://www.openssl.org/docs/fips/UserGuide-2.0.pdf
To add to #Anthony Mastrean's answer, you can totally use nginx open source and achieve FIPS compliance with FIPS 140-2 validated crypto modules - it's just that you have to do more work yourself.
It mostly comes down to:
configuring your OS in FIPS mode,
using a NIST-blessed openssl version (the exact version that you use needs to be listed in the CMVP here: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?SearchMode=Basic&ModuleName=openssl&CertificateStatus=Active&ValidationYear=0)
there is no option of you compiling openssl, unless you want to pay NIST to test it and certify your build in the CMVP
configuring the correct TLS protocol version, ciphers, etc.
If you want to pay nginx, their paid "plus" offering does some/most of this set up for you.
eg. for OS: https://aws.amazon.com/blogs/publicsector/enabling-fips-mode-amazon-linux-2/
eg. for Openssl: https://wiki.openssl.org/index.php/FIPS_mode_and_TLS
I have a "blackbox" application written in Java that connects to MQ. On unix server there is MQ Client installation version 7.5.0. Java application is using 1.7.0_79. I have to use SSL_RSA_WITH_AES_256_CBC_SHA256 to make the connection.
I cannot upgrade to MQ Client v8. I am not entirely sure if I can connect having MQ Client version 7.5.0 and for instance use SSL_RSA_WITH_AES_256_CBC_SHA256.
Would be that even possible to establish connection having these components ?
IBM added support for non-IBM Java cipher suite names via APAR IV66840, this was included in MQ v7.5.0.5.
What you are asking should be possible if you have the following:
Set this java system property
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
or
System.setProperty("com.ibm.mq.cfg.useIBMCipherMappings", "false")
Use cipher suite value TLS_RSA_WITH_AES_256_CBC_SHA256.
Note does not start with SSL_ for Oracle java.
Make sure the strong cryptographic provider is enable in java to support ciphersuites with AES256 encryption. It appears that if you upgrade to a higher level of java 7 (1.7.0_161 for example) this will be included and enabled by default.
Use a JKS keyStore.
I am running my JDK8 application in JDK11 enviroment.
I am using TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher suite algorithm which i am suspecting that it is not supported or disabled in JDK11.
There are list of ciphers which are supported by jvm
please refer https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
Also if you see here someone has listed cipher which is supported by jdk upto jdk1.8
https://developer.ibm.com/answers/questions/301898/where-i-can-find-list-of-cipher-suites-that-suppor/
but I want to know which cipher suite algorithm is supported/enabled/disabled in jdk11.
I am using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher algorithm but when i am trying to run my application in jdk 11 run time environment I am getting SSLHandshakeException(Getting javax.net.ssl.SSLHandshakeException in JDK11). That's why I am trying to change my cipher suite algorithm and for the same i want to know which algorithm I can use in JDK11 enviroment.
It will be helpful if i also get to know the ciphers which are supported by both jdk11 and jdk8.
Please help me with it.
Thanks.
For revised Q:
Your first link is to (Oracle, and thus OpenJDK) java 7 not 8; there are differences in TLS ciphersuite support between 7 and 8, although not affecting the ciphersuite you name. Your link for 'upto 1.8' is for IBM Java which uses different cryptoproviders and is not good documentation for Oracle/OpenJDK crypto. Note the question at that link is specifically "... Cipher suites that supported by IBM Java" -- NOT Oracle/OpenJDK Java. For Oracle/OpenJDK 8 see https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites and for 11 see https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names . Both include TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and as expected it works for me in Oracle 11.0.2, and numerous versions of 8. All TLSv1.2 ciphersuites supported in 8 are still supported in 11, although 11 additionally supports TLSv1.3 (which you apparently aren't using).
Aside from the fact that, as commented, the Java defaults usually do better at providing security than overrides by people who don't know what they're doing, the exception you report in your other Q (but didn't provide here)
javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature
does not in any way indicate that the ciphersuite you name is unsupported. First, please be clear whether your application is the TLS client or server -- even if there is not a client/server relationship in the application protocol, there always is in the TLS protocol; that's how TLS (and SSL before it) is defined.
Second, follow the standard instructions for SSL/TLS=JSSE debugging by running with system property javax.net.debug=ssl and show the resulting output (probably just the last 100 lines or so, because it's quite voluminous).
Original Q was much vaguer and appeared to be about RC4, but actually wasn't.
Your question text gives no clue what 'cipher suite algorithm' you mean, but you tagged RC4-cipher. If your issue is using (any of the) ciphersuites that include RC4 in TLS 1.2 or earlier, then you shouldn't. RC4 was prohibited for TLS by RFC7465 in Feb. 2015 because of rapid advances in cryptanalytic attacks on it. This applies to all versions of TLS protocol existing in 2015 (1.0, 1.1 and 1.2), and was implemented by all supported versions of Java: 8 from 8u60 up, and all releases of 9 and higher.
If you really want to use RC4 and risk attackers stealing your data -- perhaps it is actually false, meaningless, or otherwise valueless -- either change the setting in the java.security file or call Security.setProperty early in your program (before loading JSSE); see the JSSE Reference Guide e.g. for Java11. Note in j8 the file location is different, <JREhome>/lib/security/java.security. See also RC4 related issue after Java 8 update .
If and when you (want or need to) use TLS 1.3, which Java 11 and up supports, this is no longer an option. TLS 1.3 only supports AEAD ciphers (or modes), which RC4 as originally defined is not, and no proposal for an AEAD construct based on RC4 will be accepted today.
On the other hand if you just want to use good, secure ciphersuites, don't change anything and just use the defaults. The defaults are the defaults precisely because they are secure, at least as far as is currently known. If analytic advances change that, then the defauts will be changed accordingly, and your programs using them will also be secure without you having to make, test, distribute, and verify new releases.
I was looking to enable chacha/poly algorithm in the openssl 1.1.0 version. I googled alot but couldn't get the resolution. please help me if any one knows
How do I enable chacha/poly in openssl1.1.0
ChaCha20/Poly1305 is enabled by default in OpenSSL 1.1.0. With all other things being equal, you will use it if its a common cipher and its selected by the client or server.
If you are not seeing ChaCha20/Poly1305 as the cipher suite, then check the server. It probably lacks support for curve25519 or the cipher suite. You should still see the cipher suite advertised in the ClientHello.
A disappointing thing about ChaCha and Poly1305 is they are only available as a unit via EVP_chacha20_poly1305. You cannot use just ChaCha or just Poly1305. (And ChaCha is TLS's ChaCha, and not Bernstein's ChaCha).
Also see How to use Poly1305 with EVP interfaces? on the OpenSSL Users mailing list.
Some phones only prompt the user for permission the first time a connection is made. Others pop up the permission prompt whenever the MIDlet attempts to make a HTTP connection! What are the options if we want to suppress the prompt?
Can we sign the JAR using only one CA (Certificate Authority) and have it work on all devices? Do we have to pay for a signature on every release?
Is it an option to create our own CA certificate and tell our customers to install it on there device?
Alternatively, it seems that plain socket connections do not suffer so. Is there a free implementation of HTTP on top of TCP for J2ME?
Some phones allow you to change the setting manually to set once per session. Or try adding
MIDlet-Permissions: javax.microedition.io.connector.http
to the jad file.
Yes, if the build is signed with the root certificate that is available on most devices, Verisign Class 3 certificate, for example
As a security measure, devices don't allow you to install your own certificates, even if it is obtained from a CA.
Plain socket connections may add overhead in processing of the data in the client side. Also some security issues are also involved.
Signing the JAR is not guaranteed to suppress these prompts on all handsets and all networks. It may work on some. AFAIK you usually need to sign per build; so if you use the same build on many handsets, you need to sign only once.
You could write your own implementation of HTTP over sockets, but beware that Socket implementations do not allow access to ports 80 and 8080 (again AFAIK).
Your best option when experiencing multiple prompts for HTTP is to direct the user to the MIDlet permissions setting in their handset menu; this should be changed to "ask once".
HTH,
funkybro
Java Verifieds UTI root certificate is not on all handsets/network combinations, the same is true for other domains in the trusted third party such as Verisign and Thawte (for these bodies in particular Motorola devices)
It is fair to say that the UTI certificate is probably the one to choose to give you the most coverage across handsets
To suppress the HTTP connection prompt, signing an app is the only option. Another would be to get preload on a pre-market phone, but even the handset manufacturers require signed jad/jars.
Making a set of jad/jar work on different devices is not dependent on signing but how you design an app. If you can address this then yes, you can have one signed jad/jar work on multiple devices.
I do not know about creating our own certs and asking customers to install them. I dont think it works as I dont think it is possible.
HTTP over TCP is a fairly easy implementation, provided you know what you are doing, but I dont know of any free implementations of it.
Get it Java Verified and you will find that on all networks and phones - the user will get prompted only once each time they start the app to authorise a connection.