teddziuba / pqauth Goto Github PK

The only test now is for the "happy case", so I should probably test some error conditions. But nothing ever goes wrong in production anyhow.

I'm filing this as an issue to fix the README text.

They are nearly impossible to use. Seriously. Try it some time, it will make you want to stab yourself in the eyeball with a soldering iron.

I've deployed it extensively across Ruby (Chef), Java (Jenkins auth server, Jenkins notification client, and soon Cassandra), Python (multiple clients and Twisted server), C (libcurl client and libmicrohttpd server), PHP (curl and stream wrappers), Erlang (RabbitMQ auth), node.js (client), shell (wget and curl), protocol-independent tunnels (stunnel and OpenVPN), and client browsers for desktop (Firefox, Safari, and Chrome) and mobile (Android). I hear iOS has solid support, too. At a minimum, I've worked with the underlying SSL/TLS implementations known as NSS, OpenSSL, GnuTLS, and Java. So, I think I can talk with authority about the complexity and capability of the model.

There's a ton to learn -- took me months -- but it works across all of those as a unified approach. And now, I can access every operational resource for my company with the certificate I've installed on my laptop and phone. Anyone deploying additional resources can do so by installing a single public certificate key, and anyone at the company can authenticate.

If you're looking for a runner-up with broad HTTP(S) support, OAuth has good library support across languages. Like pqauth, though, it's inherently limited to HTTP(S) because it doesn't allow protocol-neutral wrapping like SSL.

And then, get your load balancer or HTTP server to pass the client identity information along to the app. It's brutal.

If you mean the IP address, having the load balancer terminate SSL does that. That won't usually work for client certificate auth, but client cert auth provides a much stronger client identifier, anyway.

You can't extract a session key. After the SSL/TLS negotiation is done, the client and server share a secret, but this is at the transport layer, and you can't really get at it from the application layer.

I'm sure it's possible to get in many cases, but the SSL/TLS session identifier wouldn't be that useful unless you have one backend or coordination for sharing the session data. We tend to use the DN (less unique) or client certificate fingerprint (more unique) if the server and client are mutually authenticated. Otherwise, we use the old, reliable standby of cookies.

You need a certificate authority to sign client certificates.

This is just false. You can roll entirely self-signed for certificates, and it works just like SSH keys, with all the attendant disadvantages listed in the next section. Just like SSH keys, the public side of each certificate pair must be listed as trusted on the server, CA-style, or there must be some other lookup method. This is how Freenode IRC handles its SSL-based authentication; you give them the fingerprint of your self-signed certificate. Tiny Tiny RSS also supports this sort of CA-less authentication-by-fingerprint.

Also, to show the equivalence, you can even use the same key pair for both SSL and SSH by generating a self-signed certificate, using the PEM-format private key for both, and extracting the SSH-style public key:

ssh-keygen -y -f my.key > ~/.ssh/id_rsa.pub

Sure, you could start up your own CA to sign your client certs, but at that point, you're just using a CA to satisfy SSL's bureaucracy instead of as an actual source of trust.

This is also false. Running your own CA for your users or users of your API has major distinguishing advantages for regulating trust.

1. It's possible to distribute the CA's public key to multiple places in order to authenticate any certificate signed using the private key. SSH-style infrastructure requires access to every public key in any place where the key pair might be used. You could use a trust signing mechanism, like GPG does, where you distribute signatures from trusted key pairs alongside your key data, but that's essentially redoing x.509 if there's only one root of trust.
2. You can bake a revocation URL and an expiration date into certificates you sign -- or not. (You technically have to include an expiration date, but it could be after we're both dead.) SSH-style key management requires removing the public key from each machine or lookup service that may distribute it as "trusted."
3. Certificates can embed more information as signed data in their fields. For example, our certificates identify whether the client is a human or an automation tool. Thus, certificates can include capability and accountability data. Again, this is optional. SSH-style keys can only identify the client as a key-holder for a specific public key.

Seems easy enough, use Crypto.Random.random.getrandbits(128) and construct a new uuid.UUID around those bits.

The keys in the JSON objects aren't right.

Also, you need to explain how to marshall the flow server-side by using the server's GUID.

Create a Django app that includes Authentication middleware and backends for pqAuth.