💾 Archived View for tilde.pink › ~maria › log › 2021-08-20_sad_panda.gmi captured on 2023-09-28 at 16:29:56. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

sad panda

Anyone that has never heard of this phenomenon, it's a website that shows a sad panda unless you have a certain cookie set. The panda site will usually feature content that is arguably interesting for a certain crowd.

The last sad panda I found was related to a bunch of japanese adult comics. Not something "critical" to state security. Just a place where people could share them and comment and rate them.

In geminispace this is a lot easier to achieve than doing cookie-magic. You can just create your own root cert authority and distribute the client certificates. I did this whole think out of curiosity. And so I thought I'd document this here, maybe someone feels inspired to build something from it. Who knows.

Regarding authorization: when you terminate ssl within your load balancer, you have no way to get the certificate into your application. Maybe this doesn't matter, maybe it does. I'll be suggesting something later.

Assume your door is hosted here:

gemini://panda.example.com

Proxying I did with haproxy

frontend  main
    bind :1965 ssl verify optional crt /my/path/cert/haproxy/panda.pem ca-file /my/path/cert/haproxy/capanda.pem
    mode                 tcp
    log                  global
    option               dontlognull
    maxconn              80
    timeout              client  30s
    use_backend panda if { ssl_fc_sni -i panda.example.com } { ssl_fc_has_crt } { ssl_c_verify 0 }
    use_backend sadpanda if { ssl_fc_sni -i panda.example.com } !{ ssl_fc_has_crt } || !{ ssl_c_verify 0 }

backend panda
    mode        tcp
    balance     roundrobin
    timeout     connect 5s
    timeout     server  5s
    server      panda1 127.0.0.1:9002 check

backend sadpanda
    mode        tcp
    balance     roundrobin
    timeout     connect 5s
    timeout     server  5s
    server      sadpanda1 127.0.0.1:9003 check

This uses verification on client certificates when they are presented. The ca-file is the self-signed ca authority. And it only lets those certificates in that verify against the ca. There is also a deny-list for certificates that have no longer access, which I didn't implement here, but it's in the haproxy documentation.

When a client certificate is verified the request will route to the panda backend, otherwise it will route to the sadpanda backend.

To build your own certication authority, well. There's tutorials on that. Or send me mail, I can provide a script.

Finally, regarding authentication. There is such a thing called wildcard DNS record. It takes a DNS and every subdomain get relayed to the parent. Basically a catch-all. Together with SNI you can do something like this:

gemini://<client cert sha1>.panda.example.com

And haproxy can check via SNI whether the client cert verifies and its sha1 matches the wildcard. In your application you then access the request and know from which "user" this is. This way every certificate has its own door through the gate.

While this is pretty neat, I am not sure if geminispace needs a walled off, secret community. We're pretty small and have discovery issues as it is. Small communities generally have less need to shard into smaller, exclusive communities. Any how, if you have an idea, how to use this, let me know.