SSL: certificate pinning

[ilf@…]

Currently, SSL certificates are verified via domain name and X.509 Certificate Authorities. I'd like to bypass both via certificate pinning.

I propose an account setting "tls_fingerprint", taking the SHA1 of a certificate.

That way, I can manually enter one specific fingerprint for this account, not having to trust the CA-cartel. And I can verify it against an IP, not needing DNS.

I also propose to use "trust on first use" for all new accounts, showing the fingerprint and saying "is this really the fingerprint you want to trust" like OpenSSH.

[ilf@…]

After all the NSA revelations, I wanted to open a ticket for this, and realized I had already done it a year before the Snowden leaks started. Maybe someone(TM) will want to have another look at this?

Other developments in the meantime: ​http://tack.io/ ​https://tools.ietf.org/html/draft-perrin-tls-tack-02

[dx]

uhhh, patches welcome.

[dx]

FWIW, you get this when using libpurple, and i'd love to have this at some point without it, but I looked at how libpurple does it and it's a huge chunk of complicated SSL library code. I'll give it a look some day.

[dx]

I'm going to need to do this at some point as part of bigger certificate validation related changes, so bumping priority back up.

I think it doesn't need to be as complicated as what libpurple does, but still would require annoying changes to the ssl api. I hate API stuff. I'll try to figure out a way to avoid them.

[ilf]

Another bump for this. People have just discovered Tor-Exit-Nodes actively attacking XMPP-Connections with Man-In-The-Middle TLS-Attacks, exactly what pinning prevents: ​https://tech.immerda.ch/2016/03/xmpp-man-in-the-middle-via-tor/