The cost of "security"

[capt bullshot]

Drop TLS on that embedded device and put a proper reverse proxy in front of it that does all the TLS infrastructure stuff.

What is a reverse proxy? Isn't that another server which somebody has to set up and admin, for ever?

Yes, indeed.
I have to admit, it's kind of impracticable / impossible for a device intended to be used by "not how the internet works aware" end users.

[ve7xen]

And what does it achieve? Very little, it seems. IOT boxes can't be on open ports, because these are discovered by sniffers almost immediately, due to back doors and vulnerabilities which cannot be fixed (a 100BN $ company like M$ is still patching back doors in Windoze after 30 years, so an embedded coder has absolutely zero chance, and then new ones will be discovered after the product is sold and installed somewhere) so their "internet access" can only be as a client, calling up some server, and hidden behind a NAT router.

TLS wouldn't really help you here anyway, you're still talking about exposing a lightweight microcontroller to the Internet, and despite best intentions it's going to be too bespoke and too infrequently updated for that to be a good idea, so this isn't the angle.

It gets you a few things, whether you care or not about them, or whether they are the best solution to the problem is up to you and your product, and maybe your customers. As usual it's all tradeoffs.

• Server validation. You know you're talking to your server, signed by your CA. If you're a commercial product, the corollary is that users 'can't' reverse engineer your protocol and redirect your device's traffic to their own collector - helps you lock the devices to your service and prevent MITM
• Client identification/validation, if you choose to use it. You can generate a per-device keypair, signed with your CA, and store it in some secure enclave at manufacturing time. This can be used to securely identify the device
• The obvious benefits of encryption in flight against snooping.

I can see not caring about #1 and #3 (though your customers might), but #2 seems like a bigger problem to me. If this is a service at scale, you need some strong way to validate that client updates are associated with the correct account. You can't rely on some plaintext identifier that can be easily fuzzed or even that's printed on the box or easily predictable. Otherwise someone's probably going to attack it and start trying to spam bogus spoofed data into your client's instances.

But if you are calling up a server which you control, you don't need the whole TLS crap, with PK, session key negotiation, x509 authentication. You can just use a shared key, with AES256 or whatever. You have the key dist issue but with PK you still need 100% secure "access control" on each box because the private key has to be secure. You don't need auth because a fake server won't be able to read the data anyway.

Whether you control the server is orthogonal to whether you need to securely authenticate it or not. Shared keys ship with the box and will eventually get extracted, if history is any indication, and then you're hosed, so that's not really a strong solution.

And if the IOT box is to call up some "public service" server, the certificate for that will expire regularly, so you need the whole root certificate store, currently about 200k, and a means of periodically updating that, too In the context of embedded systems, it mostly can't be done practically, and even if it can be done, it will sooner or later break or be forgotten (even the biggest firms have had their website certificates expire because the person whose job that was has left, etc).

You probably wouldn't want to use the 'normal' PKI for such a thing, you'd spin up your own CA and issue long-lived certificates. You don't want to rely on the public trust store when you control both ends, and there's no reason for it here. Unless of course you want to connect to client-provided endpoints, in which case yeah you need to either include (and update) the normal trust store or allow users to install their own trust store (which might be beyond their abilities).

The other thing is that "IOT" is going to end up with a really dirty reputation, as companies go bust, or just stop maintaining the servers. So the remotely controlled irrigation system, where you have a nice app connecting to that server, or even just a website served by that server, goes dead one day and there is no way to fix it. You have to rip the whole lot out.

I'm not sure what this has to do with TLS, but I strongly agree. I'd like to see some industry consortium coalesce around something like MQTT + some service discovery mechanism to make interoperability mostly transparent for the standard home use case (a bunch of sensors and a 'base station' on the same network), and flexible enough to point elsewhere if desired.

Remember, the original purpose of HTTPS was to protect the traffic from eavesdropping, not to securely identify and authenticate the server / client.

I don't know where you get this from, secure identification of both the server and client is a key feature / raison d'etre of TLS and by extension HTTPS.

[madires]

because of the lack of IPv4 address space.

That was supposed to happen 20 years ago but since a way was found to have multiple domains on the same IP, the issue has gone away.

No, that happens when RIRs run out of IPv4 address space to assign to telcos/orgs. Please see https://en.wikipedia.org/wiki/IPv4_address_exhaustion for more details. And shared web hosting (running multiple websites on a single IP address) is supported since HTTP 1.1 and only helps with webservers. There are much more connected devices than just webservers.

IPV6 also does not solve vulnerabilities because the same hacking can be done. For example every instance of win10 has its predefined IPV6 address but that just means hackers who know the ranges can target them, in the hope of discovering win10+ installations which are not behind NAT.

Yes, IPv6 is more or less as secure or insecure as IPv4. But this isn't the point, it's the lack of IPv4 address space. Which predefined IPv6 address do you mean? Loopback, link-local , ULA, multicast or global unicast? And even public unicast doesn't mean that a criminal can simply access your device. Usually you would have a SOHO router with a stateful firewall in front of the device, besides the device coming with its own firewall/protection.

[capt bullshot]

Remember, the original purpose of HTTPS was to protect the traffic from eavesdropping, not to securely identify and authenticate the server / client.

I don't know where you get this from, secure identification of both the server and client is a key feature / raison d'etre of TLS and by extension HTTPS.

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on the Internet.[1][2] In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS,[3] or HTTP over SSL.

The principal motivations for HTTPS are authentication of the accessed website, and protection of the privacy and integrity of the exchanged data while in transit. It protects against man-in-the-middle attacks, and the bidirectional encryption of communications between a client and server protects the communications against eavesdropping and tampering.[4][5] The authentication aspect of HTTPS requires a trusted third party to sign server-side digital certificates. This was historically an expensive operation, which meant fully authenticated HTTPS connections were usually found only on secured payment transaction services and other secured corporate information systems on the World Wide Web. In 2016, a campaign by the Electronic Frontier Foundation with the support of web browser developers led to the protocol becoming more prevalent.[6] HTTPS is now used more often by web users than the original non-secure HTTP, primarily to protect page authenticity on all types of websites; secure accounts; and to keep user communications, identity, and web browsing private.

So no client authentication and "expensive" server authentication requiring external infrastructure.
Yes, HTTPS (on SSL and later TLS) provided server authentication but due to the required infrastructure and because you'd have to trust a third party authority, it was (and is) often called "broken by design". So IMNSHO HTTPS is just good for preventing eavesdropping.
Inside a corporate network, as a stupid end user on a company provided computer you're usually not even protected from eavesdropping because the company proxy does a "man in the middle" on your HTTPS connections for "corporate security" reasons and normally you don't even notice that since the IT department silently supplies their "not trustworthy" certificates to your browser.

[ve7xen]

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on the Internet.[1][2] In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS,[3] or HTTP over SSL.

Okay, agreed...

The principal motivations for HTTPS are authentication of the accessed website

When the first 'principal motivation' listed is exactly what I said, it's pretty clear your argument doesn't hold up here. Certificate validation has been done since day-0 of HTTPS support in browsers - it is a MUST in the RFC, and client authentication has likewise been supported for a looong time, though it's not widely used. This functionality is inherited from SSL/TLS.

Management of the trust is an entirely separate issue, and yes the typical setup is not that strong, but this isn't anything to do with HTTPS or TLS, but how we have decided to ship a default trust store with browsers / operating systems and allow any public entity to obtain a certificate. You can easily implement it in such a way that only explicit trust is allowed, which is what you would probably want to do in a closed system like an IoT platform, for several reasons.

[madires]

SSL client certs are usually not used for HTTPS connections. But it's a feature of SSL/TLS and some services are using this. It can be used as 2FA method, for example.

[capt bullshot]

The principal motivations for HTTPS are authentication of the accessed website

When the first 'principal motivation' listed is exactly what I said, it's pretty clear your argument doesn't hold up here. Certificate validation has been done since day-0 of HTTPS support in browsers - it is a MUST in the RFC, and client authentication has likewise been supported for a looong time, though it's not widely used. This functionality is inherited from SSL/TLS.

