15 ms·

My primary concern are local servers ‒ which of course, are irrelevant if you are a centralised service provider such as Google. To provide some context, I'm c

My primary concern are local servers ‒ which of course, are irrelevant if you are a centralised service provider such as Google. To provide some context, I'm currently working on a web application where the server is intended to be running inside a home network (where the server requires zero configuration by the user). As of now, some of the JS APIs I'm using are only available if the site is running in a secure context, so the server has to serve the application using HTTPS, otherwise some functionality won't be available. However, it is impossible to obtain a valid TLS certificate for this local connection -- I don't even know the hostname of my server, and IP based certificates aren't a thing. So basically, to get a "green lock symbol" in the browser, the server would have to generate a random CA and get the user to install it, which comes with its own severe security risks and is not an option. So my current plan is to have a dual-stack HTTP/HTTPS server, which on first startup generates a random, self-issued certificate. When the server is first accessed using HTTP, the client automatically tries to obtain some resources via HTTPS. If this succeeds, the user is redirected to the HTTPS variant. If it fails due to a certificate error, the user is presented with a friendly screen telling her that upon clicking "next" an ugly error message will appear, and that this is totally fine. Oh, and here's how to permanently store an exception in your browser. Still, the app will forever be marked as insecure. Although it isn't. It is trivial for the user to verify that the connection is secure by comparing the certificate fingerprint with that displayed by the server program she just started. This sucks. It just seems that Google and co don't care about people running their own decentralised infrastructure; and marking your own local servers as "insecure" does definitively not help.

deleted 9y ago
[deleted]
fulafel 9y ago
You are deluding your users if you convey the idea that home networks are separated the internet. Or that traffic on a home network is safe and doesn't need TLS. Can't you just put up a domain can give your users subdomains on that?
- aurelian15 9y ago
  Already thought about this. But a) the application does not require any internet connection, b) while it is possible to just get a global domain name and redirect that locally to the local server, this would require my server to hijack all DNS requests in the local network. Which I don't want to. And I don't want users having to setup DNS redirects themselves. Edit: And don't get me wrong, I'm totally for TLS on the local network; but there should be an easy way for users to permanently mark self-signed certificates from a local address as secure.
  - fulafel 9y ago
    There would be no hijacking involved, just give each of your users a normal unique subdomain that you serve from the DNS. As in, user-1.yourapp.net, user-2.yourapp.net etc. If someone wants to run it in a network with no access to the DNS, you can just tell them to put that in their hosts file (or whatever local DNS setup they are using).
  - JeanMarcS 9y ago
    Do you have the IP of your server on your local network ? Is it fixed (always the same) ? If so, that I would try something like this : - get a domain if you don’t have one - configure a subdomain (like myhomeserver.mydomain.tld) to that IP on the DNS (A record) - get a Let’s encrypt certificate using DNS validation - install the certificate on the local server I haven’t tested this with certificates, but we used to do this back in the days to avoid configuring local DNS on some small companies networks
    - godzilla82 9y ago
      So, are you suggesting to buy domains even for isolated networks? And then for this to work you need to connect to the internet just for DNS lookup?
      - jakobegger 9y ago
        No, you can use a local DNS server or put the DNS entries in your host file. No need to use the internet for DNS lookup.
mpolichette 9y ago
If you have a web service counterpart you should consider looking into webrtc... the sdp exchange can happen through your site and then they will connect directly
- aurelian15 9y ago
  That's a valid point, and something like this might be a solution (i.e. serving the client JS from a public site with valid TLS certificate and connecting to the local network from there) -- however, I don't want my application to be dependent on an internet connection. This is something you should be able to run in the literal lonely cabin in the woods.
  - hamandcheese 9y ago
    You could use service workers to aggressively cache the client for offline use. And maybe have an insecure version served from the application as a fallback.
  - collinmanderson 9y ago
    I think manually trusting a self-signed is the simplest way to go in that case.
