Community
Participate
Working Groups
According RFC5246, the ServerKeyExchange may have no "signed_params" for anonymous key exchanges. Unfortunately the "signed_params" may be simply left out by an attacker also in non-anonymous key exchanges in order to bypass the signature verification. Californium doesn't check that, it only ignores the verification, if the signature is missing. Proposed behavior: - fail, when no signature is provided in the ServerKeyExchange FMPOV, this bug requires a CVE.
All versions 2.0-2.6.4 are affected and also all 3.0.0 milestones. Version 1.0 are not affected, there a NullPointerException will fail the handshake.
FMPOV http://cwe.mitre.org/data/definitions/322.html describes the error.
Bugfix PRs: master/3.0: https://github.com/eclipse/californium/pull/1686 2.6.5: https://github.com/eclipse/californium/pull/1687 Planed schedule for 2.6.5: 11-August https://projects.eclipse.org/projects/iot.californium/releases/2.6.5
Could you precise which of PSK, RPK or X509 mode is affected ? Client, Server or both ?
DTLS client-side, RPK and X509 mode. The client considers the Certificate to be verified by the signature, but an attacker (server-side) may send a certificate and no signature in the ServerKeyExchange, which bypasses that signature verification. I started to consider, if a role-exchange extends the scope. I didn't find, that this extends that attack.
Project name: Eclipse Californium Versions affected: [2.0.0, 2.6.4] and [3.0.0-M1, 3.0.0-M3] Common Weakness Enumeration: - CWE-322: Key Exchange without Entity Authentication Summary: In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the certificate based (x509 and RPK) DTLS handshakes accidentally succeeds without verifying the server side's signature on the client side, if that signature is not included in the server's ServerKeyExchange. Links: - https://bugs.eclipse.org/575281
@Simon @Kai please check, if that description is OK for you.
(In reply to Achim Kraus from comment #0) > According RFC5246, the ServerKeyExchange may have no "signed_params" for > anonymous key exchanges. Unfortunately the "signed_params" may be simply > left out by an attacker also in non-anonymous key exchanges in order to > bypass the signature verification. Californium doesn't check that, it only > ignores the verification, if the signature is missing. > > Proposed behavior: > - fail, when no signature is provided in the ServerKeyExchange > Since we do not support anonymous key exchanges at all, I also think that this is the way to go. > FMPOV, this bug requires a CVE. I agree
(In reply to Achim Kraus from comment #5) > DTLS client-side, RPK and X509 mode. > > The client considers the Certificate to be verified by the signature, but an > attacker (server-side) may send a certificate and no signature in the > ServerKeyExchange, which bypasses that signature verification. > > I started to consider, if a role-exchange extends the scope. I didn't find, > that this extends that attack. Does this mean that a client that wants to authenticate using a certificate or RPK cannot simply omit the signed_params in order to bypass the server's verification?
(In reply to Achim Kraus from comment #6) > Project name: Eclipse Californium > > Versions affected: [2.0.0, 2.6.4] and [3.0.0-M1, 3.0.0-M3] > > Common Weakness Enumeration: > > - CWE-322: Key Exchange without Entity Authentication > > Summary: > > In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the > certificate based (x509 and RPK) DTLS handshakes accidentally succeeds > without verifying the server side's signature on the client side, if that > signature is not included in the server's ServerKeyExchange. > > Links: > > - https://bugs.eclipse.org/575281 That one is ok for me. Another one that seems appropriate would be http://cwe.mitre.org/data/definitions/347.html FMPOV
In reply to #9 > Does this mean that a client that wants to authenticate using a certificate or RPK cannot simply omit the signed_params in order to bypass the server's verification? According RFC5246, the client has to use the CertificateVerify https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.8 for that. That is checked and will fail the handshake. If a none empty client certificate is sent, the missing of that message will also fail the handshake. In RFC5246 that's the difference in the server and client certificate based authentication. server: Certificate and signed ServerKeyExchange client: Certificate and signed CertificateVerify. The ClientKeyExchange is not signed at all. A anonymous server will not sent a Certificate and doesn't include the signature in the ServerKeyExchange. A anonymous client will send a empty certificate an no CertificateVerify. According the configured client authentication mode (none/wanted/needed), a empty certificate is refused or passes the check. I guess, that system reflects many cases, where only the server is authenticated and the client stay anonymous until some "token" or "username/password" authenticates it over the already encrypted connection.
In reply to #10 > http://cwe.mitre.org/data/definitions/347.html My interpretation of 347 is, that there is a signature, but that is not proper checked. My interpretation of 322 is, that "without Entity Authentication" meana also without signature. Sure, just interpretations.
(In reply to Achim Kraus from comment #12) > In reply to #10 > > > http://cwe.mitre.org/data/definitions/347.html > > My interpretation of 347 is, that there is a signature, but that is not > proper checked. > > My interpretation of 322 is, that "without Entity Authentication" meana also > without signature. > > Sure, just interpretations. Then let's stick with 322.
(In reply to Achim Kraus from comment #11) > In reply to #9 > > > Does this mean that a client that wants to authenticate using a certificate or RPK cannot simply omit the signed_params in order to bypass the server's verification? > > According RFC5246, the client has to use the CertificateVerify > https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.8 for that. > That is checked and will fail the handshake. If a none empty client > certificate is sent, the missing of that message will also fail the > handshake. > > In RFC5246 that's the difference in the server and client certificate based > authentication. > server: Certificate and signed ServerKeyExchange > client: Certificate and signed CertificateVerify. The ClientKeyExchange is > not signed at all. > > A anonymous server will not sent a Certificate and doesn't include the > signature in the ServerKeyExchange. > > A anonymous client will send a empty certificate an no CertificateVerify. > According the configured client authentication mode (none/wanted/needed), a > empty certificate is refused or passes the check. > > I guess, that system reflects many cases, where only the server is > authenticated and the client stay anonymous until some "token" or > "username/password" authenticates it over the already encrypted connection. Great, thanks for explaining
> if that description is OK for you. That sounds good to me. Thx for very clear explanation. > FMPOV, this bug requires a CVE. I agree.
@Wayne Please check comment #6 if something is missing for you in order to assign a CVE. If nothing is missing, please assign a CVE and create the mitre PR. Thanks in advance!
Sorry for the delay. > Please check comment #6 if something is missing for you in order to assign a > CVE. I've assigned CVE-2021-34433 and have pushed the report to Mitre. https://github.com/CVEProject/cvelist/pull/2615
Thanks a lot!
Based on the discussion, I believe that we can reasonably mark this as FIXED. Reopen if I've made a horrible mistake.
