8 ms·

It’s a glaring security hole, IMHO. I create such devices and the only way I know is self-signed certs, but the browsers complain a lot about that. Ideally ther

It’s a glaring security hole, IMHO. I create such devices and the only way I know is self-signed certs, but the browsers complain a lot about that. Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices/services and that the identity isn’t verified by https like most sites. The issue lies between the browsers and https system. SSH can do encryption without requiring identity verification. It handles it by asking "Do you want to trust this new server?". Then if it changes informs you of that. Browsers could easily implement that for .local with self-signed certs. Of course browser developers assume everyone has internet all the time and you only access servers with signed domains. I’ve wondered what it’d take to get an ITEF/W3C RFQ published for .local self-signed behavior. (Edit: RFQ, not my autocomplete’s RTF)

paledot 6y ago
I love this idea. There are enough influential tech people who read HN, can we make this happen please?
- Sebb767 6y ago
  Thirded. This sounds like a sound solution.
arwineap 6y ago
> It handles it by asking "Do you want to trust this new server?" That's basically how it works though; your OS packages a group of trusted CA certs. You can add additional trusted CA certs, even ones minted by you to ensure your apps trust the connection
- loeg 6y ago
  The mechanism SSH uses is called Trust on First Use ("TOFU") and is closer to what used to be HTTPS certificate pinning. In this scheme, certificates never expire, and if they do, clients warn about the unexpected change in certificate. It is different from the CA PKI system, where the client trusts any certificate signed by a trusted CA without prompting the user at all, and doesn't prompt the user if the certificate for a site changes.
  - zozbot234 6y ago
    Self-signed certificates give you basically this. It's a bit of a hassle to mark them as trusted, but you only have to do it once.
    - loeg 6y ago
      That has not been my experience with current versions of Chrome.
- paledot 6y ago
  There are two options: * Manually install a root certificate, which is a confusing process for most end users and a non-starter for anyone who cares about security. (Imagine walking your parents through the process.) * Trust a self-signed certificate, which is an increasingly difficult and counterintuitive process since Chrome and Firefox started competing to see who could destroy their usefulness faster. I'm not even sure if it's possible anymore. Neither of these are acceptable.
  - Spivak 6y ago
    I mean I’m not sure if there’s a solution that will make everyone happy then. Making trusting self-signed cheers easy and not scary has real security implications because users just click-through warnings.
    - elcritch 6y ago
      That’s why self-signed and "local signed" should be distinct concepts, IMHO. The .local domain is already special cased, and could provide a different UI path more akin to how SSH works. AFAICT, you can’t get a https cert for a .local domain, so it’d not break existing https security model. It’d provide a more secure way for apps like syncthing to provide a secure local UI as well. Getting browsers to accept my self-signed certificate is a pain and makes people just use http.
    - imtringued 6y ago
      Making casual users create their own root certificates sounds like an even worse problem. Now an attacker isn't restricted to impersonating your lightbulbs. They can impersonate any domain if they can get your private CA. Now imagine if an IoT vendor engages in questionable practices like creating the CA for you and the user only has to download an exe that automatically installs the root certificate. The benefit for the vendor would be that all devices you order from their website would be shipped with correctly signed https certificates. Later a hacker dumps the database with root CAs and uses it to impersonate your bank.
  - arwineap 6y ago
    Honestly, I don't trust most end users to install root certificates If you are doing something for an end user, I think it makes a lot of sense just to get a certificate; it's just not a large barrier anymore.
sokoloff 6y ago
Why do you need to use self-signed certs? (As contrasted with CA-signed certs that happen to be signed by a CA that you own and trust as suggested by arwineap?) It took my a little over an hour one evening to figure out how to create my own CA, trust it, and sign certs for all my local devices (except my UniFi cloud controller which I admit I gave up on due to time).
- CydeWeys 6y ago
  Because 99.99%+ of users don't have the technical skill to do this, but still need to be able to access local devices and it would sure be good if they could do so in a secure manner?
  - CountSessine 6y ago
    So the answer is to subvert the global certificate infrastructure that protects web traffic? No, it isn’t. Your IoT device has no security at all if a non-technical user is setting it up or if it doesn’t have a way of accepting a user configured certificate, and you shouldn’t pretend otherwise by dressing it up in bad certificates and worthless encrypted tunnels. Just use HTTP.
    - Spivak 6y ago
      I mean if they’re worthless tunnels then so is every SSH tunnel. Should we just go back to telnet?
      - CountSessine 6y ago
        On your own network? Does it really matter whether you use telnet or ssh? And if it’s on a shared network, don’t you have an IT department that can set up the local key infrastructure and push out certificates? The argument here is that we should enable lots of shitty IoT devices to masquerade as being secure, and inure browser users to click ‘yes’ to accepting a broken certificate. If it’s on a managed network, IT can set up a certificate and push that out to client machines. If it’s on your home network you can do that (unless your IoT device can’t take a user configured client cert, in which case it’s rubbish anyways), and if you can’t then you might as well use HTTP.
