I tried running Epiphany on Debian Bullseye with the Unbound+DNSSEC-Trigger validating resolver, which sets the 'ad' bit when the DNS is trusted. I tried navigating to debian.org which has DANE configured, but Epiphany still complained that it couldn't make the HTTPS connection due to not finding a trusted certificate authority in the chain.
There are a few options to solve this:
- Use a library like libunbound or the getdns API to do validated DNS queries. This enables using DANE even when the client doesn't have a validating resolver. This is probably the least suitable idea.
- Expose GnuTLS's DANE functionality by chaining the various TLS options it supports up the stack (libsoup, webkit2gtk, Epiphany). I'm not sure whether GnuTLS's functionality works like libunbound, or if it merely piggybacks on the system resolver. The latter is totally fine, IMHO.
- Allow Epiphany to handle the TLS details of whether to support DANE/TOFU/certificate authorities/raw public keys/PKCS#11/etc. by setting up options for GnuTLS itself (basically let Epiphany and everything else in the stack make its own GnuTLS context with its preferences, which is more future-proof), and just hand it to GnuTLS.
- Use GLib or some other helper to do the TLSA queries, check the 'ad' (authenticated) bit, check the fingerprint in whichever component it's most appropriate in, and compare the string against the certificate fingerprint.
It seems CURL hasn't yet figured out a model for how they want to do DANE, but their circumstance is a little different:
- CURL and c-ares are designed to run "everywhere," and one of CURL's most prominent features is that it's a wrapper around many other TLS libraries. This seems different from libsoup, which seems to support GnuTLS only (which in this case is a good thing; that permits libsoup users tweaking GnuTLS to their liking).
As compared to any other browser or ecosystem, I think Epiphany and the WebKitGTK+ stack appears to be capable of accommodating DANE and other advanced TLS features well.