search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.26k stars 1.11k forks source link

Check for certificate revokation (related to OpenSSL Heartbleed bug) #1231

Open aef opened 10 years ago

aef commented 10 years ago

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 commented 10 years ago

:thumbsup:

mkrautz commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

:+1:

Avamander commented 5 years ago

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 commented 3 years ago

@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:

Avamander commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Okay then this sounds good to me :+1:

ElizabethCody commented 3 years ago

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.

S-S-X commented 7 months ago

disconnect would be the best choice for when Must-Staple is specified but then isn't fulfilled

Second that. If certificate is flagged with Must-Staple then OCSP response should definitely be stapled by Mumble server.

Additionally my thoughts about what could and what should be implemented:

Good to remember that there's OCSP requests, OCSP stapling and OCSP Must-Staple, these are three different things and do not have dependencies other than Must-Staple flagged certificate should have OCSP stapled in response.

Personally I think OCSP requests probably do not even have to be implemented client side. Only server side for stapling (requests possibly for automated refresh) and client side to check stapled responses (but no requests at all). Basically only support what is needed for stapling to be useful.

Neustradamus commented 4 months ago

To follow this important ticket.