Open EP-u-NW opened 3 years ago
I assume the X509* functions are OpenSSL ones? :eyes:
Oh yes, forgot to mention that 😅 Doing quite much OpenSSL atm...
So we want to start working on this, but I read some issues/discussion posts about a complete server rewrite. Can you give a short introduction about that? Might it be better to wait with implementing crl until the rewrite is done and implement crl support there?
There are no plans on a server rewrite. The topic was brought up once but after some discussion we concluded that a step-wise refactoring is the way to go.
Very important!
It is currently not possible to add CRLs (certificate revocation lists) to a server. The problem here is that Qt doesn't allow adding a crl to a
QSslConfiguration
orQSslSocket
.CRLs seem to be a bit outdatet in favour of the Online Certificate Status Protocol (OCSP). Boldly spoken, in OCSP a certificate contains a link to a place where a CA publishes a CRL so that the peer receiving the certificate can follow this link and check the newest CRL from there. OCSP is discussed in #1231 but from an other perspective: In our case, the mumble server is the certificate receiving peer (in form of user certificates), not the mumble client (as in #1231 with the servers certificate).
For user certificates a CRL might actually be better suited then the OCSP and could act as additional blacklist.
The best solution for this would be to contact Qt and ask them to implement CRLs, but it seems that is out of Qt's scope. In the meantime, we could try validating the client certificates manually after the actual ssl handshake, e.g. if an authenticate message arrives.
The general scheme could be something like:
Honestly, I don't know the performance implications of doing this manually instead of openssl doing this for us...