[Freedombox-discuss] TLS handshake client credential/identity exposure

Daniel Kahn Gillmor dkg at fifthhorseman.net
Sat Jan 12 20:02:08 UTC 2013


On 01/12/2013 07:52 AM, Michael Rogers wrote:
> Good points. I agree that the double handshake's a better solution
> than trying to obfuscate the certificates.
> 
> Can the server's OpenPGP-based certificate be converted into an
> ordinary-looking self-signed cert for the outer layer of the double
> handshake?

Hm, this is a good question.  I don't see a reason that you couldn't
provide an entirely different certificate during renegotiation.  But i'm
not sure what you gain against a strong adversary, though.

If i'm understanding things properly, the server's initial certificate
(offered during the first handshake) needs to be something that the
client can use to verify the identity of the remote server, without the
client proving its identity to the server.  As a consequence, even if
you manage to encrypt the entire handshake in something like an anon-DH
exchange, it will be available to anyone making a request.  So while an
adversary might not be able to effectively snoop on the specific
connection, but they'll be able to initiate a connection to the server
and get the certificate.

A network-based attacker who can observe traffic can thereby observe
connections, and create their own connection to the server to see how it
is identifying.  So it seems like we have to treat the server's offered
certificate as a public, and clients (both legitimate and adversarial)
need to be able to identify the server properly from that certificate.

Is there a way around this constraint that doesn't amount to
security-by-obscurity?

If not, it seems to me like obfuscating the certificate might be an
interesting exercise, but one unlikely to hold up against a persistent
adversary who is willing to create or break connections in order to
discover the claimed identity of one party in the communication.

I'd like to be wrong about this (either for TLS or for any other
synchronous streaming protocol), or to understand ideas that might
mitigate these concerns.  But i think there's something fundamental
going on here related to identity/anonymity and mediated communications
between two parties who have no pre-established communications channel.

what do you think?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130112/3c4eb911/attachment.pgp>


More information about the Freedombox-discuss mailing list