TLS authentication scenarios

Transport Layer Security is used all over the web today to secure traffic to https websites.

We can use TLS for peer-to-peer communications. To do so it’s important to understand TLS itself first.

In your browser right now

In most cases on the Internet, TLS is used to secure connections issued by a client to a server.
The client requests the server certificate. Upon receiving the certificate, it checks it matches the server information and was issued by a root CA. The certificate points to the root CA which must be installed on the user machine.

TLS is also rarely used by a server requesting to identify clients connecting, by requesting their certificate and checking it.

For peer-to-peer communications, you’d ideally want both.

What if we have no root of authority

Most of the time it’s ok to use a CA and pay a fee to be issued a valid certificate.
You can also decide to create your own CA and distribute the root CA certificate to all the machines in the network. You will need to think about expiration and rotation of the certificate.

Pragmatic approaches


SSH uses a known_hosts approach to store the identity of the hosts. If you try to connect to a known host, and a man-in-the-middle attack occurs, trying to intercept the connection, that attempt is detected.

TOFU stands for “Trust-On-First-Use”. This approach stores a hash of the certificate in a file associated with the information of the peer connecting.


This approach allows specifically some hosts and certificarte pairs to connect to the peer.

CA, and all those, too

You can combine those approaches with trusting your computer’s root of trust.

Mapping a peer identity

When connecting to a server, it is easy to associate the certificate to its host and port.

When identifying a client, it is impossible to identify the originating host and port - NAT is involved usually, and most TCP connections will use a different socket over time. In that case, it might be worth keeping track of the certificate.

More on certificates

You can store actual data signed in certificates, as used by the extended validation certificates, which store the name of the company to which the certificate is issued.

It should be possible to use certificate entries to store all sorts of interesting metadata for the purpose of identifying peers, the network they seek to join, or a role in the network.