Misleading BSI TR-02102-2 recommondations
craig opened this issue · 7 comments
When the tools scans a system, it says:
----|Failed Checks:
Die folgenden Diffie-Hellman Gruppen werden empfohlen.
The following groups were supported but not recommended:
ECDH_X25519
The German sentence means "The following Diffie-Hellman Groups are recommended", but then groups are listed that are not recommended.
The additonal ECDH_X25519 group (https://en.wikipedia.org/wiki/Curve25519) does not mean that the system is insecure, it only means that it's not listed as recommended in the BSI TR-02102-2 recommondation.
This does not deserve a "failed check" and is not the same category as e.g. supporting TLS 1.0.
I would agree that x25519 does not mean the system is insecure. But TR-02102-2 does not recommend this group. The whole language of the guideline is written in recommendations. The guideline explicitly tells you which groups are recommend, and which are "ok to use":
brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 (see [RFC5639] and [RFC7027])
If these curves are not available, the following curves can also be used:
• secp256r1, secp384r1, secp521r1
It makes sense that if you violate this "recommendation" your tests fail. I.e., if a non-recommended group is "weak" and you still support it breaks your security. So I see this rather as a problem with the guideline than with our scanner.
Hi @ic0ns,
I've actually written to the BSI about this, they specifically answered that one do not fail the TR-02102-2 recommondations if additional ciphers are supported and pointed to the introduction of the document. From a practical viewpoint, it does not make sense to "fail" the requirement of providing "secure tls", if you support more secure ciphers.
They are not going to change the document any time soon, but I have in writing that they don't know about any cryptographic issues with TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_8_SHA256, Curve25519 und Curve448, so those can be considered safe.
If the scanner says "Failed Checks", when those ciphers are supported, it gives the strong impression that they need to be disabled; but that's not the case. Maybe a less harsh wording would already go a long way in preventing unnecessary discussions with pentesters using your tool.. :'-)
Their contact is: tr02102@bsi.bund.de
- craig
Well, if I start changing the tests based on my own knowledge and opinions I am not really evaluating the guideline anymore, but a hybrid of what I think the guideline should have been instead. The BSI did not publically state in that guideline that they consider x25519, x448 or chacha safe, secure and recommended choices.
The guideline checks we implemented just literally check if the server is following the recommendations described in the respective documents. If the server does not, a check fails. We implemented these guideline checks for people who have to follow these guidelines due to compliance requirements or company policy. If your job is to follow TR-02102-2 then supporting X25519 is a violation and you have to disable it to be compliant. If you don't care about TR-02102-2 and just want a secure & fast configuration you have more freedom. For this case especially (as well as pentesters) who just want to know if there is a problem, and if so how severe is it - we implemented our own recommendations which also rate the severity of the issue based on our own opinion.
If the BSI publishes a new documents which gives the thumbs up for these I am happy to change the checks, but as it stands they are not recommended, so the tests fail.
We implemented these guideline checks for people who have to follow these guidelines due to compliance requirements or
company policy.
For those people, the tool is misguiding: the BSI does not say you need to deactivate better ciphers to be compliant. You can still have an auditor certify your system if they are enabled. Those are only recommondations after all, you're allowed to use something safer.
"The Technical Guideline at hand contains recommendations for the protocol version to be used as well as
the cryptographic algorithms and key lengths as a concretisation of the general recommendations in Part 1
of this Technical Guideline [TR-02102-1]. As mentioned in Part 1 of [TR-02102-1], mechanisms which are
not listed are not necessarily considered by the BSI to be insecure."
I can just recommend talking to the BSI if you doubt what I'm saying.
Anyways, it's your tool, you will do as you please. ;)
I am open to a discussion as I don't work commonly work with any guidelines but I don't see how another interpretation makes sense. If I allow not recommended algorithms I can quickly get into the "this is dangerous zone", because I suddenly allow null or export cipher suites, which are considered not recommended by the guideline also the same way x25519 or x448 are not recommended. SSL 2 is also only "not recommended". It's not 'forbidden', but activate it and hell breaks loose. There is no distinction between x25519 and SSL 2 in the document. If I as the developer now judge that x25519 is secure and SSL 2 is not so x25519 should not result in a failed test but SSL 2 should then I am effectively implementing my own guidelines and not TR-02102-2 anymore.
The statement you are quoting is also not contradicting our tests, with our guideline tests we are not evaluating if you are secure or not, we are evaluating if you are following the guidelines. Since all the "requirements" in the guideline are formulated as recommendations that is what we are testing.
I've done 15 BSI certifications so far. ;) That's a bit of an issue with the BSI, they sometimes give recommondations that might sound like you have to stick to them, but in reality, you don't have to be too strict if you have good reasons.
Generally "known bad" alogrithms/ciphers are hard to argue against, but if there are no publicly known issues with a newer cipher that's generally accepted as being strong, the Auditor who is testing you will very, very likely not complain about it. They will hand their assessment of your systems to the BSI - which will probably not complain about it either. I think they should add newer ciphers to their documents, but then again, they're just as short-staffed as everyone else and can probably not keep up.
Despite being a government agency, IMHO the BSI tries not to be too strict.
I'll try to persuade them to include newer ciphers/algos in the 2023 version, we'll see.
I totally understand that. But I can only put in the tests what they publish^^ - also I don't think they will recommend everything new, as there are also non-technical reasons why specific algorithms or parameters are not recommended. For example, I don't think they will recommend the Russian GC curves, published in March 2022 (RFC9189) anytime soon, although there are no known attacks or weaknesses.
But if you personally want to whitelist specific groups or cipher suites, you can do that by modifying the XML files which describe the guideline:
https://github.com/tls-attacker/TLS-Scanner/blob/master/TLS-Server-Scanner/src/main/resources/guideline/bsi.xml
If you rebuild the project the scanner should honor your updated guidelines.