[Help-gnutls] Re: Handling "normal" peer errors on invalid certs

[Simon Josefsson]

Philip Kovacs <kovacsp3 at comcast.net> writes:

> Hi.  I'm new to GnuTLS.  I'm using it for a client-server library and 
> I have a fairly basic question.

Hi!  Welcome.

> When my server is configured to require x.509 client certificates,
> and the client either fails to send one, or sends an invalid one,
> the server detects this error during its gnuttls_handshake() and
> I have the server break off the connection, as desired.
>
> The client's gnutls_handshake(), upon server break-off is returning
> either GNUTLS_E_PUSH_ERROR or GNUTLS_E_UNEXPECTED_PACKET_LENGTH.
>
> The server situation is similar:  if the client detects an invalid
> server certificate, I have the client break off the connection.  
> The server then sees GNUTLS_E_UNEXPECTED_PACKET_LENGTH in its (first) 
> gnutls_record_recv().
>
> Is there something more I need to do in order to close the communication
> down more "gracefully" in situations where certificate failures are seen?
>
> Just seems odd to be handling GNUTLS_E_PUSH_ERROR or
> GNUTLS_E_UNEXPECTED_PACKET_LENGTH "normally" when the other side doesn't
> like the certificate.

I suspect the error handling here is simply sub-optimal, and that you
aren't doing anything wrong.

Creating a self-test inside GnuTLS tests/ that trigger this situation
would help.  Having that self-test would help us test what kind of
errors really should be returned in this situation, and how to return
them.  I can't commit to work on this now, so I added the following to
doc/TODO:

- Investigate why failed client authentication results in weird error
  messages.  See http://permalink.gmane.org/gmane.network.gnutls.general/875

If you or others wants to work on it, you are very welcome to do so.

/Simon