Check for certificate revokation (related to OpenSSL Heartbleed bug)

[aef]

Please implement the Online Certificate Status Protocol (OCSP) in Psi to deny revoked server certificates. Also consider supporting OCSP stapling for efficiency. A detailed explanation follows:

When Psi connects through TLS, it receives the X.509 certificate of the XMPP server and verifies if it wants to trust this certificate. The certificate holds a limited range in time for which it is valid. If it is not expired yet and is signed by a certificate authority, the certificate is trusted if the certificate is signed by a trusted certificate authority (directly or through multiple intermediate authorities).

Now there are plenty of reasons why a certificate authority would want to revoke a certificate before it would expire by itself. Probably the most serious reason being that the private key associated with the certificate leaked to the public. The recent Heartbleed bug in OpenSSL allowed attackers for about two years to acquire the private keys of any TLS based service running an affected version of OpenSSL, which were estimated by some to be about one third of the Internet web services. Security researchers and certificate authorities all around urged people affected by Heartbleed to revoke all certificates.

Classically certificate authorities regularly issue certificate revokation lists (CRL). These are signed lists of not-to-be-trusted certificates even though they appear to be trustworthy on their own. Because CRLs were a pain in the ass to keep up to date, nowadays certificate authorities offer an OCSP service. If a certificate is sent to the OCSP service, the service responds with a signed statement if the certificate is still valid or not. The URL for the OCSP service is encoded into the issuing certificate authorities certificate.

When recovering from Heartbleed I noticed that Psi seems to neither look up CRLs nor to use OCSP to check for certificate validity. Psi will therefore trust any certificate that by itself appears to be valid. All of the certificates affected by Heartbleed and all other certificates which were willfully revoked by their owners for various other reasons are still trusted by Psi.

Imagine now some attacker used Heartbleed to acquire a certificate and the corresponding private key of an XMPP server. Up to the point where the server operator replaces the certificate with a new one, the attacker can decrypt communication between the XMPP and its clients. After the server operator exchanged the certificate with a new one and revoked the old one, the attacker could still fool Psi clients accepting him as man in the middle who again can eavesdrop every communication between the XMPP server and client. This is possible because the Psi doesn't realize that the certificate has been revoked by its owner.

In my opinion this is a big security problem and Psi should support OCSP.

The same problem applies to the voice chat tool Mumble which is also implemented in Qt. I found out that currently Qt's OCSP support is not production-ready but there is already a good foundation of code provided by Richard J. Moore. Please see the Mumble ticket for futher information.

[Neustradamus]

+1

[Neustradamus]

https://github.com/psi-plus/main/issues/593