7 ms·

The domain in question (drmlocal.cisco.com) resolves to 127.0.0.1. This is a handy and above all cross-platform/cross browser way for a website to talk to a loc

by pilif 9y ago

The domain in question (drmlocal.cisco.com) resolves to 127.0.0.1. This is a handy and above all cross-platform/cross browser way for a website to talk to a locally installed application (that's running a web server, bound to the loopback interface) by using CORS and/or jsonp. If the site that wants to make use of this is using SSL, then the locally running web browser also needs to be using SSL and it needs to have a publicly trusted cert. The other alternative (installing a local CA) seems to be worse. An option would be for the locally installed app to ask a server for a cert to use while it's running, but that means that the app needs to phone home which it otherwise would not have to. So I guess we're back to proprietary browser extensions if this technique is frowned upon.

Nullabillity 9y ago
This technique is already the equivalent of a proprietary browser plugin, except for that it's running completely outside of the browser sandbox. The proper fix here is to stop with the DRM bullshit and just use HTML5 <video> like everyone else.
- notyourwork 9y ago
  Can you elaborate on use html5 <video> like everyone else? I am not familiar with this technique.
- pilif 9y ago
  In my case I’m using this to allow people to read data from a locally connected (via USB) barcode scanner. Remind me again how <video> would be of help there?
  - Nullabillity 9y ago
    If you already need a native driver then you might as well make the whole thing native.
euroclydon 9y ago
I actually need to do this. Is there a best practice for handling the certificate? It needs to be installed on the machine for the browser to trust it. All I can think of is to make a new certificate for every machine at install time and binding an obscure domain name to the loopback interface, so it would be highly unlikely to overlap with a real site.
- ploxiln 9y ago
  You can do what Cisco did with the domain name. Just don't create a CA-trusted cert for it. Instead, as you suppose, generate a unique cert on each machine and install it to the appropriate/needed trust stores on that machine.
- justinclift 9y ago
  The Plex approach, pointed out above by diafygi above might suit you. https://news.ycombinator.com/item?id=14595269 You need a wildcard cert (not hard), and a DNS resolver (daemon) to respond back with custom IP address. Sounds pretty simple in concept. :)
  - pilif 9y ago
    A wildcard won’t help much. If you want to do this correctly, then each client needs to generate a unique certificate and private key. The name in the certificate, the custom resolver helps with, but now you’re stuck with that uniquely generated certificate which you now need signed by a CA. And this is the step that’s problematic: that host is not connectable from the outside, so there’s no way for, say, let’s encrypt to do http validation (even if their usage quota would allow to do this at scale, which it doesn’t), so you’d have to do domain validation which would work, but would require your clients to ship their private keys to the server which is a big nono again. You could also do some crazy polling approach in order to have your server relay between the DNS validation by let’s encrypt and your client (which, again, usually is behind a NAT and firewall, so it has to poll the server to have the possibility to send the response to the ACME challenge), but this is a huge amount of work, and, again, doesn’t work because of per-domain quotas. So now you’re stuck with a custom solution with a CA which involves you having a trusted signed CA certificate (good luck getting that one) and providing these clients with an API or having a CA providing a custom API for these clients to use. None of these things are widely available and as they are custom solutions, I’m sure CAs will require a lot of money for, provided they even talk to you at all if you are a small company.
asdfaoeu 9y ago
It looks like browsers will allow you to talk to localhost from a secure page without SSL https://bugzilla.mozilla.org/show_bug.cgi?id=903966 https://bugzilla.mozilla.org/show_bug.cgi?id=903966. The other way assuming you don't need to transfer much is you can reverse proxy it out to your own server and back to your application. (Where the SSL decoding is done by the remote server)
- stereo 9y ago
  Chrome doesn’t.
  - asdfaoeu 9y ago
    https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://chromium.googlesource.com/chromium/src.git/+/130ee68... ? I just saw that from the first ticket but I guess it hasn't actually been merged there's a bug though. https://bugs.chromium.org/p/chromium/issues/detail?id=607878 https://bugs.chromium.org/p/chromium/issues/detail?id=607878
stereo 9y ago
JOSM, an editor for OpenStreetMap, installs its own certificate, which is limited to https://localhost:8112 https://localhost:8112. This seems pretty safe to me - if someone can MITM that, you already have bigger problems.
- ryanlol 9y ago
  Presumably that certificate isn't actually signed by any relevant CA, right? If so it seems rather irrelevant in the context.
Kenji 9y ago
If somebody MitMs your connection to 127.0.0.1, you're hopelessly lost anyway. I don't really see a reason to protect requests that do not leave your machine.
- asdfaoeu 9y ago
  The issue is remote sites that are using SSL and want to do an Ajax request to a local site.
ejcx 9y ago
If it is local and communication never leaves the machine, why use TLS? 1Password got heat for the opposite in the past (use of ws:// between the browser extension and the Mac Client). 1Password correctly pointed out that there isn't really a point to "secure communications" if the webserver and the web client are on the same machine. If you can't trust your own machine to intercept your connection then TLS is not going to save you. What I bet happened was some project manager said "There needs to be a green check" or some security person said "You NEED TLS" and nobody spoke up that it didn't make sense. edit: I'm not a deleter, but I misunderstood your post and I realized it right after I pressed enter. Did not realize you were talking about being on a remote webpage and being connected locally.
- pilif 9y ago
  Yeah. The webpage is remote and using ssl and now wants to talk to the locally installed app. I agree that SSL doesn’t make sense there and honestly, in my opinion it would make sense for browsers to treat localhost as a secure origin. But they don’t and so we’re back to square one which is that a secured origin can’t make requests to a non secured origin. Update: newer browsers do in-fact do this. It’s also part of the WHATWG spec: https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 https://github.com/w3c/webappsec-mixed-content/commit/349501... Of course there’s still IE and Edge that are of different minds, but it’s nice to see movement
  - derefr 9y ago
    Interesting; intuitively, I would say that this should be fine for mobile browsers, but desktop browsers shouldn't be doing this—PC operating systems are still built on a fundamentally "mutually-untrustworthy multitenant time-sharing system" paradigm. Any random port on localhost (or, indeed, on any other IP assigned to the loopback interface—that's 127/8 in IPv4, you know!) can be a socket opened by a process running on your PC that was started by someone who 1. has limited shell access to your machine, but 2. who isn't you. Privileging such ports would give such attackers an easy escalation path from this limited shell access to administrative access, assuming that you yourself are a [local or domain] administrator. Mobile devices can ignore this because they're (so far) inherently single-user devices. But anything allowing multiple parallel user sessions—even a Chromebook, or an iPad in Classroom mode—shouldn't make the assumption that local ports are safe. That's how a teacher gets their password phished by their students.
diafygi 9y ago
Plex does this by generating a private key at install then issuing a real ssl cert for it. That way the private key never is seen by Plex or anyone else. Really cool technique. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
- pilif 9y ago
  Yes. But it requires them to have a CA certificate which requires special contracts with a CA. Now, Cisco could certainly do that, but for smaller companies, that‘s probably not feasible
  - koenrh 9y ago
    Not necessarily. Plex does not hold the private key for their intermediate certificate authority ('Plex Devices High Assurance CA2'). They use a DigiCert API to sign certificates under the 'plex.direct' domain.
    - pilif 9y ago
      Which means: special deal with digicert. Or can you link me to a product page where anybody can sign up?
      - Azeralthefallen 9y ago
        A company i used to work for tried to get something similar to what Digicert has with Plex, and the initial cost was very high.
      - hannob 9y ago
        Let's Encrypt. There's no reason not to use LE. You need to make sure that your device is accessible under the given subdomain for a certain period, and it may not always be trivial. But there are ways to do that.
        9y ago
ryanlol 9y ago
>So I guess we're back to proprietary browser extensions if this technique is frowned upon. It's not. You just need to not fuck it up. drmlocal.cisco.com isn't really an acceptable way of doing that because it's in the cisco.com scope, why not just have drmlocalcisco.com instead?
- vbezhenar 9y ago
  If private key is accessible to the wide public, it's considered compromised and CA must revoke the certificate. Domain doesn't matter.
0xfeba 9y ago
Microsoft was proposing to prohibit localhost connections in a new version of Edge. They, rightly, were shouted down from that position.
duskwuff 9y ago
Another option that comes to mind is a keyless SSL configuration, similar to what Cloudflare does: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
vardump 9y ago
> The domain in question (drmlocal.cisco.com) resolves to 127.0.0.1. So if someone just MITMs your clear text DNS to make drmlocal.cisco.com resolve to something else, they get your cisco.com cookies and plausible chance to impersonate Cisco? Think targeted attacks.
saurik 9y ago
Back in 2011, the HBO Go application on iOS contained a similar certificate for 127.0.0.1; I believe in that case a certificate for the bare IP address or just "localhost" that they got from Verisign. It was noticed by jan0 from the iOS jailbreak community, who had written isslfix, with the goal of hacking in a fix to a bug found in Apple's SSL certificate verification. He had some logging and noticed this extremely weird certificate get checked. https://github.com/jan0/isslfix https://github.com/jan0/isslfix The file was embedded in the binary as a base64-encoded PKCS12, but was encrypted with a password. They thought they were clever and used a format string to cobble together multiple parts that they then ran through a base64 decide to get the password. When jan0 told me about it, I spent a couple hours reversing the logic until I worked out the password... only for jan0 to tell me after that he had simply used one of my tools to hook the decryption itself and it only took him a few minutes ;P. (I scavenged my stuff and found a copy!) The password to this file--which is the one directly taken from the binary, and so this is the original password (!!)--is "AmsterdamIsC0ld". (I have given talks about "the fallacy of trying to secure content inside of a binary you give to your attacker", and this password with that 0 for the O always manages to get some laughs ;P.) http://test.saurik.com/hackernews/localhost.der http://test.saurik.com/hackernews/localhost.der As for why this absolutely should be frowned upon: this doesn't provide any actual security... if everyone has the private key then anyone on your computer can man in the middle attack this connection. This is no better than just using HTTP to connect to this local service: the only reason you are even using SSL here is to bypass a security check in the browser (that an SSL website can't access a non-SSL website). And if you want to argue "it is a local computer, why is a man in the middle attack relevant", you need only see the work people in jailbreak communities for random devices do to escalate privileges through various otherwise protected and sandboxed applications... made all the more obvious in your own description as it is the security of this website that is being undermined now (as maybe returning weird stuff from its API will mess with the user's site account or network settings or just break the website and give you arbitrary JavaScript execution). I mean, in this case, you can't even guarantee the connect is to localhost! You start by swapping out the DNS to redirect drmlocal.cisco.com to some other IP address, and now you can get that website running on one computer--which you might not even have physical access to!--to talk to your forged copy, and trick the user into interacting with it, possibly letting you steal authorization keys or doing any of the other aforementioned described "bad stuff". I will argue a local CA is absolutely "better", even if the optics are worse: you can generate the key for the CA, use that key to generate a key for just the one host, destroy the private key for the CA, and then install the public key. You now have a CA installed that can effectively only ever be used for the one host. Of course, that causes a problem that you are training users to install CAs. If you dislike that, you can either use a proprietary browser or lobby browsers and OS developers to provide support for installing a CA limited to a hostname pattern: the fact that these do not exist is the real problem here and is downright criminal, as we know people want to do stuff like this, and it isn't even a ludicrous concept.

by pilif 9y ago

Nullabillity 9y ago

This technique is already the equivalent of a proprietary browser plugin, except for that it's running completely outside of the browser sandbox. The proper fix here is to stop with the DRM bullshit and just use HTML5 <video> like everyone else.

notyourwork 9y ago
Can you elaborate on use html5 <video> like everyone else? I am not familiar with this technique.
pilif 9y ago
In my case I’m using this to allow people to read data from a locally connected (via USB) barcode scanner. Remind me again how <video> would be of help there?
- Nullabillity 9y ago
  If you already need a native driver then you might as well make the whole thing native.

euroclydon 9y ago

I actually need to do this. Is there a best practice for handling the certificate? It needs to be installed on the machine for the browser to trust it. All I can think of is to make a new certificate for every machine at install time and binding an obscure domain name to the loopback interface, so it would be highly unlikely to overlap with a real site.

ploxiln 9y ago
You can do what Cisco did with the domain name. Just don't create a CA-trusted cert for it. Instead, as you suppose, generate a unique cert on each machine and install it to the appropriate/needed trust stores on that machine.
justinclift 9y ago
The Plex approach, pointed out above by diafygi above might suit you. https://news.ycombinator.com/item?id=14595269 You need a wildcard cert (not hard), and a DNS resolver (daemon) to respond back with custom IP address. Sounds pretty simple in concept. :)
- pilif 9y ago
  A wildcard won’t help much. If you want to do this correctly, then each client needs to generate a unique certificate and private key. The name in the certificate, the custom resolver helps with, but now you’re stuck with that uniquely generated certificate which you now need signed by a CA. And this is the step that’s problematic: that host is not connectable from the outside, so there’s no way for, say, let’s encrypt to do http validation (even if their usage quota would allow to do this at scale, which it doesn’t), so you’d have to do domain validation which would work, but would require your clients to ship their private keys to the server which is a big nono again. You could also do some crazy polling approach in order to have your server relay between the DNS validation by let’s encrypt and your client (which, again, usually is behind a NAT and firewall, so it has to poll the server to have the possibility to send the response to the ACME challenge), but this is a huge amount of work, and, again, doesn’t work because of per-domain quotas. So now you’re stuck with a custom solution with a CA which involves you having a trusted signed CA certificate (good luck getting that one) and providing these clients with an API or having a CA providing a custom API for these clients to use. None of these things are widely available and as they are custom solutions, I’m sure CAs will require a lot of money for, provided they even talk to you at all if you are a small company.

asdfaoeu 9y ago

It looks like browsers will allow you to talk to localhost from a secure page without SSL https://bugzilla.mozilla.org/show_bug.cgi?id=903966 https://bugzilla.mozilla.org/show_bug.cgi?id=903966. The other way assuming you don't need to transfer much is you can reverse proxy it out to your own server and back to your application. (Where the SSL decoding is done by the remote server)

stereo 9y ago
Chrome doesn’t.
- asdfaoeu 9y ago
  https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://chromium.googlesource.com/chromium/src.git/+/130ee68... ? I just saw that from the first ticket but I guess it hasn't actually been merged there's a bug though. https://bugs.chromium.org/p/chromium/issues/detail?id=607878 https://bugs.chromium.org/p/chromium/issues/detail?id=607878

stereo 9y ago

JOSM, an editor for OpenStreetMap, installs its own certificate, which is limited to https://localhost:8112 https://localhost:8112. This seems pretty safe to me - if someone can MITM that, you already have bigger problems.

ryanlol 9y ago
Presumably that certificate isn't actually signed by any relevant CA, right? If so it seems rather irrelevant in the context.

Kenji 9y ago

If somebody MitMs your connection to 127.0.0.1, you're hopelessly lost anyway. I don't really see a reason to protect requests that do not leave your machine.

asdfaoeu 9y ago
The issue is remote sites that are using SSL and want to do an Ajax request to a local site.

ejcx 9y ago

If it is local and communication never leaves the machine, why use TLS? 1Password got heat for the opposite in the past (use of ws:// between the browser extension and the Mac Client). 1Password correctly pointed out that there isn't really a point to "secure communications" if the webserver and the web client are on the same machine. If you can't trust your own machine to intercept your connection then TLS is not going to save you. What I bet happened was some project manager said "There needs to be a green check" or some security person said "You NEED TLS" and nobody spoke up that it didn't make sense. edit: I'm not a deleter, but I misunderstood your post and I realized it right after I pressed enter. Did not realize you were talking about being on a remote webpage and being connected locally.

pilif 9y ago
Yeah. The webpage is remote and using ssl and now wants to talk to the locally installed app. I agree that SSL doesn’t make sense there and honestly, in my opinion it would make sense for browsers to treat localhost as a secure origin. But they don’t and so we’re back to square one which is that a secured origin can’t make requests to a non secured origin. Update: newer browsers do in-fact do this. It’s also part of the WHATWG spec: https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165 https://github.com/w3c/webappsec-mixed-content/commit/349501... Of course there’s still IE and Edge that are of different minds, but it’s nice to see movement
- derefr 9y ago
  Interesting; intuitively, I would say that this should be fine for mobile browsers, but desktop browsers shouldn't be doing this—PC operating systems are still built on a fundamentally "mutually-untrustworthy multitenant time-sharing system" paradigm. Any random port on localhost (or, indeed, on any other IP assigned to the loopback interface—that's 127/8 in IPv4, you know!) can be a socket opened by a process running on your PC that was started by someone who 1. has limited shell access to your machine, but 2. who isn't you. Privileging such ports would give such attackers an easy escalation path from this limited shell access to administrative access, assuming that you yourself are a [local or domain] administrator. Mobile devices can ignore this because they're (so far) inherently single-user devices. But anything allowing multiple parallel user sessions—even a Chromebook, or an iPad in Classroom mode—shouldn't make the assumption that local ports are safe. That's how a teacher gets their password phished by their students.

diafygi 9y ago

Plex does this by generating a private key at install then issuing a real ssl cert for it. That way the private key never is seen by Plex or anyone else. Really cool technique. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

pilif 9y ago
Yes. But it requires them to have a CA certificate which requires special contracts with a CA. Now, Cisco could certainly do that, but for smaller companies, that‘s probably not feasible
- koenrh 9y ago
  Not necessarily. Plex does not hold the private key for their intermediate certificate authority ('Plex Devices High Assurance CA2'). They use a DigiCert API to sign certificates under the 'plex.direct' domain.
  - pilif 9y ago
    Which means: special deal with digicert. Or can you link me to a product page where anybody can sign up?
    - Azeralthefallen 9y ago
      A company i used to work for tried to get something similar to what Digicert has with Plex, and the initial cost was very high.
    - hannob 9y ago
      Let's Encrypt. There's no reason not to use LE. You need to make sure that your device is accessible under the given subdomain for a certain period, and it may not always be trivial. But there are ways to do that.
      - 9y ago

ryanlol 9y ago

>So I guess we're back to proprietary browser extensions if this technique is frowned upon. It's not. You just need to not fuck it up. drmlocal.cisco.com isn't really an acceptable way of doing that because it's in the cisco.com scope, why not just have drmlocalcisco.com instead?

vbezhenar 9y ago
If private key is accessible to the wide public, it's considered compromised and CA must revoke the certificate. Domain doesn't matter.

0xfeba 9y ago

Microsoft was proposing to prohibit localhost connections in a new version of Edge. They, rightly, were shouted down from that position.

duskwuff 9y ago

Another option that comes to mind is a keyless SSL configuration, similar to what Cloudflare does: https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...

vardump 9y ago

> The domain in question (drmlocal.cisco.com) resolves to 127.0.0.1. So if someone just MITMs your clear text DNS to make drmlocal.cisco.com resolve to something else, they get your cisco.com cookies and plausible chance to impersonate Cisco? Think targeted attacks.

saurik 9y ago

Back in 2011, the HBO Go application on iOS contained a similar certificate for 127.0.0.1; I believe in that case a certificate for the bare IP address or just "localhost" that they got from Verisign. It was noticed by jan0 from the iOS jailbreak community, who had written isslfix, with the goal of hacking in a fix to a bug found in Apple's SSL certificate verification. He had some logging and noticed this extremely weird certificate get checked. https://github.com/jan0/isslfix https://github.com/jan0/isslfix The file was embedded in the binary as a base64-encoded PKCS12, but was encrypted with a password. They thought they were clever and used a format string to cobble together multiple parts that they then ran through a base64 decide to get the password. When jan0 told me about it, I spent a couple hours reversing the logic until I worked out the password... only for jan0 to tell me after that he had simply used one of my tools to hook the decryption itself and it only took him a few minutes ;P. (I scavenged my stuff and found a copy!) The password to this file--which is the one directly taken from the binary, and so this is the original password (!!)--is "AmsterdamIsC0ld". (I have given talks about "the fallacy of trying to secure content inside of a binary you give to your attacker", and this password with that 0 for the O always manages to get some laughs ;P.) http://test.saurik.com/hackernews/localhost.der http://test.saurik.com/hackernews/localhost.der As for why this absolutely should be frowned upon: this doesn't provide any actual security... if everyone has the private key then anyone on your computer can man in the middle attack this connection. This is no better than just using HTTP to connect to this local service: the only reason you are even using SSL here is to bypass a security check in the browser (that an SSL website can't access a non-SSL website). And if you want to argue "it is a local computer, why is a man in the middle attack relevant", you need only see the work people in jailbreak communities for random devices do to escalate privileges through various otherwise protected and sandboxed applications... made all the more obvious in your own description as it is the security of this website that is being undermined now (as maybe returning weird stuff from its API will mess with the user's site account or network settings or just break the website and give you arbitrary JavaScript execution). I mean, in this case, you can't even guarantee the connect is to localhost! You start by swapping out the DNS to redirect drmlocal.cisco.com to some other IP address, and now you can get that website running on one computer--which you might not even have physical access to!--to talk to your forged copy, and trick the user into interacting with it, possibly letting you steal authorization keys or doing any of the other aforementioned described "bad stuff". I will argue a local CA is absolutely "better", even if the optics are worse: you can generate the key for the CA, use that key to generate a key for just the one host, destroy the private key for the CA, and then install the public key. You now have a CA installed that can effectively only ever be used for the one host. Of course, that causes a problem that you are training users to install CAs. If you dislike that, you can either use a proprietary browser or lobby browsers and OS developers to provide support for installing a CA limited to a hostname pattern: the fact that these do not exist is the real problem here and is downright criminal, as we know people want to do stuff like this, and it isn't even a ludicrous concept.