5 ms·

You should be aware of Certificate Transparency if you go down this route. While I agree that it probably shouldn't matter it could help an attacker gather kno

by mjlee 8y ago

You should be aware of Certificate Transparency if you go down this route. While I agree that it probably shouldn't matter it could help an attacker gather knowledge about your internal network. Perhaps it's of interest that you use a specific monitoring tool or mail server internally - that could make phishing emails easier to craft.

mholt 8y ago
Even without CT, you're still setting public DNS records -- so better yet, don't rely on "internal" hostnames staying private if you want them publicly trusted. Full stop.
- organsnyder 8y ago
  It's very common for internal hostnames to be resolvable only internally (such as with split-zone or dedicated internal DNS servers). Edit: Or do you mean as part of the challenge-response mechanism? Yeah, that would have to be public.
  - zeeZ 8y ago
    Only needs to be public for the challenge though. We use split DNS with an external server that has an empty zone. Internal clients are limited to setting their respective _acme-challenge.subdomain TXT record and delete it afterwards.
    - someone13 8y ago
      Out of curiosity, how is this implemented?
      - w7 8y ago
        Not the person you asked, but: Besides possibly being a function of a provider's API; DNS server security policies can be used to limit updates to certain domains and/or record types based on preshared key. Since the DNS-01 challenge only needs to make a TXT record with a predetermined name you can configure a zone like so (using BIND syntax as an example): key "example-key" { algorithm hmac-sha512; secret <KEY_HERE>; }; zone { ... update-policy { grant "example-key" name _acme-challenge.example.com TXT; }; }; another option is to have a CNAME from _acme-challenge.example.com to a dedicated challenge zone like challenges.example.com that has similar restrictions. This coupled with something like acme.sh makes it easy and relatively secure for machines to generate their own certificates.
  - isostatic 8y ago
    It is common, but as dns over https becomes standard it won’t be able to be.
    - organsnyder 8y ago
      Why would that preclude the ability to host certain zones only on internal DNS servers?
      - yjftsjthsd-h 8y ago
        It appears that some clients just universally query third-party servers, thereby giving out a list of every host name that they're looking for to a third party.
        organsnyder 8y ago
        Not enterprise devices, though. Some enterprise networks even block third-party DNS servers (yes, even over HTTPS—all traffic must go through the corporate proxy).
      - isostatic 8y ago
        If the default option allows a fallback then yes, only split dns (where you get different results internal and externally) will be affected. However how long before the default option is via https only.
        organsnyder 8y ago
        I still don't understand. How does DNS over HTTPS differ from DNS over port 53 in a way that would impact the ability to host internal zones (or even split DNS)?
- tracker1 8y ago
  Considering how many office networks use 192.168.. or 10..., I'm not sure that in practice you're REALLY* leaking all that much... I mean it's a little bit of a hint, but if you can control a bridged device with internal network access, you'll probably get the same info (roughly) from a port scan. The "breach of info" is overblown imho.
  - pawal 8y ago
    In practice internal only DNS names will always leak to external resolvers in one way or another. Pretending otherwise is very naive.
ce4 8y ago
This is not exclusive to LetsEncypt - you'll get this with any official CA that participates in CT. You could use a private CA or official wildcard certs.
- peterwwillis 8y ago
  Yep. Until Google abandons CT or the industry grows a pair (and a brain) we're stuck with not being able to use stock web PKI for confidential internal hosts.
  - devrand 8y ago
    I disagree. CT has exposed a ton of issues in PKI and held CAs accountable. If you're hostnames are sensitive then Web PKI is not the correct solution, like you have identified. At that point you should be running an internal PKI and be responsible for running/maintaining to whatever standards you deem fit. Making Web PKI less transparent to fit your use case is not the answer.
    - peterwwillis 8y ago
      No, CT is stupid. Transparency is not necessary for security, but preventing invalid certificate issuance is. CT doesn't even do that. It just alerts you to it after the fact - but you have to monitor it to be useful anyway, so it's actually opt-in security. And it creates annoying side-effects like this public/private thing, or actually preventing CAs from issuing certs when their CT endpoints go down. It's ridiculous. CT is a bank alarm that goes off after the bank's been robbed, that you won't hear unless your radio is tuned to pick it up.
      - JoshTriplett 8y ago
        > Transparency is not necessary for security, but preventing invalid certificate issuance is. > CT is a bank alarm that goes off after the bank's been robbed > There are better solutions How do you propose to prevent invalid certificate issuance? In particular, how do you propose to observe whether any CA accepted by browsers has issued a certificate to someone other than you for a domain you control, if you presume that there are malicious actors willing and able to compromise certificate authorities? Your threat model is nation-states. Assume someone else is willing to put up the cash, what's your solution that works strictly better than certificate transparency, and in particular (since you called attention to it) prevents invalid certificate issuance rather than just logging it for subsequent audit (and CA trust revocation)?
zackboe 8y ago
Chrome and Safari (the only browsers enforcing CT logs at the moment) can both be configured to disable enforcement for certain URLs. https://twitter.com/sleevi_/status/1102306640072716288 https://twitter.com/sleevi_/status/1102306640072716288
- JonathonW 8y ago
  But you can't stop Let's Encrypt from publishing CT records for your internal-only certificates.
