Mumble: Check for certificate revokation (related to OpenSSL Heartbleed bug)

[aef]

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

When a Mumble client connects, it receives the X.509 certificate of the server via TLS 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 Mumble seems to neither look up CRLs nor use OCSP to check for certificate validity. Mumble 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 Mumble.

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

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

[tbuehlmann]

:thumbsup:

[mkrautz]

I think OCSP and OCSP stapling make good sense for Mumble.

The typical web browser criticisms about OCSP don't directly apply to Mumble.

Mumble primarily uses TLS for Mumble connections, and secondarily for web access (for fetching images from text messages, client updates, etc.). So an OCSP request that blocks the TLS handshake while we're waiting for a response isn't as lethal as it is in a web browser, because for Mumble, it primarily happens when connecting to Mumble server.

Another criticism is that OCSP to be generally useful, must "soft-fail" to be compatible with captive portals. I have my doubts that a server running a custom protocol on top of TLS on port 64738 will make any captive portal happy in the first place, so I'm not sure how much of a problem this is for Mumble.

However, right now, Mumble is using Qt's QSslSocket to implement TLS functionality both in the Mumble client and the Murmur server.

Unfortunately, Qt does not support OCSP or OCSP stapling at present. Here are the Qt issues that track OCSP and OCSP stapling:

https://bugreports.qt-project.org/browse/QTBUG-12812
https://bugreports.qt-project.org/browse/QTBUG-17158
(via https://qt-project.org/wiki/Improving_Qts_SSL_Support)

I think the way forward with OCSP support in Mumble would be for someone (presumably a Mumble developer) to contribute OCSP support to Qt.

If OCSP support went into Qt, it would go into Qt 5.

Right now, we're in the process of migrating to Qt 5 in Mumble itself (we're tracking the HEAD of Qt 4 at the moment). Mumble does build with Qt 5, but there are a few minor issues across all platforms which prohibit us from flipping the switch completely

So the Qt 5 transition is something we'd also need to finish before we could make use of any new OCSP features in Qt.

[aef]

Thank you very much for your quick and constructive answer. At least the Mumble project doesn't call people paranoid because they request state-of-the-art security features.

As for the progress of OCSP in Qt 5, this post suggests that a guy named Richard J. Moore has already been working on this since 2011. I will try to contact him to ask about what needs to be done to get this going into production.

[aef]

I've got response from Richard J. Moore about the topic. He has given me permission to post it here:

On 18 April 2014 20:48, Richard Moore wrote:

Hi Alexander,

The current state is as follows:

1. OCSP request and response parsing, conversion to Qt types etc. is done,
   so we can send and receive OCSP just fine, but...
2. Verifying of the OCSP response signatures is currently not working
   properly.
3. The encrypted() signal has been added to QNetworkAccessManager
   (requirement for nice integration).
4. The ability to pause the socket after the certificate verification is
   partially implemented, but currently only when there's an error. This needs
   to be done when there's no error too so we can send the OCSP request before
   anything is transmitted.
5. The cache of OCSP statuses is not started.

All of this is fixable of course, but I only have so much time to work on
things. At the moment I've focussed more on fixing various problems in the
existing functionality rather than adding more.

Cheers

Rich.

On 18 April 2014 15:55, Alexander E. Fischer wrote:

Hello,

I saw your efforts from 2011 on getting OCSP running in Qt 5. Thank you
for that. Qt based projects like the voice chat utility Mumble or the
XMPP/Jabber instant messengers Psi and Psi+ are now in dire need to
support OCSP to at least be ready for the next Heartbleed-like
disaster.

I myself am a regular user of these tools but I have only very limited
experience with C++ and Qt, making me a far from ideal candidate to
implement security features in such a widely used framework. Therefore
my idea was to try to get people talking about this again. Would you be
willing to explain what the current state of OCSP in Qt 5 is, so we may
actually get it to work in production? Should you be willing, please see
the following ticket of the Mumble project:
https://github.com/mumble-voip/mumble/issues/1231

Thanks in advance.

Alexander E. Fischer

[ELLIOTTCABLE]

:+1:

[Avamander]

LetsEncrypt can easily provide a certificate with the OCSP Must-Staple extension if OCSP were to be implemented it would be nice that that extension were to be respected as well.

[ancarda]

@mkrautz: The two bugs you linked to (QTBUG-12812 and QTBUG-17158) are now closed, so perhaps all we need to do is finish moving to Qt 5 (has this already been done?) and we're ready to implement this.

Implementing OCSP would be good for Mumble, and it might be something I could try to tackle. However, part of me wonders how useful it will be doing a single revocation check at startup. Unlike HTTPS, where connections are generally short lived, one might be connected to a Mumble server for many hours or days. Would it make sense to do regular checks every N minutes? My thinking is if a certificate gets revoked after connecting to a server, OCSP wouldn't be useful to you.

Does anyone know how Mumble reacts if the certificate expires while you're connected? If you remain connected today, this would stop working within N minutes since OCSP responses would indicate the cert has expired.

If we do go ahead with regular OCSP checks, I think the server should ideally do this for us - to preserve privacy. The server would check OCSP and push the response down to all connected clients. That'd basically be OCSP stapling. If a client doesn't get this after some set timeout, it could:

• Under normal circumstances: Check OCSP itself, disconnect, or do nothing (maybe have a client-side setting).
• With Must-Staple extension: Disconnect.

[Avamander]

Would it make sense to do regular checks every N minutes?

No. It wouldn't really protect against any attack, I think.

That'd basically be OCSP stapling.

OCSP stapling and must-staple are the exact things that it should support. E.g. when people reuse their LetsEncrypt cert with MS, Mumble should really be able to staple an OCSP response to the cert.

[Krzmbrzl]

has this already been done?

It has been done for the upcoming 1.4.0 version. All Qt4 code has been dropped in the current master branch, but the ongoing 1.3.x series still supports Qt4. But that's not an issue as it wouldn't receive this new feature anyways.

Does anyone know how Mumble reacts if the certificate expires while you're connected?

I don't _know_ it but my suspicion is that the cert is only verified at connection but once a client is connected the cert i probably not checked again.

If we do go ahead with regular OCSP checks, I think the server should ideally do this for us - to preserve privacy.

Isn't the server subject to this check in the first place? It seems a bit odd to rely on the server telling the client "trust me, my cert is fine" ^^
Besides: If the client was to expect this to be done and disconnect if it is not, it couldn't connect to servers running older versions of Mumble that don't know about this feature yet. :thinking:

[ancarda]

All Qt4 code has been dropped in the current master branch

Glad to hear this!

Isn't the server subject to this check in the first place? It seems a bit odd to rely on the server telling the client "trust me, my cert is fine" ^^

As far as I know, OCSP Stapling is simply a recent OCSP response (signed by CA - so can't be forged or tampered with) that is sent down to the client during TLS handshake. All it does is free up the client from having to talk OCSP itself. That means you won't hold up a connection waiting for a revocation check (performance) and you won't leak metadata to OCSP servers about who is using a specific cert (privacy).

OCSP _Stapling_ isn't a security feature, though OCSP is.

Besides: If the client was to expect this to be done and disconnect if it is not, it couldn't connect to servers running older versions of Mumble that don't know about this feature yet. 🤔

I would only disconnect if the client is either configured to do this or the certificate has the Must Staple X.509 extension but the server isn't actually doing OCSP Stapling. In that latter case, the server administrator hasn't configured the server properly (i.e. disabled OCSP Stapling or running an old version of Murmur).

Edit: Also, this whole thing only applies if you're using a cert that has OCSP. So, self signed certs won't be affected.

Currently, you have to opt-in to Must Staple with certbot or you have to generate a CSR that requests that extension. It's unlikely anyone would generate a cert with this requirement without understanding the implications.

If you want an example of a certificate with this extension, https://crt.sh/?id=3643115346 has it:

X509v3 extensions:
    X509v3 Subject Alternative Name:
        ...
    TLS Feature:
        status_request
        ^^ This is the Must Staple extension

You can connect to this Mumble server at mumble://hedonics.org:64738 if you want to test.

[Avamander]

I would only disconnect if the client is either configured to do this or the certificate has the Must Staple X.509 extension but the server isn't actually doing OCSP Stapling.

I'd display a very strongly worded warning, OCSP isn't enough nines reliable yet to unequivocally disconnect on each failure or lack of stapled response.

[Krzmbrzl]

Okay then this sounds good to me :+1:

[MaxwellCody]

I'd display a very strongly worded warning, OCSP isn't enough nines reliable yet to unequivocally disconnect on each failure or lack of stapled response.

I think a strongly worded warning is advisable for a failed OCSP check--since OCSP is an online check with the CA, that makes it, at least partially, out of the control of both the user and server operator.

However, I think a disconnect would be the best choice for when Must-Staple is specified but then isn't fulfilled, as this is (usually) indicative of a fixable configuration issue.