TLS Certificates

[HOGGL]

This issue is to brainstorm ideas to solve customer certificate generation. We are unable to just distribute an included certificate as it can only apply to predetermined hostnames and cannot be changed. Generating them per-customer would also be an obvious security risk.

I propose that within the web UI on first run, there is a button that can generate a free Let's Encrypt certificate for that device using certbot.

[psymin]

I agree that Let's Encrypt could have a place in this project.

I believe that self signed certs are a better option if they can be made to work seamlessly in this ecosystem.

I worry about relying on a 3rd party centralized system like Let's Encrypt perpetually.

If it can be done without Let's Encrypt I think LE should be avoided.

[meathunter]

The challenge with self signing is they then need to be added to the trust store on the local machine. On Windows this is relatively straight forward, but still a manual step required, and on *nix variants it's much more of a pain.

A solution could be that the ssl certificate installation/management is included as part of the Client VPN software. When you install, or connect to a new node, it could download the cert and prompt the user to install into the trust store automagically.

[rynomad]

node to node self-signed cert exchange has been successfully prototyped. The problem with letsencrypt is that you then also need a domain name, which gets us down another rabbit hole entirely. An earlier version of this RFC had a whole notion of "coordinator nodes" that would provide dynamic DNS and proxying for letsencrypt, but it was introducing a lot of complexity and vulnerability.

as for client side, I think @meathunter has the right idea. If possible, we could go one further, and embed a webview with custom ssl handling. I think it's unlikely that we'll be able to get a great user experience trying to inject into the trust-store, but I could be wrong

[HOGGL]

I completely forgot about the Let's Encrypt ACME protocol. I found this but it's a shame no browser supports it:

Usually, TLS uses only public key certificates for authentication. TLS-SRP uses a value derived from a password (the SRP verifier) and a salt, shared in advance among the communicating parties, to establish a TLS connection. There are several possible reasons one may choose to use TLS-SRP: Using password-based authentication does not require reliance on certificate authorities. ...

I agree that a desktop application would fix these issues but isn't the focus mobile users? Having installed self-signed certs on Android, it takes every opportunity to tell you your network is insecure. Even adding a message on the pull down menu. This is obviously bad UX but I don't see a way to fix that other than publishing an app on the app store. But that's just waiting to be censored.

[rynomad]

I've done only a first pass evaluation, but the app approach of sourcing and then coupling a self-signed cert to an embedded webview seems attainable in a way that doesn't trigger any of the "your connection may be insecure" warnings (including on mobile). I would very much like to validate/invalidate this with running code ASAP though.

You are right that this replaces the centralization of ICANN/LetsEncrypt with the app store, which is arguably worse. However, it's important to note that in this model, the app isn't strictly necessary. It's merely a UX affordance. In the event that an app store pulls the app, the entire flow could still be completed manually with the same result, using apps that are virtually guarunteed not to be pulled (generic wireguard VPN client, system trust store, and any web browser).

There's a general principle at play here that is likely to show up elsewhere. I've been calling it the ejection or push-start principle: It's OK to leverage a centralized tool so long as nothing about the integrity of the system is dependent on that tool. In this case, an app that encapsulates the VPN and TLS cert offers convenience, but it's like the starter motor in a car... If it goes away, everyone can consult their owners manual and push-start to get to the same place they were before.

@HOGGL are you on our matrix chat? If so, ping me and lets brainstorm more. If not: thanks for participating, nice to meet you and email me for an invite :)

[HOGGL]

I 100% agree with the push-start principle. Sometimes it's best to get to good enough and then work out the rough edges. I'm not fond of 'bikeshedding' and being stuck in the planning phase for ages with nothing to show for it. I'm not in the matrix chat so I'll send an email shortly.

[mikedilger]

I'm going to leave a comment here about certificates and how messed up of an idea they are (actually they are a lot more messed up but this would be a book if I went into detail), and what might be a better solution. I've been involved with X.509 related stuff since about 1999 professionally at Sun Micro, Pfizer, and DHL, but not much recently. I've thought a lot about this stuff, but mostly long ago.

In a public key cryptosystem, each entity has a key pair consisting of a public key and a private key. To interact with an entity you need to know their public key. But how do you know if a public key belongs to the person claiming it belongs to? You might be interacting with an impostor. Certificates therefore arose as the following idea: If everybody trusts a centralized certification authority (CA), they can create digitally signed documents that pair official names with public keys. The X.500 directory system came into play with X.509 format certificates. But X.500 is long dead. We instead use LDAP or DNS. For TLS, official names became DNS names. Browsers came onto the market and decided to sell access to their trusted certificate databases. We now have hundreds of supposedly publicly trusted certification authorities, including Let's Encrypt. Let's Encrypt verifies your identity by doing an online test to determine if you control the DNS domain you claim to be by issuing you a random token that you expose under that DNS domain.

This entire mess could be replaced and decentralized if people simply published their public keys under their DNS domain as a TXT record. It provides the same level of identity verification. No certificates are required. No third party authority is required.

Unfortunately a plethora of software expects and requires X.509 certificates. There are ways to appease such systems: have them trust a single CA which is a local software component that manufactures certificates just to appease such software components.

Now, I know you guys also don't like that DNS is centralized authority. So that's fine, but then the solution IMHO is to not even associate public keys with anything. The idea then would be (1) Learn a public key and construct the concept of a foreign identity that you know nothing about and give no trust to, then (2) Start learning about that entity via that secure channel and assign trust and learn who they are entirely under that secure channel.... rather than trying to tie information you learned about someone via an insecure channel (twitter, facebook, etc) to a public key. [People could tweet their public key, or post it on facebook too, if that helps jumpstart trust].

A practical problem with this is that sometimes people lose their keys, so public keys can't directly be IDs. There are mitigations, but I don't want to talk your ear off right now.