-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DTLS server allows insecure renegotiation without indicating renegotiation options in ClientHello #99
Comments
Unfortunately, RFC6347 doesn't really mention such kinds of TCP/TLS specific attacks. That attack is mainly based on "buffering" of TCP/TLS for "stream oriented" processing. |
RFC7925 also refers that TLS/DTLS allows a client and a server that already have a TLS/DTLS connection to negotiate some aspects by using the renegotiation feature. But yes, it also doesn't indicate that using renegotiation options is necessary for DTLS. Except for this, I am also confused why the server state is always in the DTLS_STATE_WAIT_CLIENTHELLO state, thereby the server can always accept ClientHello requests from clients. After replying ServerHelloDone, could the state of the server move to the following one? This can be reproducible if not using clients from TinyDTLS. |
Yes, there are some issue with the handshakes. I also created two issue (#84 and #93) and provided a PR to fix them (#89). I guess, if you retest with that PR (or even better with PR #94) your issue with epoch 1 is also fixed. The same developers of this library are also develop libcoap, and so I think we currently need more patience. |
RFC6347 -
According that, at least this SHOULD be the behavior. I recently also tried to get some more clarity for that, also because discussing issue #95 showed very different interpretations. My e-mail to the tls-mailing list wasn't answered, and DTLS 1.3 issue wasn't successful either. So, for now, a system should either go with that 4.2.8, or should have a specified "session timeout". Otherwise, assuming clients with changing addresses (maybe NATed) or crashes will no work that reliable, because the "close" is also not reliable (and assuming crashs, "close" even can't be reliable). |
In the meantime a lot of fixes have been merged. |
In the meantime we decide to implement a minimal version of RFC5746, see discussion in issue #175 . |
Thanks for retesting and closing! |
Hello,
The dtls-server application allows completing the second handshake without indicating renegotiation options in the first handshake message, which is prohibited according to RFC 5746.
We could use Wireshark to capture these two handshake processes shown as follows.
This creates the opportunity for an attack in which the attacker who can intercept a client's transport layer connection can inject traffic of his own as a prefix to the client's interaction with the server(cited from RFC 5746).
Could you kindly have a check? Thanks a lot.
Kind Regards,
Jerry
The text was updated successfully, but these errors were encountered: