Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.INTERNAL is now reserved for private-use applications

icann.org

Post reply on HN
Print view View original

271–280 of 290 posts

Re: .INTERNAL is now reserved for private-use applications

#271

Post by bigstrat2003 »

Too wrote: post #137
akira2501 wrote: post #99

Earlier quoted context omitted.

localhost is a secure context. so.. presumably we're just waiting for .internal to be added to the white list.

No. The concept of a DMZ died decades ago. You could still be MITM within your company intranet. Any system designed these days should follow zero-trust principles.

> The concept of a DMZ died decades ago.

That is very much not true. Most corporate networks I've ever been on trust the internal network. Whether or not you think they should, they do.

Re: .INTERNAL is now reserved for private-use applications

#272

Post by unethical_ban »

otabdeveloper4 wrote: post #105
kortilla wrote: post #96

Earlier quoted context omitted.

Hoping datacenter to datacenter links are secure is how the NSA popped Google. Turn on crypto, don’t be lazy

Pretty sure state-level actors sniffing datacenter traffic is literally the very last of your security issues. This kind of theater actively harms your organization's security, not helps it. Do people not do risk analysis anymore?

Caring excessively about certain metrics while neglecting real security is harmful.

Encrypting all network traffic between endpoints does nothing to actively harm security.

Re: .INTERNAL is now reserved for private-use applications

#273

Post by Helmut10001 »

qwertox wrote: post #258
brewmarche wrote: post #232

Earlier quoted context omitted.

This is the DNS setup I’d have in mind as well. Regarding the certificates, if you don’t want to set up stuff on clients manually, the only drawback is the use of a wildcard certificate (which when compromised can be used to hijack everything under something.example.com). An intermediate CA with name constraints (can only sign certificates with names under something.example.com) sounds like a better solution if you d…

I'm "ok" with that risk. It's less risky than other solutions, and there's also the issue that hijacked.something.example.com needs to be resolved by the internal DNS server. All of this would most likely need to be an inside job with some relatively big criminal energy. At that level you'd probably also have other attack vectors which you could consider.

This is also my thinking.. if someone compromises your VM that is responsible for retrieving wildcard certs from let's encrypt, then you're probably busted anyway. Such a machine would usually sit at the center of infrastructure, with limited need to be connected to from other machines.

Re: .INTERNAL is now reserved for private-use applications

#274

Post by TeMPOraL »

wkat4242 wrote: post #269
TeMPOraL wrote: post #224

Earlier quoted context omitted.

Cert pinning often annoyingly works against both - software devs are a third party to both the organizational users and their IT dept overlords. Trusted computing is similar, too. It's a huge win for the user in terms of security, as long as the user owns the master key and can upload their own signatures. If not, then it suddenly becomes a very powerful form of control. The more fundamental issue is the distinction…

> The more fundamental issue is the distinction between "user" and "owner" of a computer - or its component, or a piece of software - as they're often not the same people. Often? Only really in the case of a corporate computer. But Android locks these things down for everyone. In fact corporate owners can do things normal users can't. For example I've heard (not confirmed) that with a Knox license you can add root CA…

> Often? Only really in the case of a corporate computer.

On the contrary, that's the more common case. It's the case with any computer at work (unless you're IT dept), in any work - there's hardly a job now that doesn't have one interacting with computers in some form or fashion, and those computers are very much not employee-owned. Same is the case in school setting, and so on. About the only time you can expect to own a computer is when you bought it yourself, with your own cash. The problem is, even when you do, everything is set up these days to deny you your ownership rights.

Re: .INTERNAL is now reserved for private-use applications

#275

Post by Arch-TK »

noirscape wrote: post #187
okanat wrote: post #169

Earlier quoted context omitted.

Protect the software from the user? Why are you giving them the software then?

A lot of mobile software is just a UI around an external web API. The main reason why Android makes it difficult to get the OS to accept an external certificate (you need root for it) is because without it, you can just do a hosts hack through a vpn/dns to redirect it to your own version of that API. Which app manufacturers want to prevent since it's a really easy way to snoop on what endpoints an app is calling and…

Android locking the system certificate store has nothing to do with preventing people from intercepting app traffic for the purpose of inspecting an application and everything to do with preventing people from accidentally installing a malicious certificate which allows part or all their traffic to be MITM-ed.

Re: .INTERNAL is now reserved for private-use applications

#276

Post by layer8 »

thayne wrote: post #243
fleminra wrote: post #236

Earlier quoted context omitted.

The Name Constraints extension can limit the applicability of a CA cert to certain subdomains or IP addresses.

How well supported is that?

It's required by RFC 5280 (and predecessor), so it’s fairly well supported.

Re: .INTERNAL is now reserved for private-use applications

#277

Post by thaumasiotes »

Arch-TK wrote: post #275
noirscape wrote: post #187

Earlier quoted context omitted.

A lot of mobile software is just a UI around an external web API. The main reason why Android makes it difficult to get the OS to accept an external certificate (you need root for it) is because without it, you can just do a hosts hack through a vpn/dns to redirect it to your own version of that API. Which app manufacturers want to prevent since it's a really easy way to snoop on what endpoints an app is calling and…

Android locking the system certificate store has nothing to do with preventing people from intercepting app traffic for the purpose of inspecting an application and everything to do with preventing people from accidentally installing a malicious certificate which allows part or all their traffic to be MITM-ed.

Those are literally the same thing.

Re: .INTERNAL is now reserved for private-use applications

#278

Post by 8organicbits »

layer8 wrote: post #276
thayne wrote: post #243

Earlier quoted context omitted.

How well supported is that?

It's required by RFC 5280 (and predecessor), so it’s fairly well supported.

Do you have any references for that? There are lots of RFCs that are weakly adopted or even ignored. When I tested Chrome they didn't support name constraints, but have since added support. I suspect other software is still lagging.

Re: .INTERNAL is now reserved for private-use applications

#279

Post by brewmarche »

Helmut10001 wrote: post #273
qwertox wrote: post #258

Earlier quoted context omitted.

I'm "ok" with that risk. It's less risky than other solutions, and there's also the issue that hijacked.something.example.com needs to be resolved by the internal DNS server. All of this would most likely need to be an inside job with some relatively big criminal energy. At that level you'd probably also have other attack vectors which you could consider.

This is also my thinking.. if someone compromises your VM that is responsible for retrieving wildcard certs from let's encrypt, then you're probably busted anyway. Such a machine would usually sit at the center of infrastructure, with limited need to be connected to from other machines.

Probably most people would deem the risk negligible, but it’s still worth to mention it, since you should evaluate for yourself. Regarding the central machine: the certificate must not only be generated or fetched (which as you said probably will happen “at the center”) but also deployed to the individual services. If you don’t use a central gateway terminating TLS early the certificate will live on many machines, not just “at the center.”

Re: .INTERNAL is now reserved for private-use applications

#280

Post by thayne »

layer8 wrote: post #276
thayne wrote: post #243

Earlier quoted context omitted.

How well supported is that?

It's required by RFC 5280 (and predecessor), so it’s fairly well supported.

From the issue for support on chrome, it sounds like RFC 5280 requires it for intermediate CAs, but is ambiguous on whether it is required for root CAs (which in this case, is where you want it). So chrome didn't support it on root CAs until recently, at least on Linux.

Although, ideally, it would be possible to limit the scope of a CA when adding it to the trust store, and not have to rely on the creator of the CA setting the right parameters.

Post reply on HN