5 ms·

Author here. Just wanted to comment on the Certificate Transparency issues that some of you have raised: My company (Datto [1]; we're hiring, see [2]) sells ba

Author here. Just wanted to comment on the Certificate Transparency issues that some of you have raised: My company (Datto [1]; we're hiring, see [2]) sells backup appliances which our customers place in their company network (much like you would place a router in your own network). Since we do not control anything other than our appliance inside our customers' networks, we went this route to provide a secure web interface to our appliance. And since the 65k servers/appliances (now more like 80k) are located in tens of thousands of different networks, leaking the internal IP isn't bad at all -- especially since there is no way to correlate them with the customer. For normal "internal servers" within a company, I'd probably recommend using a wildcard cert and an internal DNS server. Also: Yeyy, I'm on HN! [1] https://www.datto.com/ https://www.datto.com/ [2] https://news.ycombinator.com/item?id=19071727 https://news.ycombinator.com/item?id=19071727 or https://www.datto.com/careers/ https://www.datto.com/careers/

mmalone 8y ago
It sounds like using Let’s Encrypt makes sense for your use case since people are accessing these appliances via a web browser, but for “normal internal servers” the right answer is almost definitely to use your own internal PKI, not to use wildcard certs. See: https://github.com/cloudflare/cfssl https://github.com/cloudflare/cfssl https://github.com/hashicorp/vault https://github.com/hashicorp/vault https://github.com/smallstep/certificates https://github.com/smallstep/certificates
forgotmypw 8y ago
> leaking the internal IP isn't bad at all -- especially since there is no way to correlate them with the customer. You seem to be making many assumptions here, which some may not agree with.
- freedomben 8y ago
  Agreed. While the secrecy of IPs should never be relied on as a security mechanism, keeping them secret can force the attacker to use a scan, which can trigger IDS and tip their hand. If the attack is going through a proxy host (a vulnerable app server proxying an attack at the database for example), an unknown DB IP address could make the attack infeasible.
- hackmiester 8y ago
  I was just about to bring this up. Do none of the customers use public addresses internally? My employer does. And, as far as I know, everyone who runs IPv6 does.
cthalupa 8y ago
>And since the 65k servers/appliances (now more like 80k) are located in tens of thousands of different networks, leaking the internal IP isn't bad at all -- especially since there is no way to correlate them with the customer. Maybe not directly - and I say that as a maybe, since I'm not so sure of this premise - but you're leaking a bunch of data this way that can be used by attackers that have some level of information or access to get additional information about the network, the services running on it, etc. The idea that this "isn't bad at all" is pretty much patently false. "Not too bad in most situations" is probably a bit more accurate. >For normal "internal servers" within a company, I'd probably recommend using a wildcard cert and an internal DNS server. Why? For internal servers within the company you can run your own PKI and CA and use an internal cert, giving you much more flexibility and control over things than just using a wildcart cert and internal DNS server would, without much increase in effort. >We went this route to provide a secure web interface to our appliance. The far better option is to give the customer a way to provide their own cert. Or, since you are providing the appliance, have them trust your CA on the machines that are administrating the appliance. I'll be frank: Your choices here and general suggestions around DNS would worry me if I was in the market for your appliance. I would not find it at all acceptable that internal details of my network are leaking out, no matter how convinced you are that it's not bad at all.
- lostapathy 8y ago
  > Why? For internal servers within the company you can run your own PKI and CA and use an internal cert, giving you much more flexibility and control over things than just using a wildcart cert and internal DNS server would, without much increase in effort. Running an internal CA those days terrifies me, its a hell of a responsibility to keep that secure. People check medical records, financial data, and god knows what else on their work devices, and if your CA is compromised that can all be eavesdropped on. Either by an attacker or disgruntled insider. No thanks.
  - alexchamberlain 8y ago
    I think the argument here is given for servers that can only be accessed via an internal network; ie those eavedroppers would have to be on the internal network.
LIV2 8y ago
You're going to want to let people use their own certs if you want to sell to financial institutions and the like And wildcard certificates imply sharing a private key around which is terrible advice If you're a business spend the money on certificates, if the business pushes back ask them "how much is your data worth? How much will reputational harm cost us?" Lots of people suggest rolling your own CA but I bet most of the internal CAs out there are terribly secured and not audited.

mmalone 8y ago

It sounds like using Let’s Encrypt makes sense for your use case since people are accessing these appliances via a web browser, but for “normal internal servers” the right answer is almost definitely to use your own internal PKI, not to use wildcard certs. See: https://github.com/cloudflare/cfssl https://github.com/cloudflare/cfssl https://github.com/hashicorp/vault https://github.com/hashicorp/vault https://github.com/smallstep/certificates https://github.com/smallstep/certificates

forgotmypw 8y ago

> leaking the internal IP isn't bad at all -- especially since there is no way to correlate them with the customer. You seem to be making many assumptions here, which some may not agree with.

freedomben 8y ago
Agreed. While the secrecy of IPs should never be relied on as a security mechanism, keeping them secret can force the attacker to use a scan, which can trigger IDS and tip their hand. If the attack is going through a proxy host (a vulnerable app server proxying an attack at the database for example), an unknown DB IP address could make the attack infeasible.
hackmiester 8y ago
I was just about to bring this up. Do none of the customers use public addresses internally? My employer does. And, as far as I know, everyone who runs IPv6 does.

cthalupa 8y ago

>And since the 65k servers/appliances (now more like 80k) are located in tens of thousands of different networks, leaking the internal IP isn't bad at all -- especially since there is no way to correlate them with the customer. Maybe not directly - and I say that as a maybe, since I'm not so sure of this premise - but you're leaking a bunch of data this way that can be used by attackers that have some level of information or access to get additional information about the network, the services running on it, etc. The idea that this "isn't bad at all" is pretty much patently false. "Not too bad in most situations" is probably a bit more accurate. >For normal "internal servers" within a company, I'd probably recommend using a wildcard cert and an internal DNS server. Why? For internal servers within the company you can run your own PKI and CA and use an internal cert, giving you much more flexibility and control over things than just using a wildcart cert and internal DNS server would, without much increase in effort. >We went this route to provide a secure web interface to our appliance. The far better option is to give the customer a way to provide their own cert. Or, since you are providing the appliance, have them trust your CA on the machines that are administrating the appliance. I'll be frank: Your choices here and general suggestions around DNS would worry me if I was in the market for your appliance. I would not find it at all acceptable that internal details of my network are leaking out, no matter how convinced you are that it's not bad at all.

lostapathy 8y ago
> Why? For internal servers within the company you can run your own PKI and CA and use an internal cert, giving you much more flexibility and control over things than just using a wildcart cert and internal DNS server would, without much increase in effort. Running an internal CA those days terrifies me, its a hell of a responsibility to keep that secure. People check medical records, financial data, and god knows what else on their work devices, and if your CA is compromised that can all be eavesdropped on. Either by an attacker or disgruntled insider. No thanks.
- alexchamberlain 8y ago
  I think the argument here is given for servers that can only be accessed via an internal network; ie those eavedroppers would have to be on the internal network.

LIV2 8y ago

You're going to want to let people use their own certs if you want to sell to financial institutions and the like And wildcard certificates imply sharing a private key around which is terrible advice If you're a business spend the money on certificates, if the business pushes back ask them "how much is your data worth? How much will reputational harm cost us?" Lots of people suggest rolling your own CA but I bet most of the internal CAs out there are terribly secured and not audited.