Forum Discussion

yegor's avatar
yegor
Level 1.6: Donut
2 months ago

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

chrome enterprise core
chrome enterprise premium

5 Replies

  • Lynda's avatar
    Lynda
    Google Community Manager
    2 months ago

    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.

    • yegor's avatar
      yegor
      Level 1.6: Donut
      2 months ago

      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? 

  • yegor's avatar
    yegor
    Level 1.6: Donut
    2 months ago

    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 

  • Lynda's avatar
    Lynda
    Google Community Manager
    2 months ago

    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.

     

     

    • yegor's avatar
      yegor
      Level 1.6: Donut
      2 months ago

      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