johntash 8y ago
I'd rather use an internal pki for internal-only stuff at work, but for my own homelab I do use a wildcard cert that is something like * .homelab.mydomain.com. Sure, someone can see you have internal servers under * .homelab.mydomain.com, but they aren't going to know what specific hostnames exist there.
- deleted 8y ago
  [deleted]

by mjlee 8y ago

mholt 8y ago

Even without CT, you're still setting public DNS records -- so better yet, don't rely on "internal" hostnames staying private if you want them publicly trusted. Full stop.

organsnyder 8y ago
It's very common for internal hostnames to be resolvable only internally (such as with split-zone or dedicated internal DNS servers). Edit: Or do you mean as part of the challenge-response mechanism? Yeah, that would have to be public.
- zeeZ 8y ago
  Only needs to be public for the challenge though. We use split DNS with an external server that has an empty zone. Internal clients are limited to setting their respective _acme-challenge.subdomain TXT record and delete it afterwards.
  - someone13 8y ago
    Out of curiosity, how is this implemented?
    - w7 8y ago
      Not the person you asked, but: Besides possibly being a function of a provider's API; DNS server security policies can be used to limit updates to certain domains and/or record types based on preshared key. Since the DNS-01 challenge only needs to make a TXT record with a predetermined name you can configure a zone like so (using BIND syntax as an example): key "example-key" { algorithm hmac-sha512; secret <KEY_HERE>; }; zone { ... update-policy { grant "example-key" name _acme-challenge.example.com TXT; }; }; another option is to have a CNAME from _acme-challenge.example.com to a dedicated challenge zone like challenges.example.com that has similar restrictions. This coupled with something like acme.sh makes it easy and relatively secure for machines to generate their own certificates.
- isostatic 8y ago
  It is common, but as dns over https becomes standard it won’t be able to be.
  - organsnyder 8y ago
    Why would that preclude the ability to host certain zones only on internal DNS servers?
    - yjftsjthsd-h 8y ago
      It appears that some clients just universally query third-party servers, thereby giving out a list of every host name that they're looking for to a third party.
      - organsnyder 8y ago
        Not enterprise devices, though. Some enterprise networks even block third-party DNS servers (yes, even over HTTPS—all traffic must go through the corporate proxy).
    - isostatic 8y ago
      If the default option allows a fallback then yes, only split dns (where you get different results internal and externally) will be affected. However how long before the default option is via https only.
      - organsnyder 8y ago
        I still don't understand. How does DNS over HTTPS differ from DNS over port 53 in a way that would impact the ability to host internal zones (or even split DNS)?
tracker1 8y ago
Considering how many office networks use 192.168.. or 10..., I'm not sure that in practice you're REALLY* leaking all that much... I mean it's a little bit of a hint, but if you can control a bridged device with internal network access, you'll probably get the same info (roughly) from a port scan. The "breach of info" is overblown imho.
- pawal 8y ago
  In practice internal only DNS names will always leak to external resolvers in one way or another. Pretending otherwise is very naive.

ce4 8y ago

This is not exclusive to LetsEncypt - you'll get this with any official CA that participates in CT. You could use a private CA or official wildcard certs.

peterwwillis 8y ago
Yep. Until Google abandons CT or the industry grows a pair (and a brain) we're stuck with not being able to use stock web PKI for confidential internal hosts.
- devrand 8y ago
  I disagree. CT has exposed a ton of issues in PKI and held CAs accountable. If you're hostnames are sensitive then Web PKI is not the correct solution, like you have identified. At that point you should be running an internal PKI and be responsible for running/maintaining to whatever standards you deem fit. Making Web PKI less transparent to fit your use case is not the answer.
  - peterwwillis 8y ago
    No, CT is stupid. Transparency is not necessary for security, but preventing invalid certificate issuance is. CT doesn't even do that. It just alerts you to it after the fact - but you have to monitor it to be useful anyway, so it's actually opt-in security. And it creates annoying side-effects like this public/private thing, or actually preventing CAs from issuing certs when their CT endpoints go down. It's ridiculous. CT is a bank alarm that goes off after the bank's been robbed, that you won't hear unless your radio is tuned to pick it up.
    - JoshTriplett 8y ago
      > Transparency is not necessary for security, but preventing invalid certificate issuance is. > CT is a bank alarm that goes off after the bank's been robbed > There are better solutions How do you propose to prevent invalid certificate issuance? In particular, how do you propose to observe whether any CA accepted by browsers has issued a certificate to someone other than you for a domain you control, if you presume that there are malicious actors willing and able to compromise certificate authorities? Your threat model is nation-states. Assume someone else is willing to put up the cash, what's your solution that works strictly better than certificate transparency, and in particular (since you called attention to it) prevents invalid certificate issuance rather than just logging it for subsequent audit (and CA trust revocation)?

zackboe 8y ago

Chrome and Safari (the only browsers enforcing CT logs at the moment) can both be configured to disable enforcement for certain URLs. https://twitter.com/sleevi_/status/1102306640072716288 https://twitter.com/sleevi_/status/1102306640072716288

JonathonW 8y ago
But you can't stop Let's Encrypt from publishing CT records for your internal-only certificates.

johntash 8y ago

I'd rather use an internal pki for internal-only stuff at work, but for my own homelab I do use a wildcard cert that is something like * .homelab.mydomain.com. Sure, someone can see you have internal servers under * .homelab.mydomain.com, but they aren't going to know what specific hostnames exist there.

deleted 8y ago
[deleted]