tree d42759c1c3050c890a71125ae0ca2682881370e4
parent 8498cb36879643ec19878cb2442535bc7bb619c5
author Gilles Peskine <Gilles.Peskine@arm.com> 1494427076 +0200
committer Gilles Peskine <Gilles.Peskine@arm.com> 1494430262 +0200

Ignore failures when sending fatal alerts

In many places in TLS handling, some code detects a fatal error, sends
a fatal alert message, and returns to the caller. If sending the alert
fails, then return the error that triggered the alert, rather than
overriding the return status. This effectively causes alert sending
failures to be ignored. Formerly the code was inconsistently sometimes
doing one, sometimes the other.

In general ignoring the alert is the right thing: what matters to the
caller is the original error. A typical alert failure is that the
connection is already closed.

One case which remains not handled correctly is if the alert remains
in the output buffer (WANT_WRITE). Then it won't be sent, or will be
truncated. We'd need to either delay the application error or record
the write buffering notice; to be done later.