hamandcheese 9y ago
It would require you to run outside services to support it, but you could most certainly rig something together that lets each "installation" claim randomsubdomain.domainyoucontrol.com, phone home with the local network IP of the "installation", phone home the Lets Encrypt DNS-01 details, and then get a valid certificate for a domain that points to the local instance.
- saurik 9y ago
  That is like, way way WAY less secure than just using an unencrypted connection, as now my requests are being alerted over DNS to some third party who has the ability to trivially hijack my connections off to the Internet at large.
  - icebraining 9y ago
    Who has? They still need a valid cert for randomsubdomain.domainyoucontrol.com, how will they trivially get that?
    - kuschku 9y ago
      The owner of domainyoucontrol can simply rebind randomsubdomain and generate a new cert. There is no way to build a device with HTTPS that allows the user to distrust the maker of the device. Edit: before I get responses "you can never distrust the maker" — on HTTP I can audit the device, install it, and keep it in the local network forever, trusting it for decades. On HTTPS it needs to be online every 3 months, and the owner could very well intercept it at that time.
      - icebraining 9y ago
        Ah, the maker, fair enough. Still, there is, although not for free: the device can let you configure a subdomain of your own domain, and then use LE (with the DNS challenge) to get a cert. That still requires trusting your DNS provider, of course.
cdmckay 9y ago
It’s not impossible to obtain a SSL certificate for a local connection. You can add an entry for fictional domain that maps to localhost in your hosts file and then self-sign a certificate and install it.
- sleepychu 9y ago
  but for users of NAS type devices, we've gone from an easy http web page to change the config to needing to install a custom certificate and change the localhosts file...
  - collinmanderson 9y ago
    No need to change the local hosts file, just get a self-signed cert for the ip address. But, yes, there needs to be an easier way to say, yes, please trust this certificate. (Like how ssh prompts you the first time)
azernik 9y ago
If you control the local DNS server, you can install a certificate for localserver.example.com, then have the server return a local IP for localserver.example.com
madez 9y ago
You also could stop misusing the browser as an application frontend, and write a proper frontend with a cross-platform toolkit, and distribute that. I don't understand why developers so often choose the browser as a frontend. Are there better rationales besides having at least some frontend for tyrant-controlled devices like iOS'es, and just using the skills one already has? For the first, just tell the people to get proper devices. Because of the second, I see schooling efforts for JavaScript by the tech giants so negatively. It leads to masses of people using JavaScript where it shouldn't be.
- mkohlmyr 9y ago
  > just tell the people to get proper devices That seems like a great way to have no users. An incredibly obvious reason would be that it is the largest application delivery platform with the highest level of user familiarity and comfort. If you compare two services where one of them offers you a direct login to the app and the other offers you a 200MB download, most people will choose to log in to a website. It's a better user experience. Especially for things that will see infrequent use.
  - madez 9y ago
    If you _only_ care about the number of users, then I see a point. However, at least for non-commercial programs, why care at all about the number of users? The scenario you are drawing is not a proper comparison. There is no reason why a native toolkit couldn't support rendering the program before it's fully loaded, so I see no reason a native program would need more data transfer upfront than a JavaScript one. Though I think too that being prompted to download the program, then install it and find the way to run it can be cumbersome, but the solution to this is to not do it this way. Why not integrate with the native way to obtain applications and make it transparent and convenient for the user? After all, I think there might be fundamentally different goals when developing a software, and that explains the difference. If one has accepted advertisement-based financing of projects, then them and I would probably disagree in many ways. I think users devices must only and exclusively work for the user.
- katastic 9y ago
xg15 9y ago
Yes, this reminds me of the Mozilla IoT gateway from yesterday, which seemed like it pulled exactly that rat-tail of requirements behind it. Something like: - We'd like to make an IoT gateway that you can use from a browser. - To get access to necessary APIs, we have to provide it via HTTPS. - The get HTTP we need a certificate. Because no one is going to pay for it, we'll use Let's Encrypt. - To get a Let's Encryt cert, we need a verifyable hostname on the public internet. Ok, let's offer subdomains on mozilla-iot.com. - To verify that hostname, Let's Encrypt needs to talk to the gateway. Ok, let's provide a tunnel to the gateway. - Now the gateway is exposed to the internet and could be hacked. So we need to continously update it to close vulnerabilities. So in the end all your IoT devices are reachable from the internet. But hey, you can use Firefox to turn your lights on!
- throwaway2048 9y ago
  The real solution to this would be something like TLS-SRP where you can authenticate both sides of a TLS session with a zero knowledge password proof (devices could ship with a piece of paper containing the generated password, no need for central servers, remote connections to the mothership, gateways, or certificates, or exposing stuff to the internet, or even any internet connectivity at all). In simple terms it allows you to setup a TLS session by both sides proving they know the secret password, without either side exposing it, thus MITM is unable to capture it, it is an alternative to the cert model that works very well for network local devices. But of course Chrome and firefox both have zero interest in supporting this use case despite TLS-SRP kicking around for ages now, they'd much rather have you connect to your own devices via a mediated cloud gateway server, for your own safety of course.
  - dcow 9y ago
    Pre-shared keys are only good for bootstrapping a stronger trust relationship. You could use TLS-SRP to exchange identities and then mutually authenticate each other for the general case. X509 is not the problem. Centrally manager trust hierarchies are.
  - collinmanderson 9y ago
    I’d rather see an ssh-style ask once and then trust forever after that.
tialaramex 9y ago
Certificates in which the subject is one or more IP addresses rather than DNS names _are_ a thing, but not that many get issued by public CAs and almost certainly your laundry list of objections about how you don't want to require any setup or Internet connection will ensure you wouldn't be able to qualify.
Aaargh20318 9y ago
Why not get a wildcard certifiate for you domain and then put the local services in internal-only subdomains ?
- majewsky 9y ago
  Can't wait to walk Grandma through this on the phone when she buys a Firefox-enabled lightbulb.
  - Aaargh20318 9y ago
    Grandma should not be installing her own network, no normal person should. Do you also expect a regular end-user to install their own electrical outlets ?
    - detaro 9y ago
      Accessing a network-connected TV or other home gadget is also "using a local server", do you really suggest people should not do this without a networking professional? That's just not going to happen.
      - Aaargh20318 9y ago
        Of course that's going to happen. It's just too dangerous to let someone without the right qualifications do it. I expect it to become a legal requirement to have a licensed technician install networks just like it is with electricity or gas. The internet is just too important to leave to amateurs, look at how much damage badly configured home networks and computers are causing already. This stuff needs to be secured properly. You also didn't need a drivers license when cars just became available, but now there are shitloads of cars we have to make sure drivers are capable before letting them drive. Same goes for network-connected equipment.
        always_good 9y ago
        Also, being part of a botnet should directly impact your internet bill. I don't really see another option. It's a bit silly that nobody knows when their devices are saturating their bandwidth 24/7 because they are compromised. That way people are then motivated to hire a professional. Also, people making devices will be motivated to not use a default "admin" password because customers will start saying "uh, this smart toaster cost me hundreds of dollars when I plugged it in."
boomlinde 9y ago
Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. As for your particular hassle, it makes sense to me for a browser to mark sites that mix http/https as insecure from the point of view that once the data is on the plain http page you can no longer be sure that it won't be handed off over an unencrypted connection some place else by some rogue javascript. Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. Say, a method for routers to discover certificates announced by devices on the network to list them in its management interface where you can enable or disable them.
- zAy0LfpBZLC8mAC 9y ago
  > Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. That would be idiotic not just because unrusted parties can use those addresses, but more importantly because those are more or less terrible hacks that should be avoided completely if possible. You rather should have globally unique addresses on your internal network if you can, which would just break this. > Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. It's the internet, not "the home network and the cloud". What is needed is a way to establish a trust relationship between two devices that you have control over. Where those devices happen to be connected to the internet should be absolutely irrelevant. There might be an argument to be had to maybe support for a simplified peering procedure on a local network might be a good idea--but the point is that once the trust trelationship is established, you should be able to move your client device to a different network on the other side of the planet and still be able to talk to your device on your home network.
andrewla 9y ago
I don't think there's a way to do what you want in a secure manner. I think fundamentally your issue here is with secure contexts, not with the site labeling. In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts. Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages. > Still, the app will forever be marked as insecure. Although it isn't. It is trivial for the user to verify that the connection is secure by comparing the certificate fingerprint with that displayed by the server program she just started. Is it, though? Assuming your server hasn't been compromised (nobody is monitoring it to make sure!), and assuming that the self-signed cert cannot be easily exfiltrated, and assuming that they don't do the same thing the next time they get an ugly warning from chase-bank.ru because they're sure that it's spurious -- then maybe?
- aurelian15 9y ago
  > In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts. While that might be an option now, it's not going to be viable. Browser vendors have agreed to make all new JS APIs -- mostly independent of their security implications -- available to secure contexts only [1]. Even now, you cannot use the Crypto API -- which is entirely implementable in plain JS, albeit slower and with higher energy consumption -- without secure contexts. Or you cannot raise the IndexedDB storage limit for your application above a certain threshold without a secure context (which is exactly my problem, I want users to be able to temporarily store a few hundred MB on their mobile device). > Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages. I completely agree. I understand the implications of me doing this and I honestly don't want to. I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.". That would solve the problem, no landing page from my application required. > Is it, though? You're right, there are a lot of assumptions I'm making here. However, I see no reason why my local HTTPS site should be displayed as less secure (red cross, red text in the URL bar) than a local HTTP site. [1] https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ https://blog.mozilla.org/security/2018/01/15/secure-contexts...
tbrock 9y ago
Certainly there could be an exception for localhost right?
- collinmanderson 9y ago
  I'm curious about this myself. Would there be an attack vector? It seems to me secure localhost would only be needed for developers, and developers should be able to allow a self-signed cert.
- aurelian15 9y ago
  Yes, there already is an exception for localhost. HTTP on localhost is considered a "secure context". Edit: To be more precise, and to quote [1] "Secure Contexts says UAs MAY treat localhost as a secure context only if they can guarantee it will only ever resolve to a loopback address (and are in any case not required to). https://w3c.github.io/webappsec-secure-contexts/#localhost" https://w3c.github.io/webappsec-secure-contexts/#localhost" [1] https://github.com/w3ctag/design-principles/pull/75#issuecomment-359518513 https://github.com/w3ctag/design-principles/pull/75#issuecom...
lorenzhs 9y ago
I sort of have the reverse problem. I would like to use a websocket to connect to an insecure host on the local network from a secure context. I realise that this is incredibly niche and would probably need independent confirmation through the browser to prevent abuse. But it's needed to connect to a local weechat instance from Glowing Bear, which is essentially a web UI for WeeChat, an IRC client: https://github.com/glowing-bear/glowing-bear https://github.com/glowing-bear/glowing-bear. Right now we have an https and a non-https-version of the website, which is arguably even worse.
tomphoolery 9y ago
Your problem is isolated to local development servers, which can be easily excepted from blocking non-HTTPS sites. The potential privacy/security gains totally outweigh the inconvenience of seeing "Not Secure" in the URL bar of your browser on an app you are developing. This isn't as big of a problem as you'd like to believe. IMHO.
- kuschku 9y ago
  So, how do I build an IoT device that never sends a single packet outside of my LAN, which my grandma could have set up and run without ever seeing a security warning, and which does not show "Not Secure"? In general, how can I get all the functionality e.g. a Nest device may provide, while staying purely within of my LAN? (Disclaimer: For my own IoT projects, of course I use a special domain with DNS delegation and Let's Encrypt certificates, and HSTS preloaded)
- aurelian15 9y ago
  Sorry for not being clear enough in my initial post. I'm not talking about a development server. I'm talking about the end product being a server. For example in the form of a user-friendly executable that is natively running on your Windows/Linux/macOS Desktop, a Mobile device, or (alternatively) a single-board computer such as a Raspberry Pi. The end-users using this are not developers. They are just normal users running a simple piece of software that provides them with a web-frontend for a service in their home-network. No internet connection required whatsoever.
AdamJacobMuller 9y ago
Register domain called X.com Set up a DNS server that, for a domain of 10-0-0-1.$rand.X.com returns 10.0.0.1 Generate DNS challenges for your domain, issue lets encrypt certificates for said domain. Viola, private, local, publicly-trusted, SSL-encrypted. Have http://10.0.0.1/ http://10.0.0.1/ redirect to https://10-0-0-1.$rand.x.com/ https://10-0-0-1.$rand.x.com/ The biggest issue with this is getting LetsEncrypt to issue you enough certificates. PS: this idea is somewhat borrowed from Plex.

deleted 9y ago

[deleted]

fulafel 9y ago

You are deluding your users if you convey the idea that home networks are separated the internet. Or that traffic on a home network is safe and doesn't need TLS. Can't you just put up a domain can give your users subdomains on that?

aurelian15 9y ago
Already thought about this. But a) the application does not require any internet connection, b) while it is possible to just get a global domain name and redirect that locally to the local server, this would require my server to hijack all DNS requests in the local network. Which I don't want to. And I don't want users having to setup DNS redirects themselves. Edit: And don't get me wrong, I'm totally for TLS on the local network; but there should be an easy way for users to permanently mark self-signed certificates from a local address as secure.
- fulafel 9y ago
  There would be no hijacking involved, just give each of your users a normal unique subdomain that you serve from the DNS. As in, user-1.yourapp.net, user-2.yourapp.net etc. If someone wants to run it in a network with no access to the DNS, you can just tell them to put that in their hosts file (or whatever local DNS setup they are using).
- JeanMarcS 9y ago
  Do you have the IP of your server on your local network ? Is it fixed (always the same) ? If so, that I would try something like this : - get a domain if you don’t have one - configure a subdomain (like myhomeserver.mydomain.tld) to that IP on the DNS (A record) - get a Let’s encrypt certificate using DNS validation - install the certificate on the local server I haven’t tested this with certificates, but we used to do this back in the days to avoid configuring local DNS on some small companies networks
  - godzilla82 9y ago
    So, are you suggesting to buy domains even for isolated networks? And then for this to work you need to connect to the internet just for DNS lookup?
    - jakobegger 9y ago
      No, you can use a local DNS server or put the DNS entries in your host file. No need to use the internet for DNS lookup.

mpolichette 9y ago

If you have a web service counterpart you should consider looking into webrtc... the sdp exchange can happen through your site and then they will connect directly

aurelian15 9y ago
That's a valid point, and something like this might be a solution (i.e. serving the client JS from a public site with valid TLS certificate and connecting to the local network from there) -- however, I don't want my application to be dependent on an internet connection. This is something you should be able to run in the literal lonely cabin in the woods.
- hamandcheese 9y ago
  You could use service workers to aggressively cache the client for offline use. And maybe have an insecure version served from the application as a fallback.
- collinmanderson 9y ago
  I think manually trusting a self-signed is the simplest way to go in that case.

hamandcheese 9y ago

It would require you to run outside services to support it, but you could most certainly rig something together that lets each "installation" claim randomsubdomain.domainyoucontrol.com, phone home with the local network IP of the "installation", phone home the Lets Encrypt DNS-01 details, and then get a valid certificate for a domain that points to the local instance.

saurik 9y ago
That is like, way way WAY less secure than just using an unencrypted connection, as now my requests are being alerted over DNS to some third party who has the ability to trivially hijack my connections off to the Internet at large.
- icebraining 9y ago
  Who has? They still need a valid cert for randomsubdomain.domainyoucontrol.com, how will they trivially get that?
  - kuschku 9y ago
    The owner of domainyoucontrol can simply rebind randomsubdomain and generate a new cert. There is no way to build a device with HTTPS that allows the user to distrust the maker of the device. Edit: before I get responses "you can never distrust the maker" — on HTTP I can audit the device, install it, and keep it in the local network forever, trusting it for decades. On HTTPS it needs to be online every 3 months, and the owner could very well intercept it at that time.
    - icebraining 9y ago
      Ah, the maker, fair enough. Still, there is, although not for free: the device can let you configure a subdomain of your own domain, and then use LE (with the DNS challenge) to get a cert. That still requires trusting your DNS provider, of course.

cdmckay 9y ago

It’s not impossible to obtain a SSL certificate for a local connection. You can add an entry for fictional domain that maps to localhost in your hosts file and then self-sign a certificate and install it.

sleepychu 9y ago
but for users of NAS type devices, we've gone from an easy http web page to change the config to needing to install a custom certificate and change the localhosts file...
- collinmanderson 9y ago
  No need to change the local hosts file, just get a self-signed cert for the ip address. But, yes, there needs to be an easier way to say, yes, please trust this certificate. (Like how ssh prompts you the first time)

azernik 9y ago

If you control the local DNS server, you can install a certificate for localserver.example.com, then have the server return a local IP for localserver.example.com

madez 9y ago

You also could stop misusing the browser as an application frontend, and write a proper frontend with a cross-platform toolkit, and distribute that. I don't understand why developers so often choose the browser as a frontend. Are there better rationales besides having at least some frontend for tyrant-controlled devices like iOS'es, and just using the skills one already has? For the first, just tell the people to get proper devices. Because of the second, I see schooling efforts for JavaScript by the tech giants so negatively. It leads to masses of people using JavaScript where it shouldn't be.

mkohlmyr 9y ago
> just tell the people to get proper devices That seems like a great way to have no users. An incredibly obvious reason would be that it is the largest application delivery platform with the highest level of user familiarity and comfort. If you compare two services where one of them offers you a direct login to the app and the other offers you a 200MB download, most people will choose to log in to a website. It's a better user experience. Especially for things that will see infrequent use.
- madez 9y ago
  If you _only_ care about the number of users, then I see a point. However, at least for non-commercial programs, why care at all about the number of users? The scenario you are drawing is not a proper comparison. There is no reason why a native toolkit couldn't support rendering the program before it's fully loaded, so I see no reason a native program would need more data transfer upfront than a JavaScript one. Though I think too that being prompted to download the program, then install it and find the way to run it can be cumbersome, but the solution to this is to not do it this way. Why not integrate with the native way to obtain applications and make it transparent and convenient for the user? After all, I think there might be fundamentally different goals when developing a software, and that explains the difference. If one has accepted advertisement-based financing of projects, then them and I would probably disagree in many ways. I think users devices must only and exclusively work for the user.
katastic 9y ago

xg15 9y ago

Yes, this reminds me of the Mozilla IoT gateway from yesterday, which seemed like it pulled exactly that rat-tail of requirements behind it. Something like: - We'd like to make an IoT gateway that you can use from a browser. - To get access to necessary APIs, we have to provide it via HTTPS. - The get HTTP we need a certificate. Because no one is going to pay for it, we'll use Let's Encrypt. - To get a Let's Encryt cert, we need a verifyable hostname on the public internet. Ok, let's offer subdomains on mozilla-iot.com. - To verify that hostname, Let's Encrypt needs to talk to the gateway. Ok, let's provide a tunnel to the gateway. - Now the gateway is exposed to the internet and could be hacked. So we need to continously update it to close vulnerabilities. So in the end all your IoT devices are reachable from the internet. But hey, you can use Firefox to turn your lights on!

throwaway2048 9y ago
The real solution to this would be something like TLS-SRP where you can authenticate both sides of a TLS session with a zero knowledge password proof (devices could ship with a piece of paper containing the generated password, no need for central servers, remote connections to the mothership, gateways, or certificates, or exposing stuff to the internet, or even any internet connectivity at all). In simple terms it allows you to setup a TLS session by both sides proving they know the secret password, without either side exposing it, thus MITM is unable to capture it, it is an alternative to the cert model that works very well for network local devices. But of course Chrome and firefox both have zero interest in supporting this use case despite TLS-SRP kicking around for ages now, they'd much rather have you connect to your own devices via a mediated cloud gateway server, for your own safety of course.
- dcow 9y ago
  Pre-shared keys are only good for bootstrapping a stronger trust relationship. You could use TLS-SRP to exchange identities and then mutually authenticate each other for the general case. X509 is not the problem. Centrally manager trust hierarchies are.
- collinmanderson 9y ago
  I’d rather see an ssh-style ask once and then trust forever after that.

tialaramex 9y ago

Certificates in which the subject is one or more IP addresses rather than DNS names _are_ a thing, but not that many get issued by public CAs and almost certainly your laundry list of objections about how you don't want to require any setup or Internet connection will ensure you wouldn't be able to qualify.

Aaargh20318 9y ago

Why not get a wildcard certifiate for you domain and then put the local services in internal-only subdomains ?

majewsky 9y ago
Can't wait to walk Grandma through this on the phone when she buys a Firefox-enabled lightbulb.
- Aaargh20318 9y ago
  Grandma should not be installing her own network, no normal person should. Do you also expect a regular end-user to install their own electrical outlets ?
  - detaro 9y ago
    Accessing a network-connected TV or other home gadget is also "using a local server", do you really suggest people should not do this without a networking professional? That's just not going to happen.
    - Aaargh20318 9y ago
      Of course that's going to happen. It's just too dangerous to let someone without the right qualifications do it. I expect it to become a legal requirement to have a licensed technician install networks just like it is with electricity or gas. The internet is just too important to leave to amateurs, look at how much damage badly configured home networks and computers are causing already. This stuff needs to be secured properly. You also didn't need a drivers license when cars just became available, but now there are shitloads of cars we have to make sure drivers are capable before letting them drive. Same goes for network-connected equipment.
      - always_good 9y ago
        Also, being part of a botnet should directly impact your internet bill. I don't really see another option. It's a bit silly that nobody knows when their devices are saturating their bandwidth 24/7 because they are compromised. That way people are then motivated to hire a professional. Also, people making devices will be motivated to not use a default "admin" password because customers will start saying "uh, this smart toaster cost me hundreds of dollars when I plugged it in."

boomlinde 9y ago

Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. As for your particular hassle, it makes sense to me for a browser to mark sites that mix http/https as insecure from the point of view that once the data is on the plain http page you can no longer be sure that it won't be handed off over an unencrypted connection some place else by some rogue javascript. Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. Say, a method for routers to discover certificates announced by devices on the network to list them in its management interface where you can enable or disable them.

zAy0LfpBZLC8mAC 9y ago
> Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. That would be idiotic not just because unrusted parties can use those addresses, but more importantly because those are more or less terrible hacks that should be avoided completely if possible. You rather should have globally unique addresses on your internal network if you can, which would just break this. > Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. It's the internet, not "the home network and the cloud". What is needed is a way to establish a trust relationship between two devices that you have control over. Where those devices happen to be connected to the internet should be absolutely irrelevant. There might be an argument to be had to maybe support for a simplified peering procedure on a local network might be a good idea--but the point is that once the trust trelationship is established, you should be able to move your client device to a different network on the other side of the planet and still be able to talk to your device on your home network.

andrewla 9y ago

I don't think there's a way to do what you want in a secure manner. I think fundamentally your issue here is with secure contexts, not with the site labeling. In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts. Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages. > Still, the app will forever be marked as insecure. Although it isn't. It is trivial for the user to verify that the connection is secure by comparing the certificate fingerprint with that displayed by the server program she just started. Is it, though? Assuming your server hasn't been compromised (nobody is monitoring it to make sure!), and assuming that the self-signed cert cannot be easily exfiltrated, and assuming that they don't do the same thing the next time they get an ugly warning from chase-bank.ru because they're sure that it's spurious -- then maybe?

