search

buffrr / letsdane

🔒 Let's DANE is an experimental way to enable the use of DANE/TLSA in browsers and other apps using a lightweight proxy.
Apache License 2.0
111 stars 11 forks source link

Subdomains #1

Closed pinheadmz closed 4 years ago

pinheadmz commented 4 years ago

Do subdomains work?

I got this error from https://pinheadmz.proofofconcept.

Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for pinheadmz.proofofconcept.. The certificate is only valid for the following names: proofofconcept, *.proofofconcept, 142.93.115.133

Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

... but the TLD-only URL worked fine: https://proofofconcept/

Could be my certificate parameters but I was hoping *.proofofconcept would work.

buffrr commented 4 years ago

Yes, subdomains work check https://dane.3b. The same certificate is used for 3b and dane.3b you can add a TLSA record for the subdomain pinheadmz.proofofconcept. I didn't find one when looking for _443._tcp.pinheadmz.proofofconcept

The names in the certificate are ignored and are not used for authentication at least when it comes to DANE-EE(3). See RFC7671 Section 5.1

Authentication via certificate usage DANE-EE(3) TLSA records involves simply checking that the server's leaf certificate matches the TLSA record. In particular, the binding of the server public key to its name is based entirely on the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server.

IIRC, you can use a single certificate for all your subdomains and even entirely different domains as long as they have a TLSA record matching the provided certificate. The expiration date of the certificate is ignored as well.

pinheadmz commented 4 years ago

Got it ok thanks - so I'm trying to wildcard all subdomains to use the same TLSA without defining each subdomain as its own record. I've tried two methods:

Wildcard -> CNAME

The cname links all subdomains to the root, which has a TLSA record at _443._tcp...

I guess this doesn't work because of how the prefix pseudo-subdomains are added but I was hoping the recursive resolver would see the CNAME and continue its lookup using _443._tcp.<root> but I guess the CNAME only really works for record types, not prefixes.

* IN CNAME <root>
_443._tcp.<root> IN TLSA <...>

Wildcard -> TLSA

* IN A <same IP as root>
* IN TLSA <...>

This actually does return a TLSA record for any matching request including _443._tcp.SUBDOMAIN.<root> but the signature is over a wildcard, so I wonder if that is why it is still not validating.

Is there a way to get more logging output from godane?

Do you have any ideas how to apply TLSA records to a wildcard in this way such that any subdomains are also secured by DANE?

buffrr commented 4 years ago

The second approach should work fine. I added the following records for *.dane.3b

*.dane.3b. IN A <IP>
*.dane.3b. IN TLSA <....>

you can try ANY-SUBDOMAIN.dane.3b and it should work.

I checked subdomains at *.proofofconcept with dig. It seems there is no "ad" flag returned so that's the issue.

pinheadmz commented 4 years ago

Is your name server signing wildcard matches on the fly? I notice when I dig <random>.proofofconcept I always get back the same RRSIG (over the '*' record) and I read that validating this requires an NSEC, which I'm not sending, so I need to look into that. But your name server returns different RRSIGs for every random prefix, which my server is also not doing yet.

I compared our setups using delv:

;; validating xyz.dane.3b/A: in fetch_callback_dnskey
;; validating xyz.dane.3b/A: keyset with trust secure
;; validating xyz.dane.3b/A: resuming validate
;; validating xyz.dane.3b/A: verify rdataset (keyid=64038): success
;; validating xyz.dane.3b/A: marking as secure, noqname proof not needed

vs.

;; validating x.proofofconcept/A: in fetch_callback_dnskey
;; validating x.proofofconcept/A: keyset with trust secure
;; validating x.proofofconcept/A: resuming validate
;; validating x.proofofconcept/A: verify rdataset (keyid=58608): from wildcard
;; validating x.proofofconcept/A: looking for noqname proof
;; validating x.proofofconcept/A: noqname proof not found
;; no valid NSEC resolving 'x.proofofconcept/A/IN': 127.0.0.1#5350
;; resolution failed: no valid NSEC
pinheadmz commented 4 years ago

OK, I got this working with sign-on-the-fly software. Thanks for your help @buffrr and for this cool tool!