[gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Sun Jan 13 14:51:57 CET 2019
Being able to find such issues as part of a CI run would indeed be a nice
feature, however there are some obstacles. Results like this have been
discovered through evolutionary fuzzing techniques. In order for this to
produce results multiple instances need to run for days or weeks, which is
usually not desirable as part of the regular CI run.
In order to resolve the issue across the entire code base and not only w.r.t.
ECDHE I'd suggest the following steps:
1. Identify the code locations that are responsible for sending TLS Alerts
2. Make sure that upon receipt of a fatal alert the connection is immediately
terminated. Do not respond with any alerts of your own.*(1)
3. Use you IDE or tools like ctags/cscope to identify all code locations that
call the code locations identified in step 1.
4. Review the alert type selected by the code locations identified in step 3.
If this alert type is an `INTERNAL_ERROR` it is *very* likely it needs to
be replaced with an appropriate protocol related alert. Cases where sending
an INTERNAL_ERROR would be OK are for instance:
- A memory allocation request to the OS failed
- Starting a thread or forking a process failed
- A write to disk failed (i.e. because the hard drive is full)
(*1) Side note: You may send alerts in response to non fatal alerts. Be
aware however that sending a non fatal alert puts you in a situation where
you can not foresee how the peer will react.
Section 7.2.2 in RFC 5246 states
If an alert with a level of warning is sent and received, generally
the connection can continue normally. If the receiving party decides
not to proceed with the connection (e.g., after having received a
no_renegotiation alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection. Given this, the
sending party cannot, in general, know how the receiving party will
behave. Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are
sometimes omitted. For example, if a peer decides to accept an
expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/672#note_131126590
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnutls-devel