Hi,
Can you please consider enabling these three privacy and security technologies on the Graphviz sites? Let me know how I can help, be it by generating the records, testing, or something else.
Thanks for your consideration
The site is hosted on GitLab Pages and GitLab handles the certificates for us. GitLab probably doesn’t support stapling, I don’t know.
I had a quick google of these terms but couldn’t quickly find out what the benefit to supporting them would be for us. Maybe you could help explain?
If it’s not within your control, OCSP stapling is not a huge deal. It’s the modern way to do certificate revocation checking. It is much more efficient on the network than forcing clients to do CRL or OCSP lookups on their own, and it’s more privacy-friendly since the OCSP service doesn’t get to know the time and location of every client. OCSP is courteous; it’s being a good steward to the clients. It puts other revocation checking mechanisms to shame.
DNSSEC and DANE are DNS technologies, so even though you use GitLab Pages, and even though they manage the certificate for you, you can still realize its benefits. DNSSEC makes DNS spoofing effectively impossible, making every connection building on it more secure. Furthermore, DANE (which requires DNSSEC) allows you to leverage the fact that you now have a reliable DNS, to create a new anchor for public key infrastructure. This allows validating the authenticity of domain-validated TLS certificates using DNS alone instead of the often-criticized conventional certificate authority system.
You should still seriously consider enabling DNSSEC; it’s probably as simple as flipping a switch. DANE will be a little harder since GitLab takes care of the certificate generation for you, and I take it you don’t want to update the TLSA records by hand every three months. If GitLab always re-uses the same public key when requesting new certificates, then you can put the public key hash in the TLSA record and you won’t have to update it, not even when you get a new certificate.
That’s a big “if” and is something I’ll be glad to research. Certificate Transparency should make it easy to see if that’s the case with previously-issued certificates.
In conclusion, anybody with a domain name serves to benefit from DNSSEC; there’s no reason not to use it and there’s only benefits. It’s automatic and doesn’t require management. All you typically have to do is turn it on.
DANE will require more research on my part, and I’ll post here with my findings. OCSP stapling would be nice to have; it’s the friendly thing to do. If that’s out of your control, then I’ll direct my request to the GitLab folks.
Okay, I made a post on the GitLab forum here about the issues with DANE. It turns out they are changing the public keys, only sometimes, but sometimes is enough to mess with us.
Hmm, the GitLab docs seem to suggest that you can choose to use your own certificate and that the Let’s Encrypt option is merely provided as a convenience. I, obviously, did not make the Graphviz website, and I also don’t have access to tinker with it, so unfortunately it is up to you to explore this avenue.
That is for a secondary domain www2.graphviz.org
If I’m not mistaken, we use cloudflare for our DNS (though joker.com is still our registrar). Is the main point to change a setting to enable DNSSEC in our Cloudflare config?
The main graphviz site is hosted in gitlab, and the forum is in discourse. www2 is a self-managed VM host running Centos 7, and at some point I was able to put its letsencrypt cert renewal in an automatically scheduled script. I don’t know how the others work.
Yes, enabling DNSSEC should be straightforward in the CloudFlare config and is my primary concern. It should be a switch you can just turn on. I also happen to know that CloudFlare supports DANE (they use it themselves), but like I said we’ll have to wait to hear back from GitLab.
I’ll research enabling DANE for the forum; I’m not familiar with Discourse but I’m sure there’s a way.
Is www2 used for anything except hosting the old release tarballs? We could add these as manual Gitlab releases and turn off www2 if it gives us one less thing to worry about and/or saves money.
Edit: rethought this and decided maybe not a good idea given the torrent of feedback we’ve received in the past about the need for stable URLs of old release tarballs.
I’ve just realized I’m dumb, there is a much better way to do what I’m asking for. It looks like all of the Graphviz sites and subdomains use Let’s Encrypt certificates, right? So instead of baking certificates for individual sites into the TLSA records, why don’t we just create a single record that designates Let’s Encrypt as the issuer? You could do something like this
_443._tcp.graphviz.org. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
where this record was generated by tlsa -c --usage 2 --selector 1 graphviz.org and I chose the immediate Let’s Encrypt issuer. Choosing the ISRG root certificate might work too, as a matter of fact it would probably be best to include TLSA records for both the ISRG root certificates.
I notice that graphviz.org now has DNSSEC enabled, so it’s ready to publish some TLSA records! Let me know if you’d like additional directions on how to do this.
Yes, is this something I need to do in the registrar (Joker) or the DNS service (cloudflare)? I thought I followed their instructions but apparently not fully.
I don’t think we should rely on GitLab using Let’s Encrypt. It’s an internal implementation detail of theirs. They could change it tomorrow, which would set us up for an outage.
I have to admit I’m not particularly excited about setting up a root of trust in DNS. I’m familiar with criticisms of PKI, but I don’t think this solves any problems for us, and will set us up for outages we are ill-equipped to fix quickly with our set of volunteers.