I am new for FIPS 140-2, our application is using TLS 1.2 for communication with other systems. I am wondering if there is any requirements for TLS 1.2 to comply with FIPS? In other words, in order to be FIPS-compliant, what does our TLS 1.2 application need to do?
FIPS 140-2 is just some set of encryption/decryption algorithms that are used and monitored by the federal agency. TLS1.2 is surely accepted as FIPS-compliant but the underlying key exchange algorithm must be FIPS compliant. For that, you can use some third-party libraries, for instance, BCFIPS.
TL;DR - it depends on your tech a bit, but in general: You need to use a blessed module tested by NIST to calculate crypto routines as well as configuring your OS and TLS libraries to use good ciphers and protocol versions only (read: make it as close to impossible to use unsupported settings as possible).
If it's nginx, you need the exactly right version of openssl running and configured correctly (correct ciphers, TLS version and so on), and your OS needs to be in FIPS mode.
If it's a JVM app, you need the exact right version of Bouncy Castle installed and configured correctly so that it replaces the default Sun TLS routines, as well as your OS in FIPS mode. On it goes for other types of apps. iirc Python uses openssl, so it's more like the nginx story...
Others probably know more than I do...but hopefully this helps start the journey to understanding.
More details:
FIPS 140-2 is a bit slippery to understand at first.
Some folks say that they are doing "FIPS 140-2 compliant/compatible crypto ciphers" that makes it sound like they are meeting the criteria of the specification, but unfortunately that is different than actually using FIPS 140-2 validated cryptographic modules (as well as all the appropriate configuration of ciphers and so on).
If you are supporting FIPS 140-2 validated cryptography for something like NIST 800-53, then you are required to "do more things" than just configure TLS 1.2 correctly.
https://www.gsa.gov/cdnstatic/SSL_TLS_Implementation_%5BCIO_IT_Security_14-69_Rev_6%5D_04-06-2021docx.pdf has a reasonable summary of things to be aware of in section 3.
FIPS 140-2 compliant encryption is achieved when the following conditions are met:
Implement FIPS 140-2 Encryption Modules AND enable the FIPS 140-2 Object Module
Implement Secure Protocols
Implement FIPS-approved Ciphers
One or both sides of the communication session (client and/or server) must be set up in FIPS mode
Further, the thing about using validated cryptographic modules means, the programs or hardware that calculate crypto routines must be on the list of blessed CMVP modules at NIST:
TLS implementation must use FIPS 140-2 validated cryptographic modules in order to achieve FIPS compliance. NIST maintains a list of FIPS 140-2 Cryptographic Modules (https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search). A cryptographic module may either be an embedded component of a product or application, or an individual product in-and-of-itself.
Obligatory wikipedia reference, which makes more sense once you already know about the CMVP: https://en.wikipedia.org/wiki/FIPS_140-2#Compliance
An example of setting up your OS in FIPS mode: https://aws.amazon.com/blogs/publicsector/enabling-fips-mode-amazon-linux-2/
Redhat and others have similar guides. For windows or other OSes... your mileage may vary, but I'm sure someone has been crazy enough to do it.
OpenSSL has some notes on FIPS 140-2 that are somewhat entertaining and informative: https://wiki.openssl.org/index.php/FIPS_mode_and_TLS
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 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.
There are several implementations of TLS that support DTLS 1.2. Wikipedia has an exhaustive link here.
My reading points to the classic openssl, libressl, boringssl and mbed TLS as viable options. I am only interested in DTLS 1.2 API and nothing more. I have no interest in usage of the API elsewhere.
openssl seems to be bogged down with a lot of old protocol and usage baggage. mbed TLS's implementation approach appears to be good but it rarely figures in any comparison. I wonder why? Is it incomplete in any way?
If anyone has evaluated the above, or any other TSL implementation, purely for DTLS 1.2 API, which one would you suggest?
Mbed TLS is a lightweight configurable TLS library. It was initially designed for the embedded world and is currently used by large amounts of users and companies on all kinds of setups, from constrained devices to large servers.
Mbed TLS was previously known as PolarSSL, you may want to check both names when searching for references online.
You can find more information about Mbed TLS here:
https://tls.mbed.org/kb/generic/projects-using-mbedtls
https://tls.mbed.org/kb/how-to/mbedtls-tutorial
https://tls.mbed.org/kb/how-to/dtls-tutorial
https://tls.mbed.org/kb/compiling-and-building/how-do-i-configure-mbedtls
https://tls.mbed.org/kb/how-to/how-do-i-port-mbed-tls-to-a-new-environment-OS
I understand that PKCS#11 is std that defines cryptoki API and KMIP is a protocol that defines message format, but how they are connected or are they even interconnected?
How they both hold their individual significance in cryptography?
PKCS#11 can be considered a protocol of a kind too, it's used to communicate with the hardware devices (to be precise, with the driver modules of those devices). However, it's not suitable for network communications. KMIP is the protocol to communicate with remote key storages and similar services and use the remotely stored keys. This is similar to what PKCS#11 offers locally.
In theory, the protocols partially interlap and are to certain extent interchangeable - Oracle has the PKCS#11 driver/gateway, which talks to the remote KMIP server, and the opposite should also be possible. But, of course, each has its own strengths and weaknesses. Interestingly, both KMIP and PKCS#11 standards are developed by the same people in OASIS.
There's also a paragraph in Wikipedia that answers your question.
I am working on an application that needs to encrypt all of its traffic on a LAN environment and so the speed of encryption is important and the cpu time needs to be reduced to let the application have more cpu cycles for itself. I am thus trying to understand what are my existing options besides rolling my own since I'm not a cryptographer.
I am trying to go now for a comprehensive list of all semi-valid options to be able to measure and test them:
TLS -- Not considered fast, maybe possible to tune the ciphers
SSH -- Maintaining ssh tunnels may be a burden
UDT -- Should be high performance, how is the optional encryption?
CurveCP -- By DJB so encryption is good, not sure about the transport part
MinimaLT -- DJB contributed crypto know-how, others did the transport
IPSec -- non-trivial to configure
What else I missed?
Go with TLS. The chances that the provider has heard of it and that acceleration is already present is rather high. SSH would also be an option, but it is generally used for administration.
About the other options:
UDT -- Should be high performance, how is the optional encryption? Good question, and a quick search did not find too much information, so avoid.
CurveCP -- By DJB so encryption is good, not sure about the transport part Anything mainly done by DJB requires university grade understanding of cryptography.
MinimaLT -- DJB contributed crypto know-how, others did the transport. See above. The main documentation seems to be a paper about MinimalLT.
IPSec -- non-trivial to configure And possibly security at the wrong level. Personally I would avoid, may be tricky to setup on a cloud provider.
So there you are, in the end transport level security always seems to gravitate towards TLS.
Try to go for a ciphersuite with AES and ECDSA/ECDH(E) if you want a high chance of a speedy implementation and a high level of security.