6 ms·

As long as this is just a non-obnoxious warning that translates http to something in plain English I can sort of live with it. But as soon as browsers start to

As long as this is just a non-obnoxious warning that translates http to something in plain English I can sort of live with it. But as soon as browsers start to inject security warnings, this is going to be very, very bad. Our company manufactures devices for use in labs and industrial processes. They need complex user interfaces and there is a push to move to HTTP, HTML and JS to implement them with the device as the web server. The devices are usually installed in a controlled, isolated internal networks. Our clients run these devices for a long time. 20 or 30 years are not unheard of. They also do not update them if there is no malfunction (they work and our clients love it that way). Now how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years?

frozenport 9y ago
Do you also expect HTML or JS to be stable for 30 years?
jonny_eh 9y ago
Self-sign the certs that expire in 1000 years, then add them to the clients.
- dragonwriter 9y ago
  Don't browsers automatically distrust certificates with a lifespan longer than the current maximum (825 days)?
xtrapolate 9y ago
Now how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years? You can use self-signed certificates. Your clients will have to trust them (by updating their stores). That's hardly an ideal solution (deployment and security wise). More broadly speaking, you can't rely on anything to stay the same in 30 years, in terms of infrastructure. Many companies therefore deliver both the devices themselves, as-well as the systems to control them (ie. custom laptops/tablets). More costly for everyone involved.
- vim_wannabe 9y ago
  Wouldn't self-signed certificates have even more and scarier warnings?
  - xtrapolate 9y ago
    If your clients trust the self-signed certificates (by updating their certificate stores, adding up a self-signed root CA), then, as of today, as far as I'm aware there won't be any warnings. No guarantees that this situation won't change further down the road.
  - dx034 9y ago
    I doubt there'll be any warnings. Otherwise Chrome wouldn't work in company networks. If you have domains that are just available internally (not even on public DNS), self signing is the logical solution. Still provides you with the advantages of encryption.
FLUX-YOU 9y ago
SSL terminating proxy between the devices? I imagine you'll be able to flip a Chrome flag to turn it off anyway.
- PeterisP 9y ago
  Actually, in industrial environments that seems like the perfect choice. Over 30 years, you'll find vulnerabilities in pretty much anything; so you don't want that device on an open network anyway. But, you can put it on an isolated VLAN, configure it so that it's accessible only by that proxy and no other computers, and then all the http traffic is in the isolated part, and the users access the proxy through https.
  - gmueckl 9y ago
    This sounds like the sanest solution so far, but this would require a push to get these additional gateways installed in our customers' IT.
    - FLUX-YOU 9y ago
      I'll be honest, I've never set up the thing I mentioned, but it sounds vastly less error-prone than writing some certificate update support (likely written in C/C++) that writes the certificate bytes directly to the devices. Initial can-of-worm questions are "who's allowed to update the cert?", "how does the device authenticate the person updating it?", "what's the failure mode if an update goes wrong?", "how long shall we test the new cert-writing-module?", "will the customer even bother after the initial certs expire we install for them and instead just tell their users to flip the Chrome flag?", "how do we also update TLS and crypto libraries to support future certs or standards?"
onion2k 9y ago
how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years If there's a requirement that your code needs to run for 30 years without an update then current web technology is probably the wrong choice.
- snerbles 9y ago
  It may at least serve as a fallback, considering that the vendor may cease to exist and client software is rendered permanently unavailable.
- bpizzi 9y ago
  Sadly it's more of a 'wrong' requirement from the customer. Today's entreprise customers expect things to Just Work. They say 'just sell us a goddam appliance, we'll point a browser at it and we'll call it a day!'. I'm quoting real customers' documents here: 'it's should be as easy as Apple'. We've done it to ourselves.
  - snerbles 9y ago
    Until there is tangible motivation (i.e. multiple players get publicly put out of business by lax security), customers will continue to refuse to understand things they cannot put their hands on.
  - egwor 9y ago
    I expect things to just work and I expect them to work for a reasonable lifespan. I often think that a piece of software ought to live as long as a car, and for something commercially created (e.g. costs as much as a house) then it ought to last at least a generation (30years). I don't think I'm being unreasonable here. In a closed system this should be doable. edit: one of the reasons I think this is because we are supposed to be engineers, and other engineering disciplines do it (and their disciplines involve computes too). Consider jets and boats.
    - paublyrne 9y ago
oatmealsnap 9y ago
Sidebar: Why are you looking at web technologies if you aren't expecting to make any updates for 20-30 years? Is the interest for speedier development?
- bpizzi 9y ago
  Not the parent, but I can offer insight: because it's a hard requirement from the customer. Don't do it and they may go to the competition.
coldtea 9y ago
>Our clients run these devices for a long time. 20 or 30 years are not unheard of. Have you actually had clients run those html/js based devices "for 20 or 30 years" (e.g. have some running since 1997) or is this a totally hypothetical scenario?
- snerbles 9y ago
  About a month ago I attempted to restore a DOS-based industrial HMI panel that we shipped mid-1995. The 2 MiB of proprietary custom 72-pin SIMM flash memory had gone corrupt, and neither us nor the panel's OEM possessed the original software for restoration. We did have a later version of the software from 1997, but it needed a whopping 4 MiB to install. The machine was in active production until about two years ago, according to the customer. I fully expect most of the systems that we are shipping now to be run for the next twenty years as well. Until security issues start losing customers buckets of money, they're not going to care one bit.
  - coldtea 9y ago
    >* About a month ago I attempted to restore a DOS-based industrial HMI panel that we shipped mid-1995. The 2 MiB of proprietary custom 72-pin SIMM flash memory had gone corrupt, and neither us nor the panel's OEM possessed the original software for restoration. We did have a later version of the software from 1997, but it needed a whopping 4 MiB to install.* Sure, and there are COBOL systems running since the 70s. But I asked for such an example in web technologies. The one described above isn't. >I fully expect most of the systems that we are shipping now to be run for the next twenty years as well. Then don't build them on modern web technologies. All kinds of things can change or be deprecated.
    - deleted 9y ago
      [deleted]
    - snerbles 9y ago
      It is still not unreasonable to believe that such systems exist, and those systems will become more prevalent over time. An EtherNet/IP-controlled servo drive with an HTTP configuration page installed in 2008 will likely still be running in 2028. > All kinds of things can change or be deprecated. That's cute. If you truly believe a simple declaration of deprecation will stop the use of something, I have some oceanfront property in Afghanistan to sell you.
fulafel 9y ago
Sadly, medical and industrial "isolated networks" have turned out to be huge cans of worms. Never trust the network. Doubly so when you're faced against threats 30 years into the future.
SiVal 9y ago
Almost every consumer router is set up that way. We'll be getting security warnings from our own routers for a while.
- whyever 9y ago
  We should. It is insecure to share your Wifi if you manage your router via http.
Sephr 9y ago
Devices that run for 20 to 30 years are bound to be exploitable, even over "isolated" internal networks. A 30 year old no-updates secure webserver seems almost impossible given current security research progress.
- Dylan16807 9y ago
  Nobody said it would need to be secure? If you can get control over the computer attached to the equipment, you already won. You don't need to exploit the web server.
  - keytarsolo 9y ago
    It's not that you're exploiting the web server once you're in, it's that a 30 year old web server is the security hole you use to get in.
    - Dylan16807 9y ago
      If you can see the webserver, you're already in.
  - netheril96 9y ago
    > Nobody said it would need to be secure? Then ignore the security warnings.
briandear 9y ago
So don’t use Chrome 68. Use whatever version you have now. Since you clearly aren’t intending to update anything for “30 years,” then it shouldn’t matter. If you were intending on keeping systems updated, could you reasonably depend on a web browser developer keeping things constant enough for 30 YEARS? If it’s a closed system, you control everything right? So use what works now.
- bpizzi 9y ago
  The parent may not be able to dictate the browser compatibility, actually. Customers will use whatever they want, and if it don't works then they'll just 'whine' to the commercial next time he tries to sell them something. Do this too much and it's a recipe for disaster.
- gmueckl 9y ago
  Our clients are unwilling to update device firmware, not us. They will happily upgrade their usual IT infrastructure over time, though. So we cannot realistically dictate browsers or browser versions.
LoSboccacc 9y ago
Of all the complexity and unknown that are embedded in projects with decades of lifespan, for this one in particular the solution is quite straightforward: roll your own certificate authority and relative certificate distribution and deployment scripts.
- merb 9y ago
  This only works when SHA256 certs will be supported for 30 years (which I doubt it won't sustain the next 30 years..) I know plenty of devices which can't be used correctly any more since SHA1 + SSLv2/SSLv3 was deprecated and they generated a CA+Cert with 512/1024 Bits.
  - LoSboccacc 9y ago
    unmaintained unsupervised support is clearly not an issue, which operating system could they chose with that kind of guarantee?
dbbk 9y ago
I'm confused, you just said they don't update them. Don't update Chrome and you have no issue.
imhoguy 9y ago
Welcome into web compatibility world - lot of companies do nice buck out of its quick evolution. And this is very, very good thing for you too if you play it well. For internal use the answer is self-signed certificate. However I wouldn't count on web browser based software compatibility to last even 10 years. I think browser vendors at some point will decide to ditch <512-bit certs or some encryption scheme and one needs to make a cert/server upgrade. Some option may be Firefox ESR [0] requirement to ease an adoption. Moreover browser is UI part of your solution and you need to define some requirements - this should be all right for well administrated environments. If the user for any reason upgrades/changes the browser but not your device then this is user introduced incompatibility. Your EULA should cover that. Also you should send notifications or just show some message in device panel to your customers that they need and upgrade if they want to use given browser past version X. Customers need to learn that web means edge tech and that needs frequent upgrades. Their isolated internal network of the past e.g based on WiFi WEP would be practically a network open to bad actors today. [0] https://www.mozilla.org/en-US/firefox/organizations/ https://www.mozilla.org/en-US/firefox/organizations/
fergbrain 9y ago
Create a Root CA and sign your own certs.
- gmueckl 9y ago
  And then we'd have to tell our clients how to add the root cert to their browsers and operating systems. I doubt that this would fly with many customers.
Skunkleton 9y ago
Chrome could easily turn this warning off for private network address blocks. I wonder if this has been discussed, and if so why was it rejected?
- nybble41 9y ago
  Networks which use the private network address blocks are not necessarily trusted networks (consider open Wi-Fi hotspots). Also, private networks do not necessarily use private network address blocks—intranets frequently use publicly-routable IP addresses where possible, as it simplifies linking physically distinct intranets. With IPv6 eliminating the scarcity of public addresses we can expect this to become much more common, even among home users.
  - Skunkleton 9y ago
    Yeah, that is a fair point.
  - nsgi 9y ago
    If you're using a publicly-routable IP address why not use a publicly-routable hostname and get a certificate for it?
    - nybble41 9y ago
      The fact that the IP address is publically routable does not imply that the server is actually reachable from the public Internet—that depends on the firewall. You can associate public hostnames with private-range IP addresses as well, and obtain certificates for them. The main point was that the use of private, non-routable IP addresses does not imply that the network is trusted, and thus is not sufficient reason to exempt the server from securely identifying itself.

frozenport 9y ago

Do you also expect HTML or JS to be stable for 30 years?

jonny_eh 9y ago

Self-sign the certs that expire in 1000 years, then add them to the clients.

dragonwriter 9y ago
Don't browsers automatically distrust certificates with a lifespan longer than the current maximum (825 days)?

xtrapolate 9y ago

Now how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years? You can use self-signed certificates. Your clients will have to trust them (by updating their stores). That's hardly an ideal solution (deployment and security wise). More broadly speaking, you can't rely on anything to stay the same in 30 years, in terms of infrastructure. Many companies therefore deliver both the devices themselves, as-well as the systems to control them (ie. custom laptops/tablets). More costly for everyone involved.

vim_wannabe 9y ago
Wouldn't self-signed certificates have even more and scarier warnings?
- xtrapolate 9y ago
  If your clients trust the self-signed certificates (by updating their certificate stores, adding up a self-signed root CA), then, as of today, as far as I'm aware there won't be any warnings. No guarantees that this situation won't change further down the road.
- dx034 9y ago
  I doubt there'll be any warnings. Otherwise Chrome wouldn't work in company networks. If you have domains that are just available internally (not even on public DNS), self signing is the logical solution. Still provides you with the advantages of encryption.

FLUX-YOU 9y ago

SSL terminating proxy between the devices? I imagine you'll be able to flip a Chrome flag to turn it off anyway.

PeterisP 9y ago
Actually, in industrial environments that seems like the perfect choice. Over 30 years, you'll find vulnerabilities in pretty much anything; so you don't want that device on an open network anyway. But, you can put it on an isolated VLAN, configure it so that it's accessible only by that proxy and no other computers, and then all the http traffic is in the isolated part, and the users access the proxy through https.
- gmueckl 9y ago
  This sounds like the sanest solution so far, but this would require a push to get these additional gateways installed in our customers' IT.
  - FLUX-YOU 9y ago
    I'll be honest, I've never set up the thing I mentioned, but it sounds vastly less error-prone than writing some certificate update support (likely written in C/C++) that writes the certificate bytes directly to the devices. Initial can-of-worm questions are "who's allowed to update the cert?", "how does the device authenticate the person updating it?", "what's the failure mode if an update goes wrong?", "how long shall we test the new cert-writing-module?", "will the customer even bother after the initial certs expire we install for them and instead just tell their users to flip the Chrome flag?", "how do we also update TLS and crypto libraries to support future certs or standards?"

onion2k 9y ago

how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years If there's a requirement that your code needs to run for 30 years without an update then current web technology is probably the wrong choice.

snerbles 9y ago
It may at least serve as a fallback, considering that the vendor may cease to exist and client software is rendered permanently unavailable.
bpizzi 9y ago
Sadly it's more of a 'wrong' requirement from the customer. Today's entreprise customers expect things to Just Work. They say 'just sell us a goddam appliance, we'll point a browser at it and we'll call it a day!'. I'm quoting real customers' documents here: 'it's should be as easy as Apple'. We've done it to ourselves.
- snerbles 9y ago
  Until there is tangible motivation (i.e. multiple players get publicly put out of business by lax security), customers will continue to refuse to understand things they cannot put their hands on.
- egwor 9y ago
  I expect things to just work and I expect them to work for a reasonable lifespan. I often think that a piece of software ought to live as long as a car, and for something commercially created (e.g. costs as much as a house) then it ought to last at least a generation (30years). I don't think I'm being unreasonable here. In a closed system this should be doable. edit: one of the reasons I think this is because we are supposed to be engineers, and other engineering disciplines do it (and their disciplines involve computes too). Consider jets and boats.
  - paublyrne 9y ago

oatmealsnap 9y ago

Sidebar: Why are you looking at web technologies if you aren't expecting to make any updates for 20-30 years? Is the interest for speedier development?

bpizzi 9y ago
Not the parent, but I can offer insight: because it's a hard requirement from the customer. Don't do it and they may go to the competition.

coldtea 9y ago

>Our clients run these devices for a long time. 20 or 30 years are not unheard of. Have you actually had clients run those html/js based devices "for 20 or 30 years" (e.g. have some running since 1997) or is this a totally hypothetical scenario?

snerbles 9y ago
About a month ago I attempted to restore a DOS-based industrial HMI panel that we shipped mid-1995. The 2 MiB of proprietary custom 72-pin SIMM flash memory had gone corrupt, and neither us nor the panel's OEM possessed the original software for restoration. We did have a later version of the software from 1997, but it needed a whopping 4 MiB to install. The machine was in active production until about two years ago, according to the customer. I fully expect most of the systems that we are shipping now to be run for the next twenty years as well. Until security issues start losing customers buckets of money, they're not going to care one bit.
- coldtea 9y ago
  >* About a month ago I attempted to restore a DOS-based industrial HMI panel that we shipped mid-1995. The 2 MiB of proprietary custom 72-pin SIMM flash memory had gone corrupt, and neither us nor the panel's OEM possessed the original software for restoration. We did have a later version of the software from 1997, but it needed a whopping 4 MiB to install.* Sure, and there are COBOL systems running since the 70s. But I asked for such an example in web technologies. The one described above isn't. >I fully expect most of the systems that we are shipping now to be run for the next twenty years as well. Then don't build them on modern web technologies. All kinds of things can change or be deprecated.
  - deleted 9y ago
    [deleted]
  - snerbles 9y ago
    It is still not unreasonable to believe that such systems exist, and those systems will become more prevalent over time. An EtherNet/IP-controlled servo drive with an HTTP configuration page installed in 2008 will likely still be running in 2028. > All kinds of things can change or be deprecated. That's cute. If you truly believe a simple declaration of deprecation will stop the use of something, I have some oceanfront property in Afghanistan to sell you.

fulafel 9y ago

Sadly, medical and industrial "isolated networks" have turned out to be huge cans of worms. Never trust the network. Doubly so when you're faced against threats 30 years into the future.

SiVal 9y ago

Almost every consumer router is set up that way. We'll be getting security warnings from our own routers for a while.

whyever 9y ago
We should. It is insecure to share your Wifi if you manage your router via http.

Sephr 9y ago

Devices that run for 20 to 30 years are bound to be exploitable, even over "isolated" internal networks. A 30 year old no-updates secure webserver seems almost impossible given current security research progress.

Dylan16807 9y ago
Nobody said it would need to be secure? If you can get control over the computer attached to the equipment, you already won. You don't need to exploit the web server.
- keytarsolo 9y ago
  It's not that you're exploiting the web server once you're in, it's that a 30 year old web server is the security hole you use to get in.
  - Dylan16807 9y ago
    If you can see the webserver, you're already in.
- netheril96 9y ago
  > Nobody said it would need to be secure? Then ignore the security warnings.

briandear 9y ago

So don’t use Chrome 68. Use whatever version you have now. Since you clearly aren’t intending to update anything for “30 years,” then it shouldn’t matter. If you were intending on keeping systems updated, could you reasonably depend on a web browser developer keeping things constant enough for 30 YEARS? If it’s a closed system, you control everything right? So use what works now.

bpizzi 9y ago
The parent may not be able to dictate the browser compatibility, actually. Customers will use whatever they want, and if it don't works then they'll just 'whine' to the commercial next time he tries to sell them something. Do this too much and it's a recipe for disaster.
gmueckl 9y ago
Our clients are unwilling to update device firmware, not us. They will happily upgrade their usual IT infrastructure over time, though. So we cannot realistically dictate browsers or browser versions.

LoSboccacc 9y ago

Of all the complexity and unknown that are embedded in projects with decades of lifespan, for this one in particular the solution is quite straightforward: roll your own certificate authority and relative certificate distribution and deployment scripts.

merb 9y ago
This only works when SHA256 certs will be supported for 30 years (which I doubt it won't sustain the next 30 years..) I know plenty of devices which can't be used correctly any more since SHA1 + SSLv2/SSLv3 was deprecated and they generated a CA+Cert with 512/1024 Bits.
- LoSboccacc 9y ago
  unmaintained unsupervised support is clearly not an issue, which operating system could they chose with that kind of guarantee?

dbbk 9y ago

I'm confused, you just said they don't update them. Don't update Chrome and you have no issue.

imhoguy 9y ago

Welcome into web compatibility world - lot of companies do nice buck out of its quick evolution. And this is very, very good thing for you too if you play it well. For internal use the answer is self-signed certificate. However I wouldn't count on web browser based software compatibility to last even 10 years. I think browser vendors at some point will decide to ditch <512-bit certs or some encryption scheme and one needs to make a cert/server upgrade. Some option may be Firefox ESR [0] requirement to ease an adoption. Moreover browser is UI part of your solution and you need to define some requirements - this should be all right for well administrated environments. If the user for any reason upgrades/changes the browser but not your device then this is user introduced incompatibility. Your EULA should cover that. Also you should send notifications or just show some message in device panel to your customers that they need and upgrade if they want to use given browser past version X. Customers need to learn that web means edge tech and that needs frequent upgrades. Their isolated internal network of the past e.g based on WiFi WEP would be practically a network open to bad actors today. [0] https://www.mozilla.org/en-US/firefox/organizations/ https://www.mozilla.org/en-US/firefox/organizations/

fergbrain 9y ago

Create a Root CA and sign your own certs.

gmueckl 9y ago
And then we'd have to tell our clients how to add the root cert to their browsers and operating systems. I doubt that this would fly with many customers.

Skunkleton 9y ago

Chrome could easily turn this warning off for private network address blocks. I wonder if this has been discussed, and if so why was it rejected?

nybble41 9y ago
Networks which use the private network address blocks are not necessarily trusted networks (consider open Wi-Fi hotspots). Also, private networks do not necessarily use private network address blocks—intranets frequently use publicly-routable IP addresses where possible, as it simplifies linking physically distinct intranets. With IPv6 eliminating the scarcity of public addresses we can expect this to become much more common, even among home users.
- Skunkleton 9y ago
  Yeah, that is a fair point.
- nsgi 9y ago
  If you're using a publicly-routable IP address why not use a publicly-routable hostname and get a certificate for it?
  - nybble41 9y ago
    The fact that the IP address is publically routable does not imply that the server is actually reachable from the public Internet—that depends on the firewall. You can associate public hostnames with private-range IP addresses as well, and obtain certificates for them. The main point was that the use of private, non-routable IP addresses does not imply that the network is trusted, and thus is not sufficient reason to exempt the server from securely identifying itself.