Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subdomains #1

Closed
pinheadmz opened this issue Jul 5, 2020 · 5 comments · May be fixed by handshake-org/hnsd#126
Closed

Subdomains #1

pinheadmz opened this issue Jul 5, 2020 · 5 comments · May be fixed by handshake-org/hnsd#126

Comments

@pinheadmz
Copy link

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
Copy link
Owner

buffrr commented Jul 5, 2020

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
Copy link
Author

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
Copy link
Owner

buffrr commented Jul 7, 2020

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
Copy link
Author

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants