Forum Discussion
DnsOverHttpsTemplatesWithIdentifiers forcibly hashes all variables, making them useless
Hi folks,
This post relates to a recent change in the DnsOverHttpsTemplatesWithIdentifiers setting, which appears to no longer allow for plaintext variables to be passed to the DNS-over-HTTPS resolver, and everything is now forcibly hashed, with no ability to turn this off and restore original behavior.
While I understand the reason for this, when it comes to public DNS resolvers, this change now poses a major hindrance to end users who use private DNS resolvers, and WANT to pass plaintext identifying information (USER_EMAIL specifically) to the DNS-over-HTTPS resolver, so they can see who is responsible for the DNS traffic on the other end, in the Analytics and DNS logs that are streamed into the SIEM.
Considering DNS payload is already encrypted (DOH is used) and the org admin wants to see the plaintext identifiers, this poses a major UX issue since now they cannot correlate activity easily, and requires creation of mapping files, and constant need to sync them out of band. Without this, you see useless hashes that don't serve a purpose.
We feel there should be a setting that allows the admin of an organization to pass plaintext identifiers if they so choose to, as it poses no security issues for private DNS resolvers, over HTTPS.
Are there any plans to restore this original behavior, or at least offer a setting to allow it to behave as it did before, and not hash these variables?
Thanks
5 Replies
Hi yegor,
Thank you for reaching out with your question.
The behavior of the DnsOverHttpsTemplatesWithIdentifiers policy has remained consistent since its introduction in 2022. No changes have been made to its functionality.
The decision to use hashing for identifiers is based on two key rationales:
- Security: It provides a defense-in-depth approach, protecting the identity of the user and device should the Transport Layer Security (TLS) connection be compromised.
- Consistency: It ensures that all variables maintain a consistent, fixed length.
For technical verification, you can refer to the original implementation review:
$\to$ https://chromium-review.googlesource.com/c/chromium/src/+/4013345
Current Status & Future Plans
There are currently no plans to change this feature. However, if other community members encounter this and would like the behavior to be re-evaluated, please reply to this thread. Increased community feedback helps us prioritize future reviews and potential changes.
Hi,
Okay, fair enough. So given the current way this works, how would the org admin be able to turn those hashes into readable data (email or device serial) so it's visible in the Analytics of a DNS-over-HTTPS provider that is handing the DNS queries?
Thanks
Hi,
I could have sworn it was un-hashed before, but I'm clearly hallucinating.That being said, there is a very valuable use case here which avoids all this needless complexity: https://docs.infoblox.com/space/BloxOneThreatDefense/1227128856/ChromeBook+DOH+Enrollment+(MV3+ChromeOS)
The security angle comment is a bit puzzling, if TLS is compromised an email in a DOH endpoint URI would be the least of one's worries. I feel this should be up to the end user to decide if they want to hash the variables, or not. Default behavior can remain the same, but giving the option to not hash would significantly simplify onboarding and deployment for org admins.
We're a vendor of such an offering, and our customers (several schools) are asking for this capability, which is why I'm here.I really hope this request can be put on the roadmap.
Thanks
Thanks yegor I do see your point of view. However as you mention this is an ask mainly coming from the education space, I wonder if you post this feedback on our dedicated Education community (https://www.googleforeducommunity.com/) it might drum up some more input.
This community's audience is for ChromeOS in enterprise.
The type of customer doesn't really matter here, as we have Enterprise customers too, just majority are schools, but their use-case/requirements are the same - ability to see actual end-user emails/serial numbers in our interface, based on DOH query supplied metadata.
Ultimately, given how ChromeOS platform is currently designed: How would the org admin be able to turn those hashes into readable data (email or device serial) so it's visible in the Analytics of a DNS-over-HTTPS provider that is handing the DNS queries, like us or any other vendor?
