5 ms·
From an SSL/TLS perspective you could have an HTTPS proxy on your network proxying all your traffic and impersonating all websites, by using a certificate autho
by cube2222 5y ago
From an SSL/TLS perspective you could have an HTTPS proxy on your network proxying all your traffic and impersonating all websites, by using a certificate authority trusted by your devices.
You'd be the sole owner of that root cert / its private key, so you wouldn't have to worry about people in public networks mitm'ing you, but you'd mitm everything on your own network (that is, the traffic coming from devices where you trusted that custom CA).
Unless you want to do that with devices that don't explicitly trust your custom CA, but in that case, it's a feature that this isn't possible.
- candiddevmike 5y agoI know how to do it, you just can't do it unless you control the device. Which for the IoT devices I'm trying to "hack"/reverse engineer the API server like Nest, I cant change anything.
- tialaramex 5y agoBut this is a decision you in effect made, those devices needn't even use TLS, they could use Jim Bob's secret MITM-defeating crypto thing and you can't "hack" that either, you bought devices that are resistant to being reverse engineered. Governments could legislate of course, there could be a rule that means you can't sell Nest because it doesn't have some "hack" feature. After all the EU mandated people provide a sane charge port on phones and it more or less worked, even if you don't live in the EU your phone likely no longer has some arbitrary custom charge port on it, and you can buy replacement chargers or keep the one from a previous phone, reducing waste. You also could legislate from the far end, for public services, you could say if I own a device using my credentials to do stuff, I get to have the agreed key material so that I can decrypt messages after the fact. That's a huge pain to implement, most of the ways to do it make everybody's security a bit worse, but it isn't technically impossible. But technologically we can't change the mathematics of the encryption, Diffie-Hellman works, two parties can agree a secret (which in effect becomes a symmetric key) without either of them uttering the secret.
- frazbin 5y ago"decision you in effect made" == "you were basically coerced"
- Handytinge 5y agoWhat IoT devices have you been coerced into allowing onto your network?
- freedomben 5y agoExactly. Even Android now with Android 12 is difficult. I spent a bunch of time I didn't really have trying to get my Android to proxy through my Burp suite, which is something I used to be able to do easily. But now it's extremely difficult, and the use of HSTS makes it basically impossible for all big tech sites, especially Google owned, but even HN. All I want is to be able to see who my device is using my network to call, and what they're saying. It used to be that the tech was there to serve me, but now it seems the other way around.
- 1vuio0pswjnm7 5y ago"All I want is to be able to see who my device is using my network to call, and what they're saying." Instead of Burp, I use Haproxy running in Termux. I have not run into any problems with HSTS. The part about being able to see "what they're saying" is interesting. Assuming the people running "tech" companies wants users to trust them, the user's data/information being transferred to the "tech" company should be available to the user. After all, it is the user's network, it is the user's computer and it is the user's data/information, not the "tech" company's. It is also the the user's bandwidth. "Tech" companies do not pay the costs of transferring the data/information, users foot the bill. A cautious user could decide that if the "tech" company will not share with her the deatils of the user's data/information being sent to the mothership, then she will just block the requests. In that case, installing NetGuard available from F-Droid will allow the user to list and optionally block DNS/HTTP requests. It falls short of instecting the contents of the requests, but it does allow the user to export lists of all DNS/HTTP requests. It can also export a list of all domains that the user allows to be resolved. This is useful for determining what domains apps need to access and creating whitelists.
- d110af5ccf 5y agoThe simple(ish) solution is to install a firewall on your network and configure it to MITM all the HTTPS traffic and simply deny anything it can't MITM. I understand this to be standard practice in many corporate environments. The device/app/whatever either trusts your CA or the traffic gets blocked. I don't bother to do so myself but I think it's a good position to take. My network is mine.
- EvanAnderson 5y agoSysadmins, private network operators, and device owners are just a subset of malicious attackers and "evil" nation states. The average user doesn't know to care. They keep buying this garbage and, in turn, financing the lobby against consumer protection laws for embedded devices. It makes me want to give up on technology and go live in a shack in the woods.
- israrkhan 5y agoYou don't own the communication as a network operator, unless you can also prove that you have control over the device. IoT devices sometime rely on sending sensitive data to their backends. This data may include API keys, client authentication secrets and such. By having access to that communication, you may be able to spoof identity of the IoT device from a PC or a hacked-device. Not very desirable from IoT vendor point of view.
- inetknght 5y ago> You don't own the communication as a network operator, unless you can also prove that you have control over the device. Sure, but devices that you don't have control over shouldn't be permitted to communicate anywhere at all ever. > IoT devices sometime rely on sending sensitive data to their backends. Such as literally anything. > This data may include API keys, client authentication secrets and such. Yeah that sounds like sensitive data alright. It's all data that the owner of the device should have but often do not because of misplaced corporate greed. > By having access to that communication, you may be able to spoof identity of the IoT device from a PC or a hacked-device. So what? If I own the device and it's on my network then I have every right to everything on the device. > Not very desirable from IoT vendor point of view. And that right there is exactly the problem. IoT vendors don't want to really give up ownership of something they've sold.
- israrkhan 5y agoThere can be legitimate reasons for restricting access to IoT traffic, and data may not be user data at all. Imagine an IoT light bulb, that can be controlled via voice assistants and IoT vendor's mobile app. This bulb talks to some services. IoT vendor developed those services just for this product, If an adversary/hacker can see the communication protocol, and API keys, he can use same service to control, his own ESP32 project. He can even abuse the service in ways it was not originally intended. For example a competitor can ship counterfeit products, that work with your service.
- renw0rp 5y agoThis idea is used in some "corporate security" tools. For example companies which use ZScaler install zscaler certificates on employees machines and use ZScaler servers as MitM kind of proxy which allows them to scan all traffic, including SSL/TLS.
- userbinator 5y agoI've been running a MITM proxy for many years to do filtering (including adblocking). Fortunately I don't have any IoT to worry about.