Management of the trust is an entirely separate issue, and yes the typical setup is not that strong, but this isn't anything to do with HTTPS or TLS, but how we have decided to ship a default trust store with browsers / operating systems and allow any public entity to obtain a certificate. You can easily implement it in such a way that only explicit trust is allowed, which is what you would probably want to do in a closed system like an IoT platform, for several reasons.

Remeber, early versions of most browsers didn't complain on invalid or self signed certificates. So yes, I agree, server authentication was a principal intention of HTTPS, but wasn't trustworthy at all in the past. And "marketing" of HTTPS in its early and middle age days didn't emphasize on authenticating the server but rather "protecting your secret password" and preventing "eavesdropping your secret email". Today, this has changed, but In my still not so humble opinion it's borked more than ever because you need all that fragile infrastructure to secure the trust.
Of course, you still can provide your own trusted certificates for your own servers and your own clients to protect them from the public.

[peter-h]

Shared keys ship with the box and will eventually get extracted, if history is any indication, and then you're hosed, so that's not really a strong solution.

However, isn't that the same as if your box contains the certificate of your private server an somebody can replace that certificate...

No physical security = no security

early versions of most browsers didn't complain on invalid or self signed certificates

I think this is another reason for "HTTPS everywhere". Browsers warn your customers that they are going to die. But if you have a box which is a server, the certificate in that box will have to be self-signed, won't it?

Currently, it is still possible to config routers over HTTP locally, and remotely over HTTPS but the certificates there are IME always self signed.

The box I am working on has an HTTP server for LAN config etc, which will enable "secure" remote config via a VPN, if somebody really wants it. But the proper marketable way to do remote config/control is via a server and this server has to be maintained for the life of the product, which is a very tall order. Hence the HTTP server option.

[capt bullshot]

I think this is another reason for "HTTPS everywhere". Browsers warn your customers that they are going to die. But if you have a box which is a server, the certificate in that box will have to be self-signed, won't it?

A self signed cert makes your server unusable for most customers for said reasons, browsers make accepting such certs more and more complicated. You can get free and valid certs e.g. from Let's Encrypt, by they expire fast, so you'll have to make your server able to automatically renew the certs, and they have to be unique for each server then. Pretty elaborate  for an embedded device based on a typical MCU of today.

Currently, it is still possible to config routers over HTTP locally, and remotely over HTTPS but the certificates there are IME always self signed.

No, e.g. the FritzBox that is very common in Germany optionally uses Let's Encrypt certs. But they run embedded linux, so it's not too elaborate to renew them etc.

The box I am working on has an HTTP server for LAN config etc, which will enable "secure" remote config via a VPN, if somebody really wants it. But the proper marketable way to do remote config/control is via a server and this server has to be maintained for the life of the product, which is a very tall order. Hence the HTTP server option.

Agreed.
VPN or said reverse proxy that can do all the authentication and encryption stuff for you.
Before all that "cloud" hype, specialized companies sold VPN and/or reverse proxy boxes to connect between your device and the customers internet. Maybe they still exist in some niches.

All that "security" stuff has to be maintained to follow the latest "standards" or just trends. Otherwise it will be rendered obsolete by the strong opinion of the "security experts". Nothing wrong with these people, they're right in many aspects, but often they just don't understand it's pretty much impossible to maintain an embedded "server" according to their latest advice. So one needs some external means to stay secure here anyway.

[SiliconWizard]

If you want each of your devices to act as a server directly accessible through HTTPS and you can't use a self-signed certificate, it's going to cost you uh....

[ve7xen]

However, isn't that the same as if your box contains the certificate of your private server an somebody can replace that certificate...

No physical security = no security

The difference being it's trivial to revoke the compromised certificate without affecting the rest of the products in the field. The other difference is that the client certificate uniquely identifies a device (in the use case I describe, anyway), so exposure of one certificate also doesn't mean they have carte blanche to write data with assumed identity.

early versions of most browsers didn't complain on invalid or self signed certificates

I'd kinda need to see a reference for this claim, I know the idea of shipping a trust store goes back at least as far as Mozilla 1.0, so 20+ years, and considering SSL itself came out of Netscape in the prior era, with all the features I'm talking about in place, I'm pretty sure this was their intent. Not really relevant today, anyway.

I think this is another reason for "HTTPS everywhere". Browsers warn your customers that they are going to die. But if you have a box which is a server, the certificate in that box will have to be self-signed, won't it?

Currently, it is still possible to config routers over HTTP locally, and remotely over HTTPS but the certificates there are IME always self signed.

Yes, if the box itself is a server, you'd either need it to be self-signed, or signed by a CA that you control. It's not going to be economical or sensible to ship certificates that allow default trust on common platforms, and doesn't really add any value, which is why you usually see them using self-signed certificates here.

In what I thought you were talking about - my bad if I misinterpreted - where the client is the device reaching out to a server on the Internet, you can establish your own CA, and then make that the (only) trusted CA in your IoT device's trust store. A browser connecting to your API service is going to throw a security warning due to lack of trust, but your device will trust this certificate and work fine.

The box I am working on has an HTTP server for LAN config etc, which will enable "secure" remote config via a VPN, if somebody really wants it. But the proper marketable way to do remote config/control is via a server and this server has to be maintained for the life of the product, which is a very tall order. Hence the HTTP server option.

Yeah in this case HTTPS for local configuration is not adding much value, at least as long as users aren't going to be expected to want to expose it publicly (which is a terrible idea, TLS or not).

[capt bullshot]

However, isn't that the same as if your box contains the certificate of your private server an somebody can replace that certificate...

No physical security = no security

The difference being it's trivial to revoke the compromised certificate without affecting the rest of the products in the field. The other difference is that the client certificate uniquely identifies a device (in the use case I describe, anyway), so exposure of one certificate also doesn't mean they have carte blanche to write data with assumed identity.

In theory, yes. But revoking an individual certificate relies on reaching the critical participants with the revoke requests. If your infrastructure doesn't provide for this in a reliable way, nothing gets revoked.

[ve7xen]

In theory, yes. But revoking an individual certificate relies on reaching all parties with the revoke requests. If your infrastructure doesn't provide for this in a reliable way, nothing gets revoked.

My comments here are context-aware. We are talking about a closed system with a self-managed PKI for an IoT platform. This is trivial to accomplish in that setting.

[capt bullshot]

early versions of most browsers didn't complain on invalid or self signed certificates

I'd kinda need to see a reference for this claim, I know the idea of shipping a trust store goes back at least as far as Mozilla 1.0, so 20+ years, and considering SSL itself came out of Netscape in the prior era, with all the features I'm talking about in place, I'm pretty sure this was their intent. Not really relevant today, anyway.

OK, you've got me on this one. Afair, early browers warned once when they encountered a self-signed or otherwise bad cert (e.g. wrong domain), but with one click you usually accepted this forever with no visible indication from this point on. Many old versions of command line tools didn't complain at all with their default settings.

In theory, yes. But revoking an individual certificate relies on reaching all parties with the revoke requests. If your infrastructure doesn't provide for this in a reliable way, nothing gets revoked.

My comments here are context-aware. We are talking about a closed system with a self-managed PKI for an IoT platform. This is trivial to accomplish in that setting.

Yep, missed that one too. If do it all on your own, you're in charge to track all issued certs, enter and propagate the revokes and of course you never forget to do so and your system always works flawlessly.

[peter-h]

A self signed cert makes your server unusable for most customers for said reasons, browsers make accepting such certs more and more complicated. You can get free and valid certs e.g. from Let's Encrypt, by they expire fast, so you'll have to make your server able to automatically renew the certs, and they have to be unique for each server then. Pretty elaborate  for an embedded device based on a typical MCU of today.

IME, looking after a few websites, this is just a road to hell. These cheap or free rapidly-expiring certs just keep breaking your system, because you have to set up a cron job or whatever to keep renewing them, and then the issuer disappears so you have to change... This alone is a good reason to front your server with Cloudflare (which is free for noncommercial users).

the FritzBox that is very common in Germany optionally uses Let's Encrypt certs. But they run embedded linux, so it's not too elaborate to renew them etc.

They probably do the above, which works until it stops working

In what I thought you were talking about - my bad if I misinterpreted - where the client is the device reaching out to a server on the Internet, you can establish your own CA, and then make that the (only) trusted CA in your IoT device's trust store. A browser connecting to your API service is going to throw a security warning due to lack of trust, but your device will trust this certificate and work fine.

Yes, I think exactly that. My box doesn't have enough RAM for both HTTPS client and server anyway So it has HTTP server, and an NTTPS client whose sole purpose will be going out to some specific servers. If server authentication is needed (read: if the customer demands it) then the box can store that server's self signed cert, which will have a 100 year life.

If you want each of your devices to act as a server directly accessible through HTTPS and you can't use a self-signed certificate, it's going to cost you uh....

Yes and this, together with the continually worsening browser acceptance of self signed certs, is another reason why IOT is rarely going to be running exposed. I thought there was some way around this (e.g. getting Verisign to somehow sign 100000 certificates) but clearly there isn't.

[capt bullshot]

A self signed cert makes your server unusable for most customers for said reasons, browsers make accepting such certs more and more complicated. You can get free and valid certs e.g. from Let's Encrypt, by they expire fast, so you'll have to make your server able to automatically renew the certs, and they have to be unique for each server then. Pretty elaborate  for an embedded device based on a typical MCU of today.

IME, looking after a few websites, this is just a road to hell. These cheap or free rapidly-expiring certs just keep breaking your system, because you have to set up a cron job or whatever to keep renewing them, and then the issuer disappears so you have to change... This alone is a good reason to front your server with Cloudflare (which is free for noncommercial users).

the FritzBox that is very common in Germany optionally uses Let's Encrypt certs. But they run embedded linux, so it's not too elaborate to renew them etc.

They probably do the above, which works until it stops working

Fully agree to your points

In what I thought you were talking about - my bad if I misinterpreted - where the client is the device reaching out to a server on the Internet, you can establish your own CA, and then make that the (only) trusted CA in your IoT device's trust store. A browser connecting to your API service is going to throw a security warning due to lack of trust, but your device will trust this certificate and work fine.

Yes, I think exactly that. My box doesn't have enough RAM for both HTTPS client and server anyway So it has HTTP server, and an NTTPS client whose sole purpose will be going out to some specific servers. If server authentication is needed (read: if the customer demands it) then the box can store that server's self signed cert, which will have a 100 year life.

This works until the security experts found a feasible way to attack and re-create your self-signed server cert

Security is a never ending rat race.

[ve7xen]

IME, looking after a few websites, this is just a road to hell. These cheap or free rapidly-expiring certs just keep breaking your system, because you have to set up a cron job or whatever to keep renewing them, and then the issuer disappears so you have to change... This alone is a good reason to front your server with Cloudflare (which is free for noncommercial users).

Let's Encrypt isn't likely to go anywhere soon, and it's been a pretty big boon for security in the long-tail of the Internet, though yeah I'd probably not bake a third-party service into my IoT product. But there's another, probably bigger, problem using these ACME issuers for IoT devices, which is that they are based on DNS names and a challenge to prove ownership. You can't assume your box is exposed to the Internet to accept a challenge, or even that it has Internet access at all, if this is about local configuration. It might work for a router, which does usually have a public IP and can register itself a DNS name and a way to respond to challenges, as well as usually a DNS server so you can access the device's internal interface with a public hostname, but the IoT environment is a lot more constrained.

It'd actually be kind of reasonable for router vendors to start including an MQTT broker, and doing this certificate magic to make it accessible from your smartphone or whatever in a federated and fairly secure way, without relying on anyone's cloud service. But good luck, the industry is way too fragmented for something like that.

[gmb42]

I would actually be quite interested in opinions on which cipher suites are worth supporting in a product launched say today but which has to be compatible, as an HTTPS client, with other old stuff.

As a client, probably old stuff doesn't matter much.

Much of the size of MbedTLS is cipher suites.

If you restrict yourself to TLS 1.3 then the range of mandatory cipher suites is much reduced, see RFC 8846 Sect 9.1.

[gmb42]

Shared keys ship with the box and will eventually get extracted, if history is any indication, and then you're hosed, so that's not really a strong solution.

However, isn't that the same as if your box contains the certificate of your private server an somebody can replace that certificate...

No physical security = no security

To be pedantic the certificate is public knowledge, it's sent to the client.  It's the associated private key you have to protect, hopefully inside a secure enclave of some description.

