Graceful connection failure for failed TLS handshake #9
Comments
|
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 The underlying problem is in two parts.
|
|
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. |
|
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 |
|
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 |
|
I followed that when synthesising our custom verification code back in the network domain of PK. |
|
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. |
|
Some oddities to address
|
|
Can you also do a sanity check against quiche's bundled QUIC server/client code? See README.md, go to the place and do Maybe something is wrong with the binding, and quiche actually can handle it. |
Also updated tests to use them. Still a problem with the client verification always succeeding. * Related #9 [ci skip]
|
Using certs that are signed by a local From what I can tell is that trying to use the Let me check a few things. |
|
It seems that it doesn't like our For comparison |
|
I've got it to work. It was checking the issuer and subject fields when validating. I need to make sure that these match when generating the certs. |
|
Ah yes I forgot about that. That's key. Because otherwise they won't match. You should make sure that the error reporting works and properly indicates what the crypto failure is if possible. |
|
Something worth checking is if the server presents 2 certificates, one signed with Ed25519 root CA, and another signed with ECDSA root CA, will a client that does not understand Ed25519 skip over the Ed25519 cert and go up the trust path of the ECDSA cert? If this is possible, we could potentially solve our browser problem in Polykey because browsers don't understand Ed25519 right now, and then we can present both certs. Furthermore since the certs would be presented as a concatenated file, another question would be whether the order of this concatenation matters... it's important to make sure that the client doesn't choke on a cert using a signature it does not understand and just skips to another cert. |
|
I need to review the possible errors for a failing connection. Any lower level error needs to be wrapped in a domain level error. |
* Fixed up tests to work with the ca certs. * Polykey generated certs now work with CA. * Related #9 [ci skip]
|
Stopping the |
|
Odd, the server connection takes about 3 seconds to end if the handshake fails using an Seems that the client ends the connection sooner when using OKP. This may be affecting the clean up logic. |
|
Looks like there is an underlying logic problem with handling the streams. More specifically, handling streams ending. I have a feeling it's related to the I think in general I need to review and refactor the event handling for send, recv, close, timeout and on_timeout. Double check they're all called as intended when intended as described by the docs. |
|
Upstream issue created at cloudflare/quiche#1489. |
|
I just double checked, setting |
|
While the client not failing creation due to the client certificate failing is annoying, it's not critical. The connection will error out due to a TLS failure soon after establishment. AS such, the problem is not critical for moving forward. I'll make an issue for tracking the problem, but otherwise we can more on from it. |
|
New issue created at #12 |
|
Ah so we ARE receiving the client certificate, it's just after the connection has 'established' due to the aforementioned bug. Timing wise, I think the certs are available the moment the frame containing them is processed. |
|
small todo
|
|
example packet logs Server authenticatesClient authenticatesBoth succeedServer fails TLSClient fails TLSBoth fail TLS |
Also updated tests to use them. Still a problem with the client verification always succeeding. * Related #9 [ci skip]
* Fixed up tests to work with the ca certs. * Polykey generated certs now work with CA. * Related #9 [ci skip]
|
Can you explain what the intended behaviour for each of the 6 situation is? |
Also updated tests to use them. Still a problem with the client verification always succeeding. * Related #9 [ci skip]
* Fixed up tests to work with the ca certs. * Polykey generated certs now work with CA. * Related #9 [ci skip]
CMCDragonkai
added
the
r&d:polykey:core activity 4
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.
We need to add tests to test these conditions. The tests should check for
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
TLScert arbitraries for testing #8Tasks
The text was updated successfully, but these errors were encountered: