8 ms·

Requiring HTTPS for services on the private network seems rather extreme. How do you even do HTTPS on a private network not attached to some publicly-resolvable

Requiring HTTPS for services on the private network seems rather extreme. How do you even do HTTPS on a private network not attached to some publicly-resolvable external domain without installing the root certificate on all devices?

cratermoon 6y ago
Zero-trust architecture would note that there's not really anything 'private', once the traffic is 'inside'. The old way of thinking with firewalls and DMZs falls apart now, so you have to treat all traffic, even what you think of as "inside" as potentially hostile or disruptive. Thus, TLS everywhere. How to do it? self-signed certs and distribute your own CA and install it across devices that are authorized to be on your network.
- toomuchtodo 6y ago
  > How to do it? self-signed certs and distribute your own CA and install it across devices that are authorized to be on your network. This is an unreasonable ask for the vast majority of users.
  - cratermoon 6y ago
    This is not a proposal for users, it's a tool for network administrators and programmers. "Yeah but I have a home LAN, too" isn't relevant here, unless your home network has high-value targets on it and all the other technologies this applies to, in which case maybe you're not in "the vast majority of users".
bawolff 6y ago
If you are running a private intranet type thing, installing your own root certs seems fairly reasonable to me. You could also just have the dns be public. No reason why private networks can't be in public dns. If you are really paranoid use wildcard certs, and only have top domain be in the public dns.
- orisho 6y ago
  The certificate transparency log for an internal network would let you see which domains are in use and make it far easier for an attacker to exploit internal services. The attacker need not be an APT for this, it could be as mundane as a XSS attack.
  - bawolff 6y ago
    That's why i was suggesting using wildcard certs - they would not have the actual domain name in them. That said, regardless of what one does, i wouldn't reccomend putting too much faith in security by obscurity.
- mook 6y ago
  How the heck would I go about installing my own root cert into my TV? My fridge? (I'm picking devices here that could actually run browsers.) How the heck would I have my DNS be public, if I don't have a domain? Getting one means a cost (some amount for the registration, plus whatever you consider costs to avoid your information in the registry getting leaked) For large corporations, yes it totally makes sense to have your infrastructure be using proper domains and things. For your neighbor's network behind his router… not so much. Nothing that requires TLS does.
  - bawolff 6y ago
    In the context of this proposal, i'm not sure why your routers and stuff would need one, it seems like only corporate stuff would be affected. That said, for a router, it would be vendors responsibility to set this all up. It seems possible but annoying to do this in a secure but privacy preserving way.
bawolff 6y ago
I just read the proposal. I do not see where it says that internal services will require https. My reading is that public websites making an ajax request to http://10.0.0.12 http://10.0.0.12 will need to be https. I'm not sure how that protects against anything, but it also doesn't affect the internal services themselves.
- AntonyGarand 6y ago
  It does mention private to local requests will be affected, which is implying the private network host must be served via https > Requests from a private network to a local network https://web.dev/cors-rfc1918-feedback/#what-kinds-of-requests-are-affected https://web.dev/cors-rfc1918-feedback/#what-kinds-of-request...
  - duskwuff 6y ago
    "Local", in this context, means localhost (i.e. the machine that the web browser is running on). It does not mean other machines on the private network. Generally speaking, this simply enforces that, if you are running a web server on your local machine, external web sites (either on your private network or on the Internet at large) cannot trigger requests to that web server.
    - xg15 6y ago
      Yes, but that would mean that a web page served from 192.168.1.1 wouldn't be able to talk with a deamon on localhost if I understand that correctly - unless the private site speaks https, has a domain on the public DNS with a valid cert, etc etc.
      - duskwuff 6y ago
        Correct. But that's a really weird use case, and one which deserves some attention to security. The local network can contain untrusted devices (or devices which can be subverted into behaving in untrustworthy ways), after all; it's no more appropriate to allow one of them to access a daemon running on localhost than it would be to allow an arbitrary web site to do so.
mchristen 6y ago
Just because your domain is public doesn't mean your DNS is public as well. You can use a cert signed by a public CA in a private network just fine so long as you're using the right DNS setup.
- hitpointdrew 6y ago
  Except that a lot of places have .local (which is terrible, I know, but still lots of places have it), or .lan. A public CA won't create certs for those.
  - kjaftaedi 6y ago
    Just because your internal domain for your computers ends in .local does not mean your internal websites need to end in .local. There's nothing preventing you from creating another DNS zone.
nickphx 6y ago
That's not how I understood it. "Make sure the website making requests to a private network is served over HTTPS." My understanding of it is the site making the call to the resource on the 'private' network, must be served via HTTPS.
mikewest 6y ago
The proposal does not attempt to force private network resources to use TLS. That would be an excellent outcome, but it's difficult to do in the status quo, and is a separate problem to address separately. The proposal _does_ require pages that wish to request resources across a network boundary to be delivered securely, which therefore requires resources that wish to be accessible across network boundaries to be served securely (as they'd otherwise be blocked as mixed content). This places the burden upon those resources which wish to be included externally, which seems like the right place for it to land.

