Hacker News Reader

Comment by gmueckl | Hacker News Reader

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?

View on HN

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.

A common use case is a device serving a status report as a single simple, static, read-only (i.e. the backend has no intended ability to receive data) html file with limited or no markup. This can reasonably be expected to run for 30 years without an update - there's nothing to update, you have a fixed hardware system showing the same type of numbers to the user until it dies.

Serving this over http in a secure network would be reasonable.

Serving this over https would be reasonable if you can embed a certificate with an appropriate lifetime. Which you can't.

30 years ago browsers didn't exist, so the assumption that in 30 years time they're still going to be compatible with today's servers seems wrong to me. The equivalent would be that you were building this device in 1987 and you embedded a Gopher server on it. It'd still be accessible today but users wouldn't be very happy about how they access it.

As another user said, you own both sides of this problem so write your own client software.

My browser can show a 26 year old web page (http://info.cern.ch/hypertext/WWW/News/9211.html) just fine, and I have all reasons to assume that it'll be able to do it also after 26 more years.

If I write my own client software, that's far less likely to be the case. Writing your own is exactly the thing that you should avoid if long-term compatibility is important, sticking to open standards is a much better way to do that.

Using your own example illustrates it perfectly: if I had a 30 year old device running a Gopher server, that would be usable and I would easily be able to get a client running on a modern computer/OS - but if it needed 30 year old custom client software, then porting it would likely be a quite nasty project.

That example you linked uses absolutely NO CSS or JS! Which yes, is fine and in theory it should work "forever", but any extra functionality and you can't be sure.

Open standards change, software changes and things move on. If you are seriously relying on anything technological working for a decade or more you're out your mind.

You need to keep up and adapt because nobody gives a crap about you or your use case. Here we see Google doing what it thinks best and you need to live with this.

Of course it doesn't use CSS and JS, none of those existed back in 1992 when the website was made.

However, content using CSS1 and javascript 1.0 standards (1996?) should also work in modern browsers; but I couldn't easily find any sites that actually use them and haven't been updated for the last 20+ years to test it; the sites from e.g. 1997-1999 seem to avoid it like the plague since back then you couldn't rely on CSS1 and javascript 1.0 being properly supported.

So yes, just as modern browsers support all web technologies since their very start - a CSS3 compliant browser should be compatible also with CSS2 and CSS1 (20+years old), I'm quite convinced that 20 years into future when we might have CSS 5 or 6, the current CSS3 content will also work as well. New javascript doesn't work on ancient browsers, but ancient javascript works well in modern browsers, that's a core design principle of the web standards - we build them for compatibility.

> The equivalent would be that you were building this device in 1987 and you embedded a Gopher server on it. It'd still be accessible today but users wouldn't be very happy about how they access it.

By using firefox 56? I'm not seeing the issue.

> As another user said, you own both sides of this problem so write your own client software.

Running 30 year old DOS software is a lot more painful than accessing a Gopher server. Is that really the comparison you want to make?

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.

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.

Jets, boats, and cars all require regular servicing. Parts need fixing and updating and it isn't one and done. The allegory isn't exactly the same as software updates but the allegory of software systems to cars isn't exact either.

Our devices do not normally need servicing. They do age, but this is compensated.

I get what you say. But are you, let's say, a Catia ISO programmer who has been thrown as a leader of a project team which purpose is to buy some piece of a tier software/project that will automagically cut your programming time by half?

He may be an engineer, whatever that means, but still: the average joe in that position will not spend a single second on thinking if he expects the solution he's buying to work for a reasonable lifespan. He's been thrown in a project, that's all. If you force him to state a requirement on the expected lifespan, he will surely say 'Well, as long as possible seems good to me'.

Disclaimer: statistics applies here, of course some people will care, but I'm speaking about the 80%, if not more.

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.

But I recently had to watch from the sidelines as our management decided against .Net and Qt as the future stack for user interfaces. In the case of Qt the arguments were clearly misinformed, but I only got to comment on that after the fact. So now we will have to deal with web stacks by decree.

It may at least serve as a fallback, considering that the vendor may cease to exist and client software is rendered permanently unavailable.

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.

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.

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.

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.

If you can see the webserver, you're already in.

> Nobody said it would need to be secure?

Then ignore the security warnings.

  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.

Wouldn't self-signed certificates have even more and scarier warnings?

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.

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.

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

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

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?

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.

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/

SSL terminating proxy between the devices?

I imagine you'll be able to flip a Chrome flag to turn it off anyway.

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.

This sounds like the sanest solution so far, but this would require a push to get these additional gateways installed in our customers' IT.

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?"

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

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

>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?

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.

We have similar stories here.

Heavy industry is concerned only with keeping their production lines up and running. They will do amazing and scary things if it helps them keeping production up. These people have absolutely no idea of security or even IT. They want to bolt and wire devices together so that they work. All the cool tech hidden inside is way beyond their understanding for the most part.

>* 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.

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.

Our customers do indeed run devices from us and from competitors for decades. These lifespans are normal and expected. We currently manufacture and sell devices that have been developed 10 to 15 years ago with virtually no changes.

Internally, we have a push to transition user interfaces for future products to HTML/JS over HTTP. This was sold to our management as a solution with long term stability.

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?

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.

If you're using a publicly-routable IP address why not use a publicly-routable hostname and get a certificate for it?

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.

Yeah, that is a fair point.

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.

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.

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.

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

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.

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.

unmaintained unsupervised support is clearly not an issue, which operating system could they chose with that kind of guarantee?

Create a Root CA and sign your own certs.

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.

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

Reply on news.ycombinator.com