aurelian15 9y ago
> In the end, you can have a site like you describe, but you have to avoid using APIs that require secure contexts. While that might be an option now, it's not going to be viable. Browser vendors have agreed to make all new JS APIs -- mostly independent of their security implications -- available to secure contexts only [1]. Even now, you cannot use the Crypto API -- which is entirely implementable in plain JS, albeit slower and with higher energy consumption -- without secure contexts. Or you cannot raise the IndexedDB storage limit for your application above a certain threshold without a secure context (which is exactly my problem, I want users to be able to temporarily store a few hundred MB on their mobile device). > Any sort of avoidance of this, as by the method you describe ("please ignore the ugly warning you are about to see") is a mistake, because you're helping to train the users to ignore these messages. I completely agree. I understand the implications of me doing this and I honestly don't want to. I guess what I'm complaining about mostly boils down to an UX issue. It would be near-trivial for browser vendors to add the following to the error page if they detect a self-signed cert on a local connection: "This site seems to be served from the local network. If you are trying to access your own network infrastructure, please make sure the following fingerprint matches the one displayed by the application you are trying to access <fingerprint>, <autogenerated fingerprint art>. If you are unsure, please click 'Cancel'.". That would solve the problem, no landing page from my application required. > Is it, though? You're right, there are a lot of assumptions I'm making here. However, I see no reason why my local HTTPS site should be displayed as less secure (red cross, red text in the URL bar) than a local HTTP site. [1] https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ https://blog.mozilla.org/security/2018/01/15/secure-contexts...

tbrock 9y ago

Certainly there could be an exception for localhost right?

collinmanderson 9y ago
I'm curious about this myself. Would there be an attack vector? It seems to me secure localhost would only be needed for developers, and developers should be able to allow a self-signed cert.
aurelian15 9y ago
Yes, there already is an exception for localhost. HTTP on localhost is considered a "secure context". Edit: To be more precise, and to quote [1] "Secure Contexts says UAs MAY treat localhost as a secure context only if they can guarantee it will only ever resolve to a loopback address (and are in any case not required to). https://w3c.github.io/webappsec-secure-contexts/#localhost" https://w3c.github.io/webappsec-secure-contexts/#localhost" [1] https://github.com/w3ctag/design-principles/pull/75#issuecomment-359518513 https://github.com/w3ctag/design-principles/pull/75#issuecom...

lorenzhs 9y ago

I sort of have the reverse problem. I would like to use a websocket to connect to an insecure host on the local network from a secure context. I realise that this is incredibly niche and would probably need independent confirmation through the browser to prevent abuse. But it's needed to connect to a local weechat instance from Glowing Bear, which is essentially a web UI for WeeChat, an IRC client: https://github.com/glowing-bear/glowing-bear https://github.com/glowing-bear/glowing-bear. Right now we have an https and a non-https-version of the website, which is arguably even worse.

tomphoolery 9y ago

Your problem is isolated to local development servers, which can be easily excepted from blocking non-HTTPS sites. The potential privacy/security gains totally outweigh the inconvenience of seeing "Not Secure" in the URL bar of your browser on an app you are developing. This isn't as big of a problem as you'd like to believe. IMHO.

kuschku 9y ago
So, how do I build an IoT device that never sends a single packet outside of my LAN, which my grandma could have set up and run without ever seeing a security warning, and which does not show "Not Secure"? In general, how can I get all the functionality e.g. a Nest device may provide, while staying purely within of my LAN? (Disclaimer: For my own IoT projects, of course I use a special domain with DNS delegation and Let's Encrypt certificates, and HSTS preloaded)
aurelian15 9y ago
Sorry for not being clear enough in my initial post. I'm not talking about a development server. I'm talking about the end product being a server. For example in the form of a user-friendly executable that is natively running on your Windows/Linux/macOS Desktop, a Mobile device, or (alternatively) a single-board computer such as a Raspberry Pi. The end-users using this are not developers. They are just normal users running a simple piece of software that provides them with a web-frontend for a service in their home-network. No internet connection required whatsoever.

AdamJacobMuller 9y ago

Register domain called X.com Set up a DNS server that, for a domain of 10-0-0-1.$rand.X.com returns 10.0.0.1 Generate DNS challenges for your domain, issue lets encrypt certificates for said domain. Viola, private, local, publicly-trusted, SSL-encrypted. Have http://10.0.0.1/ http://10.0.0.1/ redirect to https://10-0-0-1.$rand.x.com/ https://10-0-0-1.$rand.x.com/ The biggest issue with this is getting LetsEncrypt to issue you enough certificates. PS: this idea is somewhat borrowed from Plex.