4 ms·
> You will still be able to measure how much data goes to and from particular IPs, since that can't be screened. "33.12% of traffic went to IPs associated with
by exikyut 8y ago
> You will still be able to measure how much data goes to and from particular IPs, since that can't be screened.
"33.12% of traffic went to IPs associated with Google. 26.3% of traffic went to IPs associated with CloudFlare. 25% of traffic went to Cloudfront. Here is the breakdown of the remaining 15.58%..."
<Insert cartoon fist punching noises here>
DO NOT WANT. Sorry for caps, it's a bit loud, but the above ^ is what I explicitly want to _avoid_. And with DoH (DNS-over-HTTPS) avoiding that will be even harder.
> You probably shouldn't attempt your idea of proxying everything.
Gestures at post and underlines angry and irritated parts (not angry at you of course, angry at TLS 1.3)
I don't _want_ to build a proxy. Well, I do; I'd love to make it a firewalling proxy that only lets HTTPS data signed by my cert through (and resigns everything so only my cert is ever used), so it DOES break everything using cert pinning, and I can sniff ALL the data generated by the programs I use (if people argue about hardware ownership, shouldn't they argue even more vehemently about their personal information?!).
But practically speaking, no, I don't want to build a proxy. I want to avoid needing to build a resilient LAN with multiple APs and subnets and firewalling and ugh. (Because I will of course need that to break HTTPS and then use my bank's website/apps without my heart fluttering - or even my Google login, for that matter...)
> Proxies are very fragile, and this will probably inadvertently worsen your security, while also introducing weird non-security misbehaviour that's hard to track down.
What do you mean?
> For example Firefox will go "Oh, a MITM proxy :(" and it will switch off all the safety measures built up over years for the public Internet because this isn't the public Internet.
Really?! Where can I learn more about this? :s
> In principle if your MITM proxy is enforcing the same or tougher rules, this wouldn't be worse, but let's face it, you're going to cobble together the minimum possible to make it work.
D:
In practice you're right. In my head I want to build the best+most secure system available, but if I'm pragmatic, the amount of support out there for doing this on a personal/temporary (aka non-dev/"break the system for a minute because it's being debugged"/SSLKEYLOGFILE) basis is about the same as for GPG-encrypted mail, so I know I'll wear down eventually, and make myself a giant sitting duck. :'(
> Every time somebody tries to get fancy and _think_ about the bits inside the packets their network is supposed to be moving they screw up. That's the most cynical reason why there's an impetus to encrypt everything. If the bits are all encrypted gibberish the temptation to meddle with them goes away.
Thanks for this. I never looked at it that way, but thinking about all the programs and apps using weird binary formats to scare people away... it makes perfect sense the Internet and HTTPS would work similarly. But I think that's a vulnerability in and of itself, in that it discourages general exploration and progressive investigative analysis by virtue of being so unbelievably multidimensional and hard. For example I look at https://sites.google.com/site/testsitehacking/-36k-google-app-engine-rce https://sites.google.com/site/testsitehacking/-36k-google-ap... and wonder.
- tialaramex 8y agoExamples of things we're sure are safe to insist on for certificates in the public Internet but we can't check in people's crappy corporate networks because the checks would just constantly fail and nobody cares to fix anything: * The FQDN (minus a trailing dot) of the site must appear either exactly as a SAN dnsName or, with its first label replaced by a single asterisk, as a "wildcard", in the certificate, otherwise the cert is worthless * The cert should have an Extended Key Usage. The EKU must contain at least 1.3.6.1.5.5.7.3.1 (meaning this key is to be used to identify a TLS server) * The certificate mustn't use SHA-1 (or MD5 for that matter) as part of a signature algorithm