Hacker News Reader

> FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?

Issue of scope. Chrome isn't selectively insecure.

>AFAIK there is no general protocol insecurity with TLS <= 1.2, unlike SSL3. There's also no reason for MITM proxies to not start using 1.3 too once it becomes more common, which I'm pretty sure will happen.

Browsers are very particular about how they communicate certificate validation failures. This is generally obscured by the MITM proxy, as is the certificate itself. Making MITM easy will inevitably lead to people running badly made proxies, especially if such a proxy is installed to the system as adware, the same reason both Chrome and Firefox wouldn't allow random unsigned extensions.

I'd honestly be surprised if any of them do HSTS properly.

>IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.

You can run dev builds - usually even the official ones - to turn most of those security features off. They're intended for your average non-power user.

>Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.

That's what you get for making an argument about browser vendors about Google and conflating it with Chrome issues in a different scope.

> I'd honestly be surprised if any of them do HSTS properly.

Maybe I'm missing something, but what would an MITM proxy have to do here as long as it passes the HSTS headers on to the browser?

As far as I understand, HSTS changes browser behavior in two places:

- A browser will always connect to a domain via HTTPS, even if the URL says HTTP. - TLS errors become unskippable.

Both behaviors are carried out by the browser and are not influenced by the specifics of the TLS connection itself (as long as a connection can be established).

> You can run dev builds - usually even the official ones - to turn most of those security features off. They're intended for your average non-power user.

But this is about average non-power users. Because the current trends force those users to place their complete trust in browser vendors or website operators, even if there were local administrators or third-party tools who could do a better job.

> FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?

To avoid introducing vulnerabilities, the way lots of antivirus MITMs do, for example. Like it says in the rest of your quote.

> Especially Google's, because that's one of the ways you can still block ads and modify pages to have them displayed as the user(-agent) wants, while it continues to slowly remove abilities from browser extensions.

Blocking ads by MITM? Yikes. Extensions are very much a better tool for that. The idea that browser vendors are going to slowly cripple them so that they’re no longer an effective blocking tool is… wrong. But anyone who was on Chrome can use Firefox anyway.

> IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.

FUD.

> Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.

Don’t.

Extensions are very much a better tool for that. The idea that browser vendors are going to slowly cripple them so that they’re no longer an effective blocking tool is… wrong

Did you not see this at all? https://news.ycombinator.com/item?id=20044430

Don’t.

You're certainly displaying your allegiance to Big G...

Now that's paranoid.

I assume you've never heard of ISPs or vendors that _inject_ ads and other shenanigans on non-https and decrypted https websites?

That's the ISP's problem. Mine doesn't do that. I trust it more than Google, at any rate.

Being able to choose your ISP is a luxury many people, especially in the US, do not have. Elsewhere there might be choice, but none are really trustworthy.

This is about disincentivising ISPs. If it's hard for them to pull off, they wouldn't do it and it would become something normal every ISP does.

> Being able to choose your ISP is a luxury many people, especially in the US, do not have. Elsewhere there might be choice, but none are really trustworthy.

If you don't trust your ISP you really should use a VPN. You still have to trust your ISP if you don't and nothing that megacorps do can help you there.

TLS mitigates 90% of the things a VPN promises to do for you rather well. But you can get that up to 95 running a local DNS resolver with tls upstream.

Isn't that one of the reasons for DNS over HTTPS, which is being rolled out now[1] in some browsers? You can keep your ISP from seeing/intercepting/replacing DNS requests.

1: https://support.mozilla.org/en-US/kb/firefox-dns-over-https

There is no 90% or 95% neither with TLS nor with DoH. There are still IP addresses, OS-specific data in IP packets, response sizes, traffic patterns, SNI, active probing data, etc. ISPs can get so much stuff on you, you really should use a VPN if you don't trust your ISP.

ISPs aren't the NSA, and the NSA has no issue watching your VPN egress.

SNI is probably the most critical here, and it is getting opportunistic encryption.

Threat modeling. Do it.

ISPs rely on DPI equipment vendors, which do all those things. And no, this is not an NSA level stuff, just your basic commercial traffic analyzing. And in fact, the most common spying ISPs do is not on DNS or HTTP, but just on IP sessions, i.e. netflow data, they record and store it for months or years. This is likely the first thing you need to protect yourself from.

DoH not just doesn't help privacy, it makes it worse for everyone by letting another party to get their DNS data and by centralizing requests on that party to actually help NSA and large scale commercial spying. ISPs are still going to get that data too though. And theoretical possibility of encrypted SNI is definitely not going to prevent that, it's probably not going to be a thing at all, just remember how quickly all the megacorps jumped in to close the equivalent domain fronting technique under a little bit of pressure from governments forcing megacorps to allow governments to identify traffic to censor something specific or get all their networks blacklisted on the IP level.

Megacorp proposed "security" and "privacy" solutions generally do not do anything good for end users at all only take away control from end users. These are the times we live in.

It's a thing.

https://www.cloudflare.com/ssl/encrypted-sni/

This is the thing US brought to itself. Liberal market with minimum regulations. If in my country ISP would touch the traffic, they would get prosecuted by the state. Selling browsing history? Under wiretapping act (you can imagine some jail time). And I can choose between 3 ISPs in country with 2 million people. And optics with at least 100/100 is normal in "larger" city (village in US terms :D) for $60 including iptv and equipment. LTE practically everywhere.

US people will need to start to complain a lot. You are beeing abused.

There are a lot of regulations concerning ISPs in the US, they are just all pro-monopoly regulations, not to enable competition.

In what country do you live?

