41 lines
3.0 KiB
Plaintext
41 lines
3.0 KiB
Plaintext
# DANE and TLS
|
|
|
|
Last year I wrote a post on gemini about gemini (ICK) musing over ways to improve TOFU trust and lend some extra credibility to TLS usage as an actual protective mechanism and not just security theater. I shared thoughts based on my experience with SSHFP which did something similar. Some recent gemlog content has brought this back top of mind, so I thought it appropriate to expand and follow up on the idea.
|
|
|
|
=> /~tomasino/journal/20210331-sshfp-and-the-tofu-issue.gmi SSHFP and the TOFU issue
|
|
|
|
In my ignorance I completely missed the existence of a more appropriate solution than SSHFP: DANE.
|
|
|
|
> DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC). - Wikipedia
|
|
|
|
That's right, it's an automated authentication mechanism that binds TLS to DNS via DNSSEC so you can be sure that the server's certificate is valid for that server and not a MITM attack, even with TOFU. It is literally the solution to our exact problem and it is a spec that works in practice today.
|
|
|
|
Here's a rough outline of how it all flows together:
|
|
* Server owner generates a TLS certificate
|
|
* Server owner also generates the DANE record for that cert (see below for links on how)
|
|
* Server owner wires up DNS with DNSSEC (see your DNS provider for how)
|
|
* Server owner adds DANE record for _1965._tcp.gemini.xxxxxx to match their server usage
|
|
* Client author adds DANE checking to their client code! (Comes up with a cool green lock icon in URL bar that is definitely not lifted from another source)
|
|
* Client checks for DANE record when hitting server and encountering a new cert. If present and matches, automatically approve. If not present, follow user's TOFU preference (Yellow lock icon?)
|
|
* Profit
|
|
|
|
I know you nerds love IETF documentation, so here you go:
|
|
=> https://www.ietf.org/id/draft-huque-dane-client-cert-07.html IETF DANE Draft
|
|
|
|
And here's some python showing how to do the verification:
|
|
=> https://github.com/getdnsapi/getdns-python-bindings/blob/master/examples/checkdanecert.py Python TLSA verification
|
|
|
|
And here's a little guide on how DANE TLSA records can be checked and created for email. Just substitute 1965 instead of 25 and you're golden. This example also uses LetsEncrypt. Normally that's a PITA because people need to keep reapproving your cert every few months, but if we start building DANE checking into our clients that problem goes away.
|
|
=> https://blogs.linux.pizza/deploy-tlsa-records-dane-on-your-email-server-with-lets-encrypt Deploy TLSA Records (DANE) on your Email Server with Let's Encrypt
|
|
|
|
UPDATE:
|
|
|
|
I've updated cosmic.voyage with a TLSA/DANE record. If you're looking to build lookup functionality into your client you can feel free to use it for testing.
|
|
|
|
|
|
Originally Published 2022-02-14 at:
|
|
gemini://tilde.team/~tomasino/journal/20220214-dane-and-tls.gmi
|
|
|
|
If you have questions or thoughts to add please send me a link to your response.
|
|
=> /~tomasino/about.txt Contact Information
|