CountSessine 6y ago
It handles it by asking "Do you want to trust this new server?" Asking the end user to accept downgraded security is a huge security antipattern. Also, if I’m operating an evil wifi AP at a coffee shop and I intercept your web request for bankofamerica.com with a redirect to bankofamerica.local, would HSTS prevent the redirect? Or could I then serve you a bad cert and trick you into accepting it? Also, what sokoloff said makes a lot of sense. Encryption without authentication is worthless, and that cert chain only works in so far as someone at the top vouches for someone’s identity. If that’s your print server, then you are the one vouching for its identity. It makes more sense for you to be the certificate authority and just build your own cert chain.
- sukilot 6y ago
  If the browser correctly explained what you were doing, and warned you that this is an attack unless you are in control of the entire network and the machines on it, I don't see the problem.
  - CountSessine 6y ago
    What would it say? “You’re connecting to an IoT device that has a worthless certificate. Would you like me to open up a completely pointless AES256 session with it and pretend that you have a secure connection?” Just use HTTP.
    - filmor 6y ago
      HTTP traffic would be unencrypted, so everyone (esp. on Wifi) could record passwords etc. flying around. With HTTPS, you at least need to MITM the connection to do that. If you establish trust in some other way (cert ID printed on the device?), the connection is secure.
      - riskable 6y ago
        Not just intercept: Using HTTPS prevents messing with the connection in-flight. So an attacker won't be able to inject their own payload into that web page you just requested.
kube-system 6y ago
How is that different than how self signed certs work now? My browser warns me, I can accept the warning for that particular certificate, and it warns me again if it changes..
- fomine3 6y ago
  At least for Chrome and Firefox, I can't accept self-signed cert easily for permanently. It asks again if I exited the browser.
  - kube-system 6y ago
    Do you have them configured to clear those settings on exit? Is the certificate actually the same when you visit the site again? Chrome and Firefox remember the acceptance of self-signed certs for a long time on my PC.
mkl 6y ago
> SSH can do encryption without requiring identity verification. It handles it by asking "Do you want to trust this new server?". The problem is to figure out whether to trust the server you need to get its fingerprint through another channel. Is there an HTTPS equivalent of that?
- lukeschlather 6y ago
  You don't need to get the fingerprint through another channel. Getting the fingerprint through another channel prevents some classes of attacks. Blindly storing the first fingerprint offered also prevents a variety of attacks.
akira2501 6y ago
> Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices/services and that the identity isn’t verified by https like most sites. For these types of sites we run a local CA, and sign regular certificates for these domains and then distribute the CA certificate to our windows clients through a GPO. When put into the correct store, all our "locally-signed" certificates show as valid. In other instances, where I haven't been able to do that, like for disparate VPN clients and such I will generally assign a RFC1918 address to it. Like service.vpn.ourdomain.com resolves to 10.92.83.200. As long as I can respond to a DNS challenge, I can still get a letsencrypt certificate for that domain.
- elcritch 6y ago
  That works if you have control over the device/network. IoT devices usually don’t work that way. It’d be nice to be able to ensure the passcode to the device isn’t broadcast in clear http.
- johntash 6y ago
  > In other instances, where I haven't been able to do that, like for disparate VPN clients and such I will generally assign a RFC1918 address to it. Like service.vpn.ourdomain.com resolves to 10.92.83.200. As long as I can respond to a DNS challenge, I can still get a letsencrypt certificate for that domain. This is basically what I've been doing lately as well. I'll create a wildcard letsencrypt cert for .vpn.ourdomain.com and then point the subdomains to internal IPs. You can even set up a split-dns where it responds to the challenge txt records for letsencrypt, but only the internal side responds to requests under .vpn.ourdomain.com.
frutiger 6y ago
> (Edit: RFQ, not my autocomplete’s RTF) Sorry for the mostly insubstantial comment but it may help you in the future: it’s RFC (Request For Comments) not RFQ. And it’s IETF (Internet Engineering Task Force) not ITEF.
jopsen 6y ago
Crazy idea: Why not serve an initial page over HTTP, and then implement encryption in JS using webcrypto for all subsequent calls. I'm not sure self-signed HTTPS can do much better than this anyways. (Yes, yes, it's a crazy idea, hehe)
- dylz 6y ago
  You can no longer do webcrypto because the initial page is compromised. Self signed HTTPS works for this case as long as you know the fingerprint/cert to accept.
  - jopsen 6y ago
    Oh, yeah... webcrypto only works on HTTPS. So you would need to ship a crypto library in JS, hehe :) Self-signed certs probably does work, if you install the certificate root on your machine. It just not something you would advice end-users to do.
    - dylz 6y ago
      The other problem is shipping a crypto library if the entire page and script is not served over HTTPS means that it's no longer useful, because the crypto library is compromised.

