Saturday, February 18, 2012

The need for SSH-like authentication in TLS

After the Diginotar CA compromise it is apparent that verifying web sites using only a trusted certificate authority (CA) is not sufficient. Currently a web site's certificate is verified against the CA that issued it and  checked for revocation using the OCSP server the CA set up. If the CA is trusted by the user, this process protects against man-in-the-middle attacks when visiting such a web-site, and also against leakage of the web-sites private key (e.g. via OCSP as long as the leakage is reported to the CA). This is an automatic process that does not require the user to be involved, but it comes at a cost. There is a single channel for verification, the CA.

The certificate based web-site verification tries to convert the trust we have in a merchant to the digital world. That is currently done by having "few" authorities that provide certificates to the merchants and based on those certificates we should base our decisions. However, trust in trade requires more than that. For example wouldn't it raise suspicions, a laptop from a merchant who approached you in a parking lot and provided you with a legitimate looking brand card? Would his business or credentials card be the only thing to check? Those heuristics are unfortunately not currently available in the digital world.

If it wasn't for the Chrome browser that implemented a preliminary version of key pinning, the Diginotar compromise might not have been uncovered. In the maliciously-issued certificates, the automatic verification procedure was not reporting any problems. It was the change in public key that triggered the key pinning warning and eventually to the Diginotar issue becoming public. Thus having an additional verification channel to standard PKI proved to be a success.

Key pinning, as of the 01 draft, is mostly server driven. That is, the user has very little control on trusting a particular server key if the server operator doesn't ask to. Another approach is the SSH programs' typical authentication method. The trust on first use. That describes the concept where the public key of the peer is not verified, or verified out-of-bound, but subsequent connections to the same peer require the public key to remain the same. That approach has the advantage that doesn't depend on the server operator setting up anything, but also the disadvantage that the user will be bugged every time the server changes its public key.

In any case having such methods to complement standard certificate verification and revocation checks, provides an additional layer of security. With such a layer, a CA compromise would not be enough for a large-scale man-in-the-middle attack since changes in the public keys would be detected and users would be warned. Such warnings might not be entirely successful in preventing all users from continuing but would raise suspicions for the legitimacy of the server, which might be enough.

For that, we implemented in GnuTLS a framework to be used either by applications that want to use key pinning, or a trust on first use (TOFU) authentication. That consists of three helper functions that store and verify the public keys. They can be seen in the GnuTLS manual. The included program gnutls-cli has also been modified to support a hybrid authentication that includes certificate authentication, TOFU and OCSP if the --tofu and --ocsp arguments are specified. The main idea of its operation is the idea discussed here and is shown in this example code at the manual.


  1. Hi Niko,

    I always thought that storing certificates in DNS while using DNSSEC is also an elegant solution to this. Of course you have to trust the dns server but it's also possible for the client to verify this in a number of ways. Since this is usually needed once per site (verified certificates can be cached), it should not be a problem.

  2. saI think that the whole model is flawed. X509 as it's used on web, obfuscates the distinction between two fundamentaly different aspects:

    1) Transactional security against eavesdroping ("small fury purple ricudia won't steal your password")

    2) Trust ("I am (Mitsos|A Big Fscking Company)", "You can trust *us* with your payment information", etc.)

    Perhaps what we really need to do is decouple the two. 1 could be handled by current means (or not), 2 could be provided by some "web of trust" or reputation building methods (though this opens a wholly different can of worms). The fundamental thing here is to make the distincion to users clear (what is "secure?").

    And yes, I understand that this could break the business model of CAs, CA auditors and other lamoya selling thin air, but let's consider this just as a happy coincidence :P

    Also, bloggers captchas SUCK.

  3. @V13, indeed DNS(sec) can be used as an alternative way to verify the public key of the server. I see this is already described in RFC6394, so it would be nice for applications to combine those heuristics in certificate verification.

    @Christos, hey indeed these are two pretty unrelated concepts, but (1) requires (2) in modern algorithms to prevent man-in-the-middle attacks. We have been pushing in gnutls openpgp certificate authentication, to take advantage of alternative trust models such as the web of trust for quite some time, without being able to take off (and CAs were not a serious obstactle on that). Thus, my impression is that any solution to fix current issues should be as an incremental change to the current model, i.e., by adding more heuristics to X.509 authentication.

  4. I'm using Certificate Patrol which monitor change on the remote certificate

    It's not complete behavor you described in your article, but it's a step forward (that should be the default behavor for browser)