How does Tunnelblick handle server certificate revocation?

[ack]

I was reading through the Tunnelblick documentation, and was unable to find details on how it handles revocation of a server certificate, such as an intermediate signing certificate or an unexpired leaf certificate for a VPN server.

If it does respect CRLs, how does Tunnelblick learn of the CRL in the first place? Does it expect a configuration file on disk a file that contains the CRL? Does it accept a configuration option for locating a CRL file hosted elsewhere (and if so how does Tunnelblick validate the CRL is valid)? Does respect a CRL Distribution Point extension field in the server’s certificate (or of an intermediate’s cert in the cert chain, or in the root cert)?

[Tunnelblick developer]

Tunnelblick does nothing with CRLs; it's done within OpenVPN.

See the OpenVPN man page for details, particularly the --crl-verify option.

Usually CRLs are implemented in the server, not the client. Because Tunnelblick is primarily for clients, my guess is that Tunnelblick might not be able to install a CRL that is a directory (instead of a file). But that's just a guess; you'd have to try it.

[ack]

Thanks!

So what happens if the OpenVPN server certificate is compromised, but not the intermediate signing certificate?

And what happens if the intermediate signing certificate is compromised, but not the root certificate?

[Tunnelblick developer]

That would depend on the client's OpenVPN configuration file. Consult OpenVPN experts about that. See Tunnelblick Support for some links.

[ack]

While OpenVPN may have some responsibility here, it's *tunnelblick's* responsibility to have *some* recommendation for how to handle server certificate revocation.  Tunnelblick needs some way to be told not to trust the server certificate - else clients will continue to trust the compromised server cert and will continue to connect to servers using the compromised server cert - now potentially the attacker's system instead of the real system.

How would one go about removing the trust chain to the no longer trusted server cert, within Tunnelblick?

[Tunnelblick developer]

Our recommendation is to use OpenVPN's certificate revocation mechanism, as I have written twice before.

I disagree that "Tunnelblick needs some way to be told not to trust the server certificate".

Instead, solve the problem (a compromised certificate) by replacing the client's OpenVPN configuration file to use a new, trusted, certificate.

[ack]

Thanks!  I appreciate you taking the time to help me figure this out.

I've read OpenVPN's documentation and their cert revocation only appears for revoking client certs, not for revoking server certs.  It therefore doesn't look applicable for revoking server certs.  I also reached out to OpenVPN per your recommendation, to see if they have any additional advice.

> solve the problem (a compromised certificate) by replacing the client's OpenVPN configuration file to use a new, trusted, certificate

Awesome!  So it sounds like the tunnelblick trust store would have to be updated so that it contains either (a) only the new server cert, or (b) a new intermediate cert that was never used to sign the compromised server cert, or (c) a new root cert that was never used to sign any cert in the chain from which the client cert exists.

That makes me wonder: Is it a Tunnelblick best practice to only include the server (leaf) certs, not anything in its certificate chain in the Tunnelblick configuration / trust store, in order to minimize breadth of impact if a certificate is compromised (roughly equivalent to pinning to the server cert)?  This would insulate entirely against the root's or intermediate's private keys being compromised, and would avoid having to reconfigure / replace trust stores in unaffected tunnelblick configurations in the event of a breach, in exchange for higher maintenance costs for maintaining tunnelblick configurations for regular certificate rotation periods.

[Tunnelblick developer]

You seem to be under the impression that Tunnelblick  has a "trust store" -- it doesn't, and that it evaluates certificates -- it doesn't. OpenVPN is the one that evaluates certificates. Technically, OpenVPN uses OpenSSL to do the actual work of evaluating certificates.

Tunnelblick stores configurations, which can be simple OpenVPN configuration files which may or may not imbed certificates within the files themselves or include certificates as separate files. Configurations can also be more complex, with related information including version info; see Tunnelblick VPN Configurations Details. But Tunnelblick doesn't do anything with certificates other than move them around, copy them, secure them, etc.

OpenVPN is the one that evaluates certificates. Technically, OpenVPN uses OpenSSL to do the actual work of evaluating certificates.

There is no "Tunnelblick best practice" about certificates because Tunnelblick doesn't do anything with certificates other then store them as separate files if the OpenVPN configuration has them as separate files.

ALL of your questions about certificates and the best practices regarding them should be directed to OpenVPN (or possibly OpenSSL) experts.

[ack]

So, if Tunnelblick has no trust store and doesn't evaluate certificates, how does it know that it is connecting to the correct OpenVPN server, and not some attacker's server?

[ack]

(I'm under the impression that Tunnelblick is VPN client software that connects to OpenVPN to establish a VPN connection.  Is this incorrect?)

[Tunnelblick developer]

Tunnelblick doesn't know if it is  "connecting to the correct OpenVPN server and not some attacker's server".

OpenVPN may or may not know if it is "connecting to the correct OpenVPN server and not some attacker's server"; that depends on the OpenVPN configuration.

The statement that "Tunnelblick is VPN client software that connects to OpenVPN to establish a VPN connection" is close but is a tiny bit misleading:

• Tunnelblick can also be used for rudimentary control of VPN servers, not just VPN clients.
  
• Tunnelblick includes several versions of OpenVPN, which it interacts with to establish and control  one or more VPN connections. (It doesn't connect to some pre-existing, external OpenVPN.)

[ack]

> Tunnelblick includes several versions of OpenVPN, which it interacts with to establish and control  one or more VPN connections. (It doesn't connect to some pre-existing, external OpenVPN.)

Oh!!!  Now I get it!  I'm sorry!  Now I understand why my questions aren't applicable for Tunnelblick.

Sorry for wasting your time on this & thank you for helping me understand how things work better!

[Tunnelblick developer]

No problem. Maybe this discussion will help someone else better understand what Tunnelblick is.

One clarification to my earlier comment that Tunnelblick doesn't connect to a pre-existing, external OpenVPN: Tunnelblick can use OpenVPN binaries that are not built into the copy of Tunnelblick being used. The binaries must specially named, and must be stored in a  special Tunnelblick folder. See Using Custom OpenVPN Binaries for details. They can be binaries from some other source, binaries that have been custom-built, or copies of OpenVPN binaries that have been extracted from other versions of Tunnelblick. (For example, you could use an old, obsolete, unsafe version of OpenVPN that Tunnelblick no longer includes if that version is needed to connect to old hardware. We don't recommend that, of course, but we allow it.)