certificate validation callbacks [was: Re: validating SAN URIs in gntls]

[peter williams]

SSL was designed according to the doctrine of mutual suspicion (each party assume the other is an active attacker). In the web, active attackers abound: they are called corporate firewalls :-). They take the SSL handshake including the self-signed cert from the browser's client authn, and spoof the browser endpoint to the intended site; presenting perhaps their own self-signed cert (since they cannot sign for the user) pointing in the SAN_URI to their own document.

Its true that the SSL patent (and all the various Netscape/IETF specs) distinguish between TLS protocols and [asymmetric] key management, with the latter being a matter for the application (GNUTLS library consumer). Lets distinguish correctly between the server, and the TLS lib/state. GNUTEST test server is the first such "server", supported by the latest GNUTLS lib.

Thus, it’s the GNUTLS test server (not the library) that is responsible for assuring the [asymmetric] key management - checking the self-signed cert, in this case.  If the server had a "wintrust type interaction" with the library, then server code might go further and do the full webid validation agent steps (or do PKIK PKI, or Netscape cert extensions, or...). As folks state properly, this validation will in the general case need the full ssl state for the connection ( => session) for each sessionid; and the server app needs to be able in any case to order a close, or an alert, or a new full handshake, or a resume.... etc, per sessionid as part of responding to what it determines, during validation of the [asymm] keys.

In the case of webid, that server code (implementing a particular validation model, somehow selected from n of them) has to not only check the self-signed cert, not only confirm pubkey exists in stored remote file, but confirm that the URI is part of an out of bound trust mesh (to address the corporate proxy simply swapping out one self-signed cert pointing to a document, for another).

So, I think I'm in agreement on all points.

1. its server's who do self-signed cert checking (and GNUTLS test server is probably one that should, or else just warn that it hasn’t)

2. its library/server API design that allows server to drive a validation process, for some asymmetric key management design (e.g. PKIX, webid protocol, .next)

3. the SSL state is what the server needs. Arguably, it needs a chain of states, those to which it has access rights because n connections (and their sessions) are all being bound to the very same server (vs TLS) endpoint, in the stack of the entity playing the SSL server-role.


-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: Monday, March 07, 2011 10:46 PM
To: peter williams
Cc: gnutls-devel at gnu.org
Subject: Re: certificate validation callbacks [was: Re: validating SAN URIs in gntls]

On 03/07/2011 11:37 PM, peter williams wrote:

> but it HAS to be self-signed, and be confirmed as such during SSL server procedures.

I'm afraid i'm still not following this argument.  We're talking about client-side authentication, and the cert in question belongs to the client in the TLS session?

I think the entire TLS handshake (up through and including the client-side cert) get certified by the client's secret key in the "certificate verify" message [0].  So the client is cryptographically
demonstrating:

 (a) control over the public key, and
 (b) a certification that covers the client certificate.

I imagine two types of threat we're concerned about:

 0) a network-based attacker who wants to use their own key in place of the client's key, and

 1) a network-based attacker who just wants to swap out the client's certificate with a different certificate (the replacement cert contains the client's own key).

In scenario 0, the attacker presents the server with a certificate derived from her own key -- since she controls the key, she can certainly make the certificate self-signed.  The validity of the self-sig on the certificate doesn't provide us with a way to distinguish the attacker from the client in this situation.

In scenario 1, the attacker is maybe trying to convince the server that the client is presenting different data from the data in the client's actual certificate.  The server could distinguish the two cases based on whether the certificate is properly self-signed (the attacker's bogus cert could not be self-signed because the client's secret key is unavailable to the attacker).  But since the client doesn't see the replacement certificate, its computed "certificate verify" message will not verify anyway.  So again, i don't think the validity of the self-sig on the certificate buys us anything in this situation.

Another way of looking at it: doesn't the "certificate verify" message offer an assertion that the client is vouching for the data in their certificate?  What additional benefits do we get from validating the self-sig on the cert anyway?

Can you help me understand *why* either party would care that either cert be self-signed if the session initiation has already established that both parties saw the same certs and are in control of their respective secret keys?

It's certainly possible that i'm misunderstanding something about how TLS works -- feel free to point it out to me, even if the flaw in my reasoning is glaringly obvious.  I can take it :)

Trying to understand,

	--dkg

[0] https://tools.ietf.org/html/rfc2246#section-7.4.8 (there are comparable sections in TLS 1.1 and 1.2)