[gnutls-devel] GnuTLS | Non TLS-compliant behviour (#672)

[Development of GNU's TLS library]

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
   certificate_expired alert.
```

-- 
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...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20190113/18422f43/attachment.html>