cratermoon 6y ago

Zero-trust architecture would note that there's not really anything 'private', once the traffic is 'inside'. The old way of thinking with firewalls and DMZs falls apart now, so you have to treat all traffic, even what you think of as "inside" as potentially hostile or disruptive. Thus, TLS everywhere. How to do it? self-signed certs and distribute your own CA and install it across devices that are authorized to be on your network.

toomuchtodo 6y ago
> How to do it? self-signed certs and distribute your own CA and install it across devices that are authorized to be on your network. This is an unreasonable ask for the vast majority of users.
- cratermoon 6y ago
  This is not a proposal for users, it's a tool for network administrators and programmers. "Yeah but I have a home LAN, too" isn't relevant here, unless your home network has high-value targets on it and all the other technologies this applies to, in which case maybe you're not in "the vast majority of users".

bawolff 6y ago

If you are running a private intranet type thing, installing your own root certs seems fairly reasonable to me. You could also just have the dns be public. No reason why private networks can't be in public dns. If you are really paranoid use wildcard certs, and only have top domain be in the public dns.

orisho 6y ago
The certificate transparency log for an internal network would let you see which domains are in use and make it far easier for an attacker to exploit internal services. The attacker need not be an APT for this, it could be as mundane as a XSS attack.
- bawolff 6y ago
  That's why i was suggesting using wildcard certs - they would not have the actual domain name in them. That said, regardless of what one does, i wouldn't reccomend putting too much faith in security by obscurity.
mook 6y ago
How the heck would I go about installing my own root cert into my TV? My fridge? (I'm picking devices here that could actually run browsers.) How the heck would I have my DNS be public, if I don't have a domain? Getting one means a cost (some amount for the registration, plus whatever you consider costs to avoid your information in the registry getting leaked) For large corporations, yes it totally makes sense to have your infrastructure be using proper domains and things. For your neighbor's network behind his router… not so much. Nothing that requires TLS does.
- bawolff 6y ago
  In the context of this proposal, i'm not sure why your routers and stuff would need one, it seems like only corporate stuff would be affected. That said, for a router, it would be vendors responsibility to set this all up. It seems possible but annoying to do this in a secure but privacy preserving way.

bawolff 6y ago

I just read the proposal. I do not see where it says that internal services will require https. My reading is that public websites making an ajax request to http://10.0.0.12 http://10.0.0.12 will need to be https. I'm not sure how that protects against anything, but it also doesn't affect the internal services themselves.

AntonyGarand 6y ago
It does mention private to local requests will be affected, which is implying the private network host must be served via https > Requests from a private network to a local network https://web.dev/cors-rfc1918-feedback/#what-kinds-of-requests-are-affected https://web.dev/cors-rfc1918-feedback/#what-kinds-of-request...
- duskwuff 6y ago
  "Local", in this context, means localhost (i.e. the machine that the web browser is running on). It does not mean other machines on the private network. Generally speaking, this simply enforces that, if you are running a web server on your local machine, external web sites (either on your private network or on the Internet at large) cannot trigger requests to that web server.
  - xg15 6y ago
    Yes, but that would mean that a web page served from 192.168.1.1 wouldn't be able to talk with a deamon on localhost if I understand that correctly - unless the private site speaks https, has a domain on the public DNS with a valid cert, etc etc.
    - duskwuff 6y ago
      Correct. But that's a really weird use case, and one which deserves some attention to security. The local network can contain untrusted devices (or devices which can be subverted into behaving in untrustworthy ways), after all; it's no more appropriate to allow one of them to access a daemon running on localhost than it would be to allow an arbitrary web site to do so.

mchristen 6y ago

Just because your domain is public doesn't mean your DNS is public as well. You can use a cert signed by a public CA in a private network just fine so long as you're using the right DNS setup.

hitpointdrew 6y ago
Except that a lot of places have .local (which is terrible, I know, but still lots of places have it), or .lan. A public CA won't create certs for those.
- kjaftaedi 6y ago
  Just because your internal domain for your computers ends in .local does not mean your internal websites need to end in .local. There's nothing preventing you from creating another DNS zone.

nickphx 6y ago

That's not how I understood it. "Make sure the website making requests to a private network is served over HTTPS." My understanding of it is the site making the call to the resource on the 'private' network, must be served via HTTPS.

mikewest 6y ago

The proposal does not attempt to force private network resources to use TLS. That would be an excellent outcome, but it's difficult to do in the status quo, and is a separate problem to address separately. The proposal _does_ require pages that wish to request resources across a network boundary to be delivered securely, which therefore requires resources that wish to be accessible across network boundaries to be served securely (as they'd otherwise be blocked as mixed content). This places the burden upon those resources which wish to be included externally, which seems like the right place for it to land.