RE: 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:address@hidden 
Sent: Monday, March 07, 2011 10:46 PM
To: peter williams
Cc: address@hidden
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)