Just a couple of months ago we set up a brand new Server 2016 box, used IIS Crypto to select PCI compliant cyphers...
Today it failed a PCI compliance scan
The remote service supports the use of medium strength SSL ciphers.
TLSv1
DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES-CBC(168) Mac=SHA1
Disabling TLS 1.0 caused a whole raft of issues, but my main concern is a lot of our web applications use System.Security.Cryptography.TripleDESCryptoServiceProvider to encrypt/decrypt strings held on our DB.
If we disable Triple DES will these applications then fail to encrypt/decrypt or does it rely on cryptography built in to .NET?
Thanks
Related
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
We got vulnerabilities on windows server 2008R2, we are using BizTalk server 2010, they are going to disable RC4 ciphers, However how do we check what are all the ciphers our BizTalk server supporting and where do we find those list.
Basically they are going to be disabling TLS 1.0.
What you need to do is install the .NET Framework v4.5.2, as the actually ciphers you are talking about are at the .Net layer rather than in BizTalk.
Then you need to set the registry keys to disable TLS 1.0 and enable it defaulting to a stronger cryptography.
There is a good article about "BizTalk Server 2010 and support for TLS 1.2"
Well, hold on. They are only 'vulnerabilities' if you're actually using them.
If you have no TLS(SSL) 1.0 endpoints (Receive Locations), you don't have a problem.
If you are calling TLS(SSL) 1.0 endpoints (Send Ports), then your trading partner needs to update first, then you can move to TLS >1.0.
I know Corda is crytographically agile. As part of this, can a Corda network use GOST block cipher cryptography (GOST 28147-89) in order to comply with Russia standards?
GOST is an encryption scheme. The only place encryption is used in Corda is in TLS communication:
TLS 1.2 does not support GOST, although there is an RFC (https://www.ietf.org/archive/id/draft-chudov-cryptopro-cptls-04.html)
OpenSSL 1.1.0 and later no longer include the GOST engine (see Can't enable GOST engine support in OpenSSL)
Theoretically, Corda's crypto library (BouncyCastle) could support some of the GOST ciphers, as long as it supports all the algorithms defined in the TLS RFC
Even if TLS supports GOST cipher suites, for a full GOST-enabled Corda, there might be a requirement for GOST root, doorman and network map keys (if they need GOST in the certificate hierarchy as well)
I cannot see how mutually secure communication between the EU, US and the Rest of the World will be achieved, unless:
A company decides to run Corda in Russia only (their own Corda network with their own root certificate authority), or
TLS is modified to run dual algorithm encryption/hashing/signature/key-exchange. I am not aware of anything of this sort, except the Google post-quantum experiment that combined the ECC and New Hope algorithms. This means it is feasible to combine algorithms in TLS
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.
Firstly, thank you for the taking the time out to read this post.
I'm running a demo development web server which is hosting my ASP.net Web API in IIS8.
My API is setup to work only via SSL, but I need the self signed SSL key to be 1024 bits rather than 2048 due to the limitations of my Microchip PIC Microcontroller that connects to it.
Can anyone advise me on how I can generate a self signed SSL certificate to be 1024 bits rather than the default 2048?
Please note that I am new to network/web programming so I'm trying to work things out as I go along. Thus far this is my first demo web applications.
Many thanks,
Rob
Ok I managed to create a key size of 1024 using microsofts selfssl tool which is part of their IIS6 Resource Toolkit.
This has solved my problem.