3 ms·

You can use HTTP instead of HTTPS or you can use a self-signed cert.

cutler 7y ago
Yeah, right - and risk the wrath of your clients when they ask you why their shiny new website can't be accessed because it doesn't implement HTTPS. Face it, folks, the golden age of the internet is long past. Now we have to jump through a bewildering array of "security" hoops just to host a ing web page.
- extra88 7y ago
  I was replying to someone who was complaining about what to do on "my LAN," no mention was made of clients. HTTPS isn't "security" with sarcasm quotes, it's actual security, it really does what it's supposed to do.
xg15 7y ago
Often, this doesn't even work for small projects: - HTTP have no access to a significant part of web APIs added in the last years - and they will be blocked from all APIs that are being added in the future. - Self-signed certs show security warnings that are deliberately confusion and discouraging to click through and will likely become even more so in the future. Show those to other people is no option.
- Lyrex 7y ago
  In my opinion this doesn't fall under the "it's only on my LAN and a super small project" category. If you LAN is a company then you should be able to deploy a custom CA to your clients and sign your certs. If it's only your small side project you personally work on, then just trusting the cert locally works out too. If people don't want to use third party providers, they have to do some of the work on their own. That's nothing new (at least to me).
  - xg15 7y ago
    A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle. I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It also seems to me that this part is actively discouraged by browser vendors, so I'm honestly not sure how long it will stay open. Self-signed certificates are also unpredictable to do API requests to because no accept UI is shown for such requests. > That's nothing new (at least to me). It absolutely is. With HTTP, you could simply run a local web server and have everything interested point their browser towards it - and everything worked. This is not possible anymore unless you want to make recurring payments for a domain and accept that you need an internet connection.
    - dublin 7y ago
      And this is exactly why SSL everywhere is a really, really, bad idea. (Plus the problems of IoT server certs, mentioned above...)
      - xg15 7y ago
        I understand the rationale behind https-everywhere and I believe it's absolutely necessary for the web at large. The problem of network attackers is certainly real. However, a side-effect (intentional or not) is that the web is turned into a sort of app store: Either you belong to the platform or you don't, and whether or not you do is decided by third parties. (Who, btw, are not even bound by any kind of public mandate - they are simply private, profit-driven companies) I also don't think the stated security advantages always make sense: Let's Encrypt will serve network attackers just as easily as legitimate customers. Meanwhile it will lead to a lot of stuff being exposed on the internet than would be necessary otherwise. We also force devices that simply should expose a local web interface to have a cloud service. I don't see how this makes anything more secure. I guess what I'd want is simply a way to designate a device as "trusted" locally, without depending on third-party services, internet connectivity or anything else and without anything expiring. A way that should be encouraged to be used by non-techical users as well.

Yeah, right - and risk the wrath of your clients when they ask you why their shiny new website can't be accessed because it doesn't implement HTTPS. Face it, folks, the golden age of the internet is long past. Now we have to jump through a bewildering array of "security" hoops just to host a ing web page.

extra88 7y ago
I was replying to someone who was complaining about what to do on "my LAN," no mention was made of clients. HTTPS isn't "security" with sarcasm quotes, it's actual security, it really does what it's supposed to do.

xg15 7y ago

Often, this doesn't even work for small projects: - HTTP have no access to a significant part of web APIs added in the last years - and they will be blocked from all APIs that are being added in the future. - Self-signed certs show security warnings that are deliberately confusion and discouraging to click through and will likely become even more so in the future. Show those to other people is no option.

Lyrex 7y ago
In my opinion this doesn't fall under the "it's only on my LAN and a super small project" category. If you LAN is a company then you should be able to deploy a custom CA to your clients and sign your certs. If it's only your small side project you personally work on, then just trusting the cert locally works out too. If people don't want to use third party providers, they have to do some of the work on their own. That's nothing new (at least to me).
- xg15 7y ago
  A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle. I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It also seems to me that this part is actively discouraged by browser vendors, so I'm honestly not sure how long it will stay open. Self-signed certificates are also unpredictable to do API requests to because no accept UI is shown for such requests. > That's nothing new (at least to me). It absolutely is. With HTTP, you could simply run a local web server and have everything interested point their browser towards it - and everything worked. This is not possible anymore unless you want to make recurring payments for a domain and accept that you need an internet connection.
  - dublin 7y ago
    And this is exactly why SSL everywhere is a really, really, bad idea. (Plus the problems of IoT server certs, mentioned above...)
    - xg15 7y ago
      I understand the rationale behind https-everywhere and I believe it's absolutely necessary for the web at large. The problem of network attackers is certainly real. However, a side-effect (intentional or not) is that the web is turned into a sort of app store: Either you belong to the platform or you don't, and whether or not you do is decided by third parties. (Who, btw, are not even bound by any kind of public mandate - they are simply private, profit-driven companies) I also don't think the stated security advantages always make sense: Let's Encrypt will serve network attackers just as easily as legitimate customers. Meanwhile it will lead to a lot of stuff being exposed on the internet than would be necessary otherwise. We also force devices that simply should expose a local web interface to have a cloud service. I don't see how this makes anything more secure. I guess what I'd want is simply a way to designate a device as "trusted" locally, without depending on third-party services, internet connectivity or anything else and without anything expiring. A way that should be encouraged to be used by non-techical users as well.