Is it worth adding cipher suites and generating DH elliptic curve key to become compliant with FIPS ?
I edited nginx-ssl.conf for cipher suites, enabled DHEC and generated DHEC 4096 key.
I guess if you add this to initial setup, you would want to generate the key on different thread because it takes a while to generate. I fork this and made commit to my res. I wanted to get feedback if this is worth the time.
I digress from my original posting and move to different direction. I believe the current Nginx SSL settings ARE FIPSv2 compliant. Not sure for v3 but its not public yet. I’m not sure why it wasn’t compliant at first when I did my testing at Qualys on the SSL.
I went back added your protocols and the results were FIPS ready . My certification might not of been right initially when I first did the test.
For Qualys requirements to past there test.
With that being said currently settings do not have elliptical curve enable. To make that happen you have to generate a 2048 bit key and on most computers that doesn’t take to long. On 1 GB digital ocean a 4096 bit key takes a long time. So I can’t I see that being done at install, at least not at default.
I wrote a tool script for mail-in-a-box to just install DHEC.
But there’s a additional option for a more conservative cipher suite but be advise your limiting your coverage to the newest technology. It limits the cipher suites to 256 and EC. Also limits to TLS1.2. I think Qualys shows only the newest browsers and phones are able to support the protocols
I can think there are many good reasons why a user would want these settings. But at the same time I can count the number of users on my system so I know coverage and efficiency isn’t issue for me. I used this to get a complete 100 across the board at Qualys for all four categories for my website.
Use as reference to achieve an 100:
For explanation for anyone that doesn’t know what FIPS is, like me. Here are some resources.
Essentially, you have to understand the exchanging of keys to understand this. A new trend has been perfect forward secrecy to protect the exchange of keys. There’s a negotiation process between the exchanging RSA certs but if the exchange is intercepted and the attacker gets the private keys and captures traffic, then its all for nothing, MITM attack. Perfect forward secrecy address this problem by using strong session keys which becomes very hard to break. Your keys are random per session and deterministic so past messages can not be compromise if other messages are compromise. The RSA private key is used the sign the DH handshake which then the exchange of DH keys happen.
This is good stuff. I will look into dovecot. I’m curious what went wrong. Any details on on why or what went wrong? I personally didn’t mess with postfix or dovecot yet.
The 256 is the cipher strength. The strength of the encryption of the data being transmitted. So the connections is being encrypted with AES 256 bit. The RSA is for signing and handshaking and hashing is for integrity .
Here’s some quick references for the abbreviations:
We’re not going to add any options to the setup — it makes it too complicated both for the user and for me to maintain. We can switch everyone over to 4096 bits, but I think that’s premature for now (and we would have to check compatibility with CAs).