Our cryptography service discovery site discovery.cryptosense.com detects servers under a given domain name and runs SSH and TLS scanners against each of them. The results are checked against best practices carefully defined by Cryptosense. You can also choose to check your results against other widely known standards: ECRYPT and NIST.
Cryptosense Discovery now provides a new standard, “ANSSI”, based on the recent new version of the security recommendations for TLS by ANSSI, the French government cybersecurity agency.
Why would I care about recommendations from ANSSI?
Broadly speaking, ANSSI is the French equivalent of NIST, and their recommendations are usually meant for French OIVs (Opérateur d’importance vitale – companies and agencies considered vital for the French economy and the security of the state), and anyone who wants to supply technology to the French government.
However, even if you are outside those categories, the ANSSI have real experience of state-level actor attack capabilities, so it’s interesting to see what they recommend.
What’s new in v1.2 of the ANSSI recommendations?
The previous publication is v1.1 from August 2016, which is a long time in cryptography years. There are too many changes to list them all, but here are the most notable ones:
- Support for TLS 1.0 and TLS 1.1 is now discouraged. TLS 1.3 is the preferred option, while TLS 1.2 is only tolerated.
- 3DES is not tolerated anymore.
- Cipher suites with CBC+HMAC must use the Encrypt-then-MAC extension.
- More TLS extensions should be avoided, like max_fragment_length, ec_point_formats and early_data.
- Session resumption should use key exchange.
- The 0-RTT option in TLS 1.3 should be avoided.
How hard is it to check your servers?
To scan servers, you could use popular tools such as Nmap or testssl.sh, or well known online scanners such as those from SSL Labs or Hardenize.
Unfortunately, none of the tools we know of provide enough data to check the ANSSI policies. You would typically need a combination of them, and some manual work, to be able to check all the rules.
For instance, unusual details necessary for a full ANSSI analysis include TLS extensions and X.509 revocation data.
What is checked by Cryptosense Discovery?
Discovery finds servers related to a given a domain name and scans them. We support a number of the specific requirements ANSSI contains, but not all. Since the ANSSI recommendations cover more than just servers, some of them don’t apply to Discovery.
Below is a table of the ANSSI rules currently checked by Cryptosense Discovery at the time of writing this article:
| ID | Summary | Notes |
| R3 | Prefer TLS 1.3 and accept TLS 1.2 | Partial support. |
| R4 | Do not use SSLv2, SSLv3, TLS 1.0 and TLS 1.1 | ✓ |
| R5 | Authenticate the server with key exchange | Partial support. |
| R6 | Exchange keys with PFS | ✓ |
| R7 | Exchange keys with ECDHE or DHE | Partial support. |
| R8 | Authenticate the server with a certificate | ✓ |
| R9 | Prefer AES or ChaCha20, tolerate Camellia and ARIA | ✓ |
| R10 | Use an authenticated mode of encryption, or at least CBC with Encrypt-then-MAC | Partial support. |
| R11 | Use SHA-2 as hashing function | ✓ |
| R13 | Prefer server order of cipher suites | ✓ |
| R19 | Do not use TLS compression | ✓ |
| R24 | Present a certificate signed with SHA-2 | ✓ |
| R25 | Present a certificate valid for at most 3 years | ✓ |
| R26 | Use keys of sufficient lengths | ✓ |
| R27 | Present an appropriate KeyUsage | ✓ |
| R28 | Present an appropriate ExtendedKeyUsage | ✓ |
| R33 | Present a certificate with revocation sources | ✓ |
Of the applicable recommendations, more may be added to Discovery in the future. If you have feedback or are interested in the addition of some of those rules, please get in touch.
To test your servers against those new rules, go to discovery.cryptosense.com and select “ANSSI” in the left column of the results page.
