Cisco subdomain private key found in embedded executable
groups.google.com
groups.google.com
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.
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
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.
I was under the impression that some of the newer APIs only work under SSL (e.g. geolocation, https://developers.google.com/web/updates/2016/04/geolocatio... ). This would mean they'd need this even if they were not requiring security. The specific instance is probably to tick a checklist for the content provider though.
subject=/C=US/ST=Florida/L=Melbourne/O=AuthenTec/OU=Terms of use at www.verisign.com/rpa (c)05/CN=localhost
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
The other solutions proposed like abusing Lets Encrypt, etc never really seemed right. I am still not sure really what the best solution is for IoT devices that doesn't have an astronomical cost.
1. Use HTTP. It's not forbidden yet. I think it's the most compatible solution.
2. Use http://127.0.0.1. It seems that this is standards-compatible solution, but browser support is not good enough, so if you can dictate browser choice for your user, it's the best future-proof solution.
3. Use your server as a proxy. When your localhost application wants to talk to your site, it talks to server and server retransmits this data to the browser. Quite cumbersome solution IMO, but should work, unless you must be able to work offline.
Now, Cisco could certainly do that, but for smaller companies, that‘s probably not feasible
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.
I tried to set up Let's Encrypt for this purpose for a personal project (to be given away as a gift), and concluded it was basically impossible as things are.
You don't want your users to have to figure out how to open their firewall enough for an http server to be publicly reachable just to use your device, especially when it has no other need for it. It would need to be reachable every 60-90 days to renew the certificates, which is frequently enough to mean "always".
The ACME protocol does have a DNS-based challenge mechanism, but it requires putting a token in a TXT record at an administrative sub-domain of your actual domain (e.g., _acme_challenge.example.com). As far as I can tell, none of the free DNS providers support or enable this (nor does certbot, without writing your own hooks). I don't want to eat a domain registration fee in perpetuity for a gift.
Sadly, there's no ACME challenge that can be satisfied solely by the actual thing you're trying to assert, which is that you control which IP address a given domain name points to.
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.
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/349501...
Of course there’s still IE and Edge that are of different minds, but it’s nice to see movement
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.
The proper fix here is to stop with the DRM bullshit and just use HTML5 <video> like everyone else.
Remind me again how <video> would be of help there?
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
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.
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?
https://news.ycombinator.com/item?id=14595269
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.
It also won’t work if the user is using Firefox or any other solution that works outside of the OS certificate store. Messing with a Firefox profile is frowned upon by Mozilla and even if you did that, it still doesn’t solve the problem for other things that bypass the OS certificate store.
https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
Throwaway account for obvious reasons.
This is the Sky UK middleware project isn't it? I know a couple of people who work there who said it's a bit of a clusterfuck. There were some good things at CSCO when I was there, but loads of WTF moments.
I'd imagine that could allow an adversary to compromise DRM for the SKY perhaps? (Based on the domain name.) But there seemed to also be concern that improperly set up cookies for other cisco.com domains may allow this to compromise them; do Cisco devices put sensitive things in cookies where that could happen?
EDIT: I am not in any way, shape, or form a network or security 'guy'. I just read the thread and wasn't horribly alarmed by the discussion; seems like a reasonable but bad exposure on the device.
Some may not even have a local DNS name but only use an RFC 1918 ip address. I don't think the current CA system can accomodate that? Obviously you don't want to hand anyone who asks for it a cert and a private key for "10.0.0.1".
In terms of who was _supposed_ to approve the decision, there is a policy in place for that. Did they get that approval? Who knows, but I think in theory there isn't a mechanism to enforce it once you control the subdomain.
Never underestimate the potential to make security mistakes.
I wonder what they're actually using it for...