[peter-h]

I'd probably not bake a third-party service into my IoT product.

Exactly. This is the main challenge: how to get a long product life.

I think one needs a route for doing firmware upgrades, and having the box "check in" to a server periodically is a good way to do it. And that has to be fairly secure otherwise, accidentally, or deliberately, somebody could brick all your boxes

If you restrict yourself to TLS 1.3 then the range of mandatory cipher suites is much reduced, see RFC 8846 Sect 9.1.

Doesn't that restrict compatibility a lot?

It's the associated private key you have to protect, hopefully inside a secure enclave of some description.

That's very difficult. I think a smartcard chip is the only way.

[westfw]

IOT boxes can't be on open ports, because these are discovered by sniffers almost immediately, due to back doors and vulnerabilities which cannot be fixed ... so their "internet access" can only be as a client, calling up some server, and hidden behind a NAT router.

I am not convinced of this argument.  For an IoT box, you ought to be able to limit the "attack surface" to a manageable size, with or without "full TLS support."
To some extent, I think it's a myth spread by the "IoT Server/Service" vendors (for obvious reasons.)
And laziness by IoT developers.  "We'll just run linux!  That'll make it all easy!"  :-(

(For instance, are their any known attacks for the WizNet embedded TCP chips?  Or the default ESP8266 AT-based TCP connections?  (DoS doesn't count.))

[peter-h]

I think it's a myth spread by the "IoT Server/Service" vendors

That is bound to happen

I have no knowledge of specifics of the hardware and software involved but having seen the poor state of the ETH code supplied by ST with the Cube IDE kit, I would expect loads of bugs, buffer overflow / stack overflow issues etc. The stuff seems to have been written by total amateurs. So I think crashing the box is probably not at all hard, but the consequences are minimal if you have a watchdog. If the 32F4 in my target crashes with say an illegal address or illegal instruction trap (the usual case after a stack corruption) the watchdog reboots it. In most applications the reboot will not even be noticed - about 3 seconds, of which 1.6 secs is the watchdog timeout.

Apart from crashing, what is the worst an attacker can do? With most server attack scenarios the attacker is after "fun" stuff like data theft, data deletion, or remote control of something. But most embedded boxes don't even have what one might call an OS. There is usually no file system and if there was, say FatFS, you won't get a console access to it, to run rm -r. As you say, the scope for these attacks will be limited in most cases.

But if somebody sold say 100k+ boxes, and an exploit became known, a thousands hackers would be in there even just to crash them. The obvious candidate is the Amazon Alexa - a fantastic "spy box", almost as good as a webcam in every house. But they are all behind NAT, and connecting only to Amazon's servers.

So this is especially a risk with linux based boxes, which is how a lot of consumer IT is done, and most chinese ripoffs are exactly that. Nearly all routers I have ever seen are linux boxes, so if you get root access you can do what you like. Old Drayteks were some custom OS... which ran fast. Their current models are linux and slow as a pig.

DOS will always be a threat because in domestic / small business cases it will be on ADSL which is dead easy to saturate, a firewall is of no help at all, but somebody must really hate you to set that up And the "cloud server" can go behind Cloudflare; this is their main business.

[tellurium]

(For instance, are their any known attacks for the WizNet embedded TCP chips?  Or the default ESP8266 AT-based TCP connections?  (DoS doesn't count.))

ESP32/ESP8266 - yes, CVE-2019-12586

[peter-h]

Great reading around above CVE

Somehow it doesn't surprise me that this is a WIFI attack.

But it seems to just crash the device, so presumably a watchdog would reboot it. So this is a DOS attack because you could park your car outside the factory and let it run all day. Not as good as installing a fake DNS server on their LAN, which has also been done from a car parked outside

[madires]

DOS will always be a threat because in domestic / small business cases it will be on ADSL which is dead easy to saturate, a firewall is of no help at all, but somebody must really hate you to set that up And the "cloud server" can go behind Cloudflare; this is their main business.

You can hire a DDoS service for just 25 bucks. It seems to be popular with online gamers to annoy competitors. And Cloudflare had a hiccup (websites unreachable) this morning - funny coincidence.