Re: How to reject a certificate with access_denied?
On 07/06/2022 15:02, Matt Caswell wrote: > > > On 07/06/2022 13:46, Michael Richardson wrote: >> Matt Caswell wrote: >> > On 06/06/2022 18:08, Christian Schmidt wrote: >> >> Hi, >> >> I am building a server application that allows a user to log >> in by >> >> providing a certificate. In order to do custom checks, I have >> added a >> >> verify callback to my code to check the certificate on top of its >> >> cryptographic features (CA Valid, etc). >> >> If the certificate does not pass my extended checks, I would >> like to >> >> return the access_denied alert as per RFC8446 section 6.2: >> >> access_denied: A valid certificate or PSK was received, but when >> >> access control was applied, the sender decided not to proceed >> with >> >> negotiation. >> >> However, I can't find a way to generate this alert in openssl, >> although >> >> openssl can handle receiving it. >> >> How do I make a callback return a non-defined (as in not >> defined in the >> >> headers) alert? >> >> > This is not currently possible. >> >> > OpenSSL has an internal table which maps verify errors to TLS >> alerts: >> >> > >> https://github.com/openssl/openssl/blob/9f3626f2473bdce53e85eba96e502e950e29e16f/ssl/statem/statem_lib.c#L1350-L1394 >> >> >> > Unfortunately there are no entries in this table that map to the >> > access_denied alert. >> >> Would extensions to this list be welcome? >> Should Christian send a PR? > > I would be happy to review such a PR - although it would only be applied > to master and not 3.0 or 1.1.1. Any PR could only be in the form of > additions to the table (not modifications to existing entries), so as > not to break existing behaviour. By PR, do you mean Problem Report or Pull Request? Because after reading up on it, it seems that a Pull Request would require a CLA, and I am not willing to sign any contract under US law (I have no idea of implications, and a lawyer to explain these is not reasonably affordable for roughly two LOC). The things I know it for are unreasonable laws (I suppose an Access Denied alert might be patentable/copyrightable under US law, while it wouldn't under EU law), ridiculously off compensations (which seems a risk to me - I do no know if someone holds a patent/copyright on the alert from the RFC, and do not know how to check), and violating Europeans' constitutional laws (see the discussion around safe harbor agreements / GDPR). Best regards, Christian
How to reject a certificate with access_denied?
Hi, I am building a server application that allows a user to log in by providing a certificate. In order to do custom checks, I have added a verify callback to my code to check the certificate on top of its cryptographic features (CA Valid, etc). If the certificate does not pass my extended checks, I would like to return the access_denied alert as per RFC8446 section 6.2: access_denied: A valid certificate or PSK was received, but when access control was applied, the sender decided not to proceed with negotiation. However, I can't find a way to generate this alert in openssl, although openssl can handle receiving it. How do I make a callback return a non-defined (as in not defined in the headers) alert? Best regards, Christian
Re: SSL_connect with TLS 1.3 and client Certificates
On 14/07/2021 13:31, Matt Caswell wrote: > > > On 13/07/2021 19:44, Christian Schmidt wrote: >> Hello all, >> >> I am currently trying to build both client and server of an application >> that uses TLS 1.3 and mutual authentication using certificates. The >> application works so far - I can establish connections, certificates are >> verified, data is successfully transmitted, etc. >> >> However, I have an issue, or maybe two. >> >> 1. SSL_connect returns successfully before the client certificate is >> sent from the client to the server. The client certificate is only sent >> on the first SSL_write_ex with > 0 bytes, and as such, at this point the >> server can generate SSL alerts like access denied, etc. > > TLSv1.3 supports two types of certificate request. It can occur during > the initial handshake, or it can occur as a post-handshake request. It > sounds like you are doing the latter, but you want the former. Is that > correct? > > What are you doing in your code to request the certificate from the client? I may have interpreted what I was seeing wrong. I was assuming that openssl was sending the client certificate together with the first data frame, but it seems that some coalescing happens on the kernel side, causing the server to retrieve both SSL records at once. The asynchronous nature of TLS implies that after sending the client certificate, SSL_connect() does not have to wait for a positive confirmation. Adding a sufficiently large usleep() between SSL_connect() and the first data record makes this visible. Please ignore my question. Best regards, Christian
SSL_connect with TLS 1.3 and client Certificates
Hello all, I am currently trying to build both client and server of an application that uses TLS 1.3 and mutual authentication using certificates. The application works so far - I can establish connections, certificates are verified, data is successfully transmitted, etc. However, I have an issue, or maybe two. 1. SSL_connect returns successfully before the client certificate is sent from the client to the server. The client certificate is only sent on the first SSL_write_ex with > 0 bytes, and as such, at this point the server can generate SSL alerts like access denied, etc. 2. When trying to benchmark latency on the application, the first roundtrip is extended by the client certificate verification. Is there any way I can complete the handshake, and thus validate the full connection, without sending data? I must say that even after reading RFC8446 I am not sure if there is a positive confirmation after the client certificate is sent, so I am not sure if what I am asking for is even possible. Best regards, Chris