> That's the ISP's problem.

No. It is the user's problem, created by the ISP.

> Mine doesn't do that.

Otherwise put: "It isn't a problem for me, so why is anyone working on the issue instead of something that I do care about"

> I trust it more than Google, at any rate.

Fair enough. Though for many, choosing not to use Google properties is a lot easier than choosing not to use an ISP that they don't entirely trust.

How do I choose not to use Google properties, including their ad services, analytics, captcha, maps, etc? Is there at least a comprehensive list of their domains, if I choose to block it all (despite that rendering half the web unusable)?

Host list that lists every one of their domains with ip 0.0.0.0

including every single 1e100 server domain? good luck

Not with a simple hosts file entry, but surely some DNS resolvers support wildcards in their configuration to make this easier?

> How do I choose not to use Google properties

Sorry, I wasn't specific enough. The poster I was replying to was commenting on their browser and I was expanding that to mean their browser and other applications.

Blocking all access to all Google services could be an uncompletable task, unless you start from blocking everything and using a white-list approach only which it unlikely to be practical (on top of creating the whitelist you'd have to monitor it and react when they or one of their related entities buy out or otherwise co-opt services you might have whitelisted in the past.

There are fairly comprehensive (though given the volunteer effort involved I'm sure they aren't 100%) lists available, but I don't know of one specific to Google so you would end up blocking other similar services unless you add your own filter to the filter list before using it.

> if I choose to block it all (despite that rendering half the web unusable)?

I doubt it would make nearly that much unusable. The only one of their services that blocking would stop you using other things is recapcha and I dare say anything "hidden" behind that is also available elsewhere. Blocking analytics isn't going to affect you as a user, maps blocks itself a lot ATM anyway ("this site is configured incorrectly" messages where a map should be because the rules for inlining maps have changed (or their enforcement has) and people haven't updated their pages to reflect the policy change at Google), etc.

Blocking third parties with a tool like uMatrix will get you some of the way. Then you can generally avoid their products and block them at the top level manually, although it might be hard to avoid visiting websites that use Google Cloud, e-mailing people that use Gmail, or using software maintained by Google.

Otherwise put: "It isn't a problem for me, so why is anyone working on the issue instead of something that I do care about"

No, I mean it's a technological workaround to what is ultimately a policy problem, and those never end well. It also happens to be a workaround that gives Google (and basically all the other anti-user corporatocracy) more power and ostensibly good PR in the form of "security".

You should absolutely not trust an ISP more than Google. Google monetizes your data themselves, while ISPs will pass it around to anyone with a couple bucks...

If data privacy is your goal, keeping both at arms length would be ideal... except most people can't choose how much data* ISPs scoop up, or even choose to switch to a competitor if they disagree with an ISP's policies.

*In contrast, you can control a decent amount of what Google collects on you.

Agree. But...

> Google monetizes your data themselves

That's what I thought abt Facebook and Twitter: It looks like they might ship anonymized (or not) data to third-parties when appropriate. Amazon, too, make a lot of data available to sellers on their platform.

Google could be doing that, too, in the guise of claiming to do something else. Or, it already is.

My goal isn't really "data privacy", but to oppose Google acting like it owns the Internet and doing whatever it wants to further its agenda.

Yes, "security" push from corporations has been a joke for years already. I guess they see that people buy it, push it even farther and lock down everything they can under that excuse.

But we can still survive it, Google is afraid of something and keeps a usable browser open source. And if things go south it won't be hard for a browser fork to implement a proper feature to allow interception of network requests before encryption and responses after decryption with another program, while disabling anti-features.

As long as there is still something where you can install that browser. Most interesting new hardware is itself increasingly locked down.

> FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?

It turns out that most of the MITM products have questionable / insecure TLS stacks [1] and can introduce insecurity to user web traffic.

[1] https://zanema.com/papers/ndss17_interception.pdf

The solution is to tell those products' authors to improve them, as the paper you linked even recommends, and not throw the baby out with the bathwater. Unfortunately, doing the latter is more in line with the intentions of companies who want to be able to shove their content down your throat unimpeded, which is why you see so much astroturfing around this issue.

What kind of browser are you using that doesn't support any remotely recent version of TLS? IE6? That sounds like a major security risk, even ignoring what versions of TLS it does or doesn't support.

A text-based one. ;-)

> FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?

https://bugzilla.mozilla.org/show_bug.cgi?id=1529830 That's why. When you developing HTTP/load balancers it's a good way to test browser in the same environment.

> AFAIK there is no general protocol insecurity with TLS <= 1.2, unlike SSL3

Yet. That we know of.

> yay, instant downvotes! I hope you enjoy being herded by Google

Yay! Complaining about downvotes! I hope you enjoy more downvotes.

There aren't _fatal and inherent_ flaws known in TLS 1.2. But there are flaws.

For example Padding Oracles are not an inherent flaw in TLS 1.2, the protocol itself doesn't oblige you to tell attackers "You guessed wrong" until they guess right. But it becomes your responsibility to not let them know, an apparently optimal TLS implementation functions as a timing Oracle for CBC mode and can be exploited. Making CBC implementations sufficiently opaque that an adversary can't tell if they guessed the padding bytes correctly is really hard, OpenSSL have failed twice so far already. In TLS 1.3 this isn't an issue, it only has AEAD primitives.

And lack of Forward Secrecy is a pretty serious problem for some applications. It's not fatal, but it's a problem. In TLS 1.3 you always get Forward Secrecy. In TLS 1.2 it was optional, so unless you're explicitly configuring the ciphersuites used there's no guarantee.