logo~stef/blog/

tlsauth

2013-04-02

certificate in firefox I just released tlsauth, a lightweight implementation of a CA and supporting scripts and config snippets that should make TLS client certificate-based authentication a bit easier to set up. The current implementation works in nginx (if someone knows how to do this in Apache, please contribute).

I also provide Flask-tlsauth and Django-tlsauth bindings, available also on pypi. Both contain simple web-based Certificate Authority functions, like sending in CSRs, listing and signing them, and even something similar to regular user registration. With the only difference, that when you are finished registering you have to import the certificate.

So when you look at this from a traditional PKI perspective something is fishy. User registration, and I get a cert back? Wait a minute, shouldn't the CSR be submitted by the user in the first place? Yes. But. :) Considering this from a traditional user registration workflow, the user usually trusts the server with his secret, the password. With TLSAuth however the server drops the secret after creating it and sending it to the user. So with most users blindly trusting their service providers I assume they'll trust them also diligently dropping them. The certs are not very good for anything else than log in to the server. And the CA can produce certs as many as he wants anyway.

Why is this good?

No more passwords

Your users win, because now they only need a password for importing the key into their browser, and then it is protected by the browser master key. This also prohibits users to reuse the same passwords on unrelated sites.

You can also copy your key around and load it on different devices, if you want to be able to access the services also from them, but this only needs to be done once in each browser.

This means also automatic authentication on all services sharing the issuing CA with the clients issuer. This means you can log in to all services on various servers certified by your issuing CA.

With appropriate security tokens you can even store your keys on smartcards and keep you certificates safe from your browser.

No more user databases!

Server operators win because they do not need to store a user database! This removes all kind of privacy issues, and reduces the costs of database leaks considerably.

Your users always send their their TLS cert, which is signed by the CA - you. So when someone comes and says: "hey i'm Joe, here's a certificate about that from you", then you can be sure about it. ;) Also a cert can contain more information, like an email address, or even an real life address for shipping, etc. You decide when you sign your users certificates what your require them to contain.

Authentication on TLS level

You know your client before it even says "GET / HTTP/1.1". This means you can redirect your handler accordingly, showing static only content for unauthenticated visitors, full dynamic server-side scripting and security bugs for trusted peers, and maybe even IMAP or SSH for certain certificates. ;)

Why is this bad?

Bad Browser UIs

On the user side log out is kinda impossible currently. But there seems to be a key-manager for stock firefox - iceweasel is not supported :/ - that could be helpful with log out and other key management related tasks.

It would be nice if the vendors would put more effort behind improving their related user interfaces instead of slacking or reinventing existing protocols.

Losing your phone/tablet/laptop

Losing HW is always a bad thing, especially when you have your certificates on it, hopefully they are protected by a master password in the browser, and full disk encryption on the hard drive. But this should be standard anyway.

Deleting users

CRL or OCSP (and OCSP Stapling already supported in nginx) are the normal way to do this. The question is how to keep track of the serial numbers without exposing the privacy of the end users by keeping server-side database.

Protecting your own CA root key

This is something that kinda makes the operator the weakest link in the whole setup. If anyone has access to your CA signing key, they can MITM attack any connections of all browsers that trust this CA. So you should apply utmost key management security with air gaping and possibly use some kind of cheap HSM like a smartcard or even better.

Loose ends

I understand that TLSAuth does not solve all problems. But for small groups or projects TLSAuth might make a lot of sense. It's perfect for protecting a phpmyadmin from all the probes on the internet, and still make it available to the admins, or you can run your own webmail for all your family and not care about the web as an attack vector.

There's a few open questions and loose ends to be explored here. But I'm quite hopeful to use TLSAuth in future projects, maybe even Parltrack.

permalink


next posts >
< prev post

CC BY-SA RSS Export
Proudly powered by Utterson