Tweet
So, there is a known issue with just relying on CA for SSL certs on hosts and encrypted access. (If any trusted CA (with CA certs installed in clients) is incompetent or can be pressured/ordered to sign certs for domains , this can result in clients confirming good crypto sessions to a server not affiliated with a domain.) TLSA ( https://tools.ietf.org/html/rfc6698 ) is an attempt to provide another method to allow properly enabled clients to verify the CA used is the same CA the owner of the domain intended to use, or validate your cert. It relies on DNSSEC and extra records for each domain and service and cert.
The options for validating a CA seem bad idea for either security or for availability:
1) When the CA owner changes their CA (even non-functionally, only cosmetically), if you use "full cert" validation, then TLSA enabled clients will be broken when CA changes. (risk of lost service)
2) If the domain owner opts for a subset of CA identifiers, to validation , then re-use of those same elements being validated could allow TLSA checks to pass when they should not (including bogus CA installed on a client's machine) (security)
(If you run your own CA and require your user to install your CA , the above are not really an issue, since you will know when you change your CA, so I am referring to 3rd party CA, not people that like to suffer. :-)
The domain owner may have no notice of this change, or alert before the change to afford planning.
It looks like the "better" choice for an admin is to not include any CA validation, but instead validate your own domain's host certs. The domain admin would know when they would need to change their cert (expiration, compromise, fun-or-profit, etc.) and then include the DNS zone record update with cert update.
Is this what you all are doing? Relying on specific host cert checks and using full-cert validation to avoid collision risks with hashing? Or do you go with sha512 hashing to save on BW?
Checking with how defcon does this for https access on forums.defcon.org:
From this we can see TLSA for https access to forum.defcon.org is managed with (Certificate Usage) "3" ("domain-issued certificate": allows for a domain name administrator to issue certificates for a domain without involving a third-party CA : Validate a single host cert whether issued by CA or not.) It also uses (Selector) "0" which is full cert (the more secure option). It also uses (Matching Type) "2" (sha512 hash of "Selector" type: in this case, the full cert.)
Seems like a fair balance to reduce BW consumption and reduce (assumed) collision risk by using sha512 instead of sha256.
Another thought comes to mind: why not include multiple checks for each service which include checks for CA with full cert check, and CA with just SubjectPublicKeyInfo and local host cert? It seems that such a choice would favor availability, but be worse for security, since a "pass" in testing any would be reduced to success. If your host key check is wrong, and the full-cert CA is wrong, but the SubjectPublicKeyInfo check is validated as passing, then the other two failures are meaningless. It would be nice if multiple checks could be offered, and a weighting for each, to let the client know about failures which are "full stop" serious vs those that might not be so bad (if host cert is fine, and SubjectPublicKeyInfo check of CA is fine, but the full-cert check of CA is failing, for example.)
What do you all do for TLSA?
Poll added. How you vote is not public. Multiple selections possible: vote with all that apply.
Why did you choose your TLSA configuration if you have one? What reasons did you dismiss the other options?
How did your transition to use TLSA work for you? Any problems? What were they?
The options for validating a CA seem bad idea for either security or for availability:
1) When the CA owner changes their CA (even non-functionally, only cosmetically), if you use "full cert" validation, then TLSA enabled clients will be broken when CA changes. (risk of lost service)
2) If the domain owner opts for a subset of CA identifiers, to validation , then re-use of those same elements being validated could allow TLSA checks to pass when they should not (including bogus CA installed on a client's machine) (security)
(If you run your own CA and require your user to install your CA , the above are not really an issue, since you will know when you change your CA, so I am referring to 3rd party CA, not people that like to suffer. :-)
The domain owner may have no notice of this change, or alert before the change to afford planning.
It looks like the "better" choice for an admin is to not include any CA validation, but instead validate your own domain's host certs. The domain admin would know when they would need to change their cert (expiration, compromise, fun-or-profit, etc.) and then include the DNS zone record update with cert update.
Is this what you all are doing? Relying on specific host cert checks and using full-cert validation to avoid collision risks with hashing? Or do you go with sha512 hashing to save on BW?
Checking with how defcon does this for https access on forums.defcon.org:
Code:
$ dig +short -t tlsa _443._tcp.forum.defcon.org 3 0 2 4A8CD5D3F7F01AF6963E0C22FF542ADED72834F4600B24B91573F1A2 A89E73561E4F9F7708C197E283C06FAB9D82719C0BDA526150035860 B2B5B8F82FF202CE
Seems like a fair balance to reduce BW consumption and reduce (assumed) collision risk by using sha512 instead of sha256.
Another thought comes to mind: why not include multiple checks for each service which include checks for CA with full cert check, and CA with just SubjectPublicKeyInfo and local host cert? It seems that such a choice would favor availability, but be worse for security, since a "pass" in testing any would be reduced to success. If your host key check is wrong, and the full-cert CA is wrong, but the SubjectPublicKeyInfo check is validated as passing, then the other two failures are meaningless. It would be nice if multiple checks could be offered, and a weighting for each, to let the client know about failures which are "full stop" serious vs those that might not be so bad (if host cert is fine, and SubjectPublicKeyInfo check of CA is fine, but the full-cert check of CA is failing, for example.)
What do you all do for TLSA?
Poll added. How you vote is not public. Multiple selections possible: vote with all that apply.
Why did you choose your TLSA configuration if you have one? What reasons did you dismiss the other options?
How did your transition to use TLSA work for you? Any problems? What were they?