paledot 6y ago

I love this idea. There are enough influential tech people who read HN, can we make this happen please?

Sebb767 6y ago
Thirded. This sounds like a sound solution.

arwineap 6y ago

> It handles it by asking "Do you want to trust this new server?" That's basically how it works though; your OS packages a group of trusted CA certs. You can add additional trusted CA certs, even ones minted by you to ensure your apps trust the connection

loeg 6y ago
The mechanism SSH uses is called Trust on First Use ("TOFU") and is closer to what used to be HTTPS certificate pinning. In this scheme, certificates never expire, and if they do, clients warn about the unexpected change in certificate. It is different from the CA PKI system, where the client trusts any certificate signed by a trusted CA without prompting the user at all, and doesn't prompt the user if the certificate for a site changes.
- zozbot234 6y ago
  Self-signed certificates give you basically this. It's a bit of a hassle to mark them as trusted, but you only have to do it once.
  - loeg 6y ago
    That has not been my experience with current versions of Chrome.
paledot 6y ago
There are two options: * Manually install a root certificate, which is a confusing process for most end users and a non-starter for anyone who cares about security. (Imagine walking your parents through the process.) * Trust a self-signed certificate, which is an increasingly difficult and counterintuitive process since Chrome and Firefox started competing to see who could destroy their usefulness faster. I'm not even sure if it's possible anymore. Neither of these are acceptable.
- Spivak 6y ago
  I mean I’m not sure if there’s a solution that will make everyone happy then. Making trusting self-signed cheers easy and not scary has real security implications because users just click-through warnings.
  - elcritch 6y ago
    That’s why self-signed and "local signed" should be distinct concepts, IMHO. The .local domain is already special cased, and could provide a different UI path more akin to how SSH works. AFAICT, you can’t get a https cert for a .local domain, so it’d not break existing https security model. It’d provide a more secure way for apps like syncthing to provide a secure local UI as well. Getting browsers to accept my self-signed certificate is a pain and makes people just use http.
  - imtringued 6y ago
    Making casual users create their own root certificates sounds like an even worse problem. Now an attacker isn't restricted to impersonating your lightbulbs. They can impersonate any domain if they can get your private CA. Now imagine if an IoT vendor engages in questionable practices like creating the CA for you and the user only has to download an exe that automatically installs the root certificate. The benefit for the vendor would be that all devices you order from their website would be shipped with correctly signed https certificates. Later a hacker dumps the database with root CAs and uses it to impersonate your bank.
- arwineap 6y ago
  Honestly, I don't trust most end users to install root certificates If you are doing something for an end user, I think it makes a lot of sense just to get a certificate; it's just not a large barrier anymore.

sokoloff 6y ago

Why do you need to use self-signed certs? (As contrasted with CA-signed certs that happen to be signed by a CA that you own and trust as suggested by arwineap?) It took my a little over an hour one evening to figure out how to create my own CA, trust it, and sign certs for all my local devices (except my UniFi cloud controller which I admit I gave up on due to time).

CydeWeys 6y ago
Because 99.99%+ of users don't have the technical skill to do this, but still need to be able to access local devices and it would sure be good if they could do so in a secure manner?
- CountSessine 6y ago
  So the answer is to subvert the global certificate infrastructure that protects web traffic? No, it isn’t. Your IoT device has no security at all if a non-technical user is setting it up or if it doesn’t have a way of accepting a user configured certificate, and you shouldn’t pretend otherwise by dressing it up in bad certificates and worthless encrypted tunnels. Just use HTTP.
  - Spivak 6y ago
    I mean if they’re worthless tunnels then so is every SSH tunnel. Should we just go back to telnet?
    - CountSessine 6y ago
      On your own network? Does it really matter whether you use telnet or ssh? And if it’s on a shared network, don’t you have an IT department that can set up the local key infrastructure and push out certificates? The argument here is that we should enable lots of shitty IoT devices to masquerade as being secure, and inure browser users to click ‘yes’ to accepting a broken certificate. If it’s on a managed network, IT can set up a certificate and push that out to client machines. If it’s on your home network you can do that (unless your IoT device can’t take a user configured client cert, in which case it’s rubbish anyways), and if you can’t then you might as well use HTTP.

CountSessine 6y ago

It handles it by asking "Do you want to trust this new server?" Asking the end user to accept downgraded security is a huge security antipattern. Also, if I’m operating an evil wifi AP at a coffee shop and I intercept your web request for bankofamerica.com with a redirect to bankofamerica.local, would HSTS prevent the redirect? Or could I then serve you a bad cert and trick you into accepting it? Also, what sokoloff said makes a lot of sense. Encryption without authentication is worthless, and that cert chain only works in so far as someone at the top vouches for someone’s identity. If that’s your print server, then you are the one vouching for its identity. It makes more sense for you to be the certificate authority and just build your own cert chain.

sukilot 6y ago
If the browser correctly explained what you were doing, and warned you that this is an attack unless you are in control of the entire network and the machines on it, I don't see the problem.
- CountSessine 6y ago
  What would it say? “You’re connecting to an IoT device that has a worthless certificate. Would you like me to open up a completely pointless AES256 session with it and pretend that you have a secure connection?” Just use HTTP.
  - filmor 6y ago
    HTTP traffic would be unencrypted, so everyone (esp. on Wifi) could record passwords etc. flying around. With HTTPS, you at least need to MITM the connection to do that. If you establish trust in some other way (cert ID printed on the device?), the connection is secure.
    - riskable 6y ago
      Not just intercept: Using HTTPS prevents messing with the connection in-flight. So an attacker won't be able to inject their own payload into that web page you just requested.

kube-system 6y ago

How is that different than how self signed certs work now? My browser warns me, I can accept the warning for that particular certificate, and it warns me again if it changes..

fomine3 6y ago
At least for Chrome and Firefox, I can't accept self-signed cert easily for permanently. It asks again if I exited the browser.
- kube-system 6y ago
  Do you have them configured to clear those settings on exit? Is the certificate actually the same when you visit the site again? Chrome and Firefox remember the acceptance of self-signed certs for a long time on my PC.

mkl 6y ago

> SSH can do encryption without requiring identity verification. It handles it by asking "Do you want to trust this new server?". The problem is to figure out whether to trust the server you need to get its fingerprint through another channel. Is there an HTTPS equivalent of that?

lukeschlather 6y ago
You don't need to get the fingerprint through another channel. Getting the fingerprint through another channel prevents some classes of attacks. Blindly storing the first fingerprint offered also prevents a variety of attacks.

akira2501 6y ago

> Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices/services and that the identity isn’t verified by https like most sites. For these types of sites we run a local CA, and sign regular certificates for these domains and then distribute the CA certificate to our windows clients through a GPO. When put into the correct store, all our "locally-signed" certificates show as valid. In other instances, where I haven't been able to do that, like for disparate VPN clients and such I will generally assign a RFC1918 address to it. Like service.vpn.ourdomain.com resolves to 10.92.83.200. As long as I can respond to a DNS challenge, I can still get a letsencrypt certificate for that domain.

elcritch 6y ago
That works if you have control over the device/network. IoT devices usually don’t work that way. It’d be nice to be able to ensure the passcode to the device isn’t broadcast in clear http.
johntash 6y ago
> In other instances, where I haven't been able to do that, like for disparate VPN clients and such I will generally assign a RFC1918 address to it. Like service.vpn.ourdomain.com resolves to 10.92.83.200. As long as I can respond to a DNS challenge, I can still get a letsencrypt certificate for that domain. This is basically what I've been doing lately as well. I'll create a wildcard letsencrypt cert for .vpn.ourdomain.com and then point the subdomains to internal IPs. You can even set up a split-dns where it responds to the challenge txt records for letsencrypt, but only the internal side responds to requests under .vpn.ourdomain.com.

frutiger 6y ago

> (Edit: RFQ, not my autocomplete’s RTF) Sorry for the mostly insubstantial comment but it may help you in the future: it’s RFC (Request For Comments) not RFQ. And it’s IETF (Internet Engineering Task Force) not ITEF.

jopsen 6y ago

Crazy idea: Why not serve an initial page over HTTP, and then implement encryption in JS using webcrypto for all subsequent calls. I'm not sure self-signed HTTPS can do much better than this anyways. (Yes, yes, it's a crazy idea, hehe)

dylz 6y ago
You can no longer do webcrypto because the initial page is compromised. Self signed HTTPS works for this case as long as you know the fingerprint/cert to accept.
- jopsen 6y ago
  Oh, yeah... webcrypto only works on HTTPS. So you would need to ship a crypto library in JS, hehe :) Self-signed certs probably does work, if you install the certificate root on your machine. It just not something you would advice end-users to do.
  - dylz 6y ago
    The other problem is shipping a crypto library if the entire page and script is not served over HTTPS means that it's no longer useful, because the crypto library is compromised.