Graceful connection failure for failed TLS handshake

[tegefaulkes]

Specification

Currently we are seeing unintended behaviour when the connection fails a TLS handshake.

What we want to happen is, if a connection fails the TLS handshake then we close the connection.

1. The connection should gracefully end for both the server and client.
2. any further attempts to establish the connection is ended.
3. Errors are propagated and the failure condition is clearly indicated to the best of our ability. This should mainly state that the TLS failed, hopefully it will specify why the TLS failed.

We need to add tests to test these conditions. The tests should check for

1. Connection success
2. Server certs fail verification
3. Client certs fail verification
4. Both server and client certs fail verification
5. We should test RSA, EC and ED signed certs.

The main way we can trigger verification failure is to have the certs self signed. We can make the certs succeed verification by providing a CA cert that allows the self signed signature.

Additional context

• Related Create TLS cert arbitraries for testing #8

Tasks

1. Expand tests to test for the above conditions
2. Fix up the connection logic to match the expected behaviour.
3. Add text fixtures for certs. These should be included in git.

[tegefaulkes]

Still getting my head around the library right now but I think I have a good idea of the problem now.

When the client fails the TLS handshake it starts the quiche connection closing proceedure. It enters a draining state where the send and recv calls need to be flushed. That is, packets need to be processed until the connection is closed. This is required so that the quic protocol can exchange the ending frames to gracefully close the connection.

The underlying problem is in two parts.

1. The QUICConnection was trying to destroy itself during the draining state due to some bad logic.
2. The createQUICClient factory was trying to stop the underlying socket before the QUICConnection had time to drain and clean up. resulting in an error due to the existing connection.

[CMCDragonkai]

Beware that the timeout mechanism I had was just a prototype. I didn't fully understand how quiche actually times out an idle connection, so the entire flow (including the while loop) might be missing something critical.

[tegefaulkes]

The connection is failing gracefully now. I think there may be a problem with it timing out so I need to look into that.

There is an oddity as well, The client is failing to verify the server due to CONNECTION_CLOSE (Transport) Error code: CRYPTO_ERROR (Unknown CA), TLS Alert Description: Unknown CA (48). This is somewhat expected due to the cert being self signed. But setting the CA doesn't fix this. Just another thing to look into.

[CMCDragonkai]

The standard TLS verification logic should accept a cert if it is trusted and if it put into the CA, it should be trusted.

However there are details relating to how CA verification works and the chain verification procedure that I may have forgotten.

See this guideline:

https://en.m.wikipedia.org/wiki/Certification_path_validation_algorithm

Exact details is in RFC 5280

[CMCDragonkai]

Review https://datatracker.ietf.org/doc/html/rfc5280#section-6

[CMCDragonkai]

I followed that when synthesising our custom verification code back in the network domain of PK.

[CMCDragonkai]

You can always play around with actually signing certs by a CA cert. There should be a tutorial on how to do this with step-cli. I've done it before with openssl and step-cli and step-ca is lot easier.

[tegefaulkes]

Some oddities to address

1. Can't get verifying the server to work, providing the server's cert chain as the CA doesn't seem to allow it.
2. It doesn't matter what certs are provided for the client, trying to verify it always succeeds.
3. Client doesn't fail properly when using the OKP signed cert. results in a timeout error and then the test timing out.

[CMCDragonkai]

Can you also do a sanity check against quiche's bundled QUIC server/client code?

See README.md, go to the place and do cargo build --exmaples. There's a quiche-client and quiche-server.

Maybe something is wrong with the binding, and quiche actually can handle it.