5 ms·
Ok, so if your adversary is your employer or your school, you are presumably using a network not controlled by you, in which case your endpoint ought to already
by vox_mollis 10y ago
Ok, so if your adversary is your employer or your school, you are presumably using a network not controlled by you, in which case your endpoint ought to already be a VPN.
A good number of employer or school-provider devices will have their own certificates preinstalled anyway.
Nobody ever said privacy was convenient.
- bigiain 10y agoI'm good with my work or school owned/issued device trusting a root cert installed by that device's owner. I'm _not good with a school or employer's network being able to generate arbitrary certs for my email, bank, social networks, etc - WITHOUT ME KNOWING ABOUT IT ON MY PERSONAL DEVICES... Sure, MitM me if it's your network - but I 100% should be able to rely on my browser on my device reliably being able to tell me "You're attempting to visit https://mybank.com https://mybank.com, but the certificate identifies it as mybank.suspiciouscorp.net Continue anyway (not recommended): [OK] [Hell no!]"
- Spooky23 10y agoIf you have a problem with that, use your own network.
- TechnicalVault 10y agoWhat if the site they're connecting to has a problem with that? If I for example serve E-Healthcare records, and have an agreement that a given person that I have vetted has access to them, I might have a problem with your unvetted IT staff having access but how would I know?
- Spooky23 10y agoSounds like you have a contract problem with the vetted individual.
- Dylan16807 10y agoDo you see no value in SSL at all, then?
- Spooky23 10y agoAs a private network owner, I see risk in uncontrolled SSL. If you provide a publicly accessible "Guest" network isolated from my corporate or private resources, that I agree that it's unreasonable to intercept TLS sessions. If you are on my network, which exists to serve my constituents with a personal device, I have every right to or even have a duty to ensure that you aren't threatening the overall integrity of the private network. Whether that be exfiltrating data, bringing in malware, etc. In 2016, the answer to this issue is really simple -- bring your own cellular service.
- Dylan16807 10y agoThe objection is not to controlling TLS on a private network. The objection is to using a method that can silently intercept connections to devices you don't administrate. If someone doesn't want to install the root cert, then "use your own network" is a perfectly fine response. If someone is upset that the TLS security model is broken in half, then "use your own network" is not a valid response.
- bigiain 10y agoAnd what do I do when you get a job at my cellular provider, and decide that my internet banking or healthcare website connections might be me "exfiltrating data" and you choose to take it upon yourself to inspect the contents of those connections just in case I'm somehow "threatening the overall integrity of the cellular provider's network"?
- danielweber 10y agoI agree that people running the network have the right to run it as they want. But if an attack can work on you using my network, it is also an attack that works on me surreptitiously rerouting your traffic onto my network. Basically undoing HTTPS.
- Spooky23 10y agoThe scope is broader than an attack. Also, what I'm talking about (MITM proxy on a private network), it's not sneaky -- you will get unsigned cert warnings. If you are using an employers device, you won't see warnings, but can examine the SSL certificate. You should also assume that you are being monitored.
- bigiain 10y ago"you will get unsigned cert warnings" No you wont. Bluecoat now has a CA Cert root key signed by Symantec. If they issue a .google.com or .gmail.com ssl cert you will _not_ get an unsigned cert warning. And explain to me how to connect to, say, my internet banking without using "a private network"? Every single hop between my house(or my phone) and my bank is a piece of network owned by some company or other. "Use your own network" is meaningless in the context of connecting to any hardware you don't own yourself.