Very interesting article, although if the message displayed to the end-user really was left at "You are using an unsupported environment variable: SSLKEYLOGFILE..." that would be truly awful UX with some potentially disastrous consequences.
Why? What "disastrous" consequences are you envisioning from a message like that? Note that the rest of the message (the part you omitted) explains in plain English what the part you quoted means to the average user.
Someone gets nefariously MITM'd and instead of giving the user an informative message, they're presented with something which means nothing to the lay-person.
You mean "stability and security will suffer"? Sorry I didn't exclude it to try to make my point more convincingly, I just missed it altogether.
Assuming that's the part you meant, do you really think that is sufficient in explaining the situation to the user. I'm very unconvinced, my parents would have no idea what that means and just close the warning.
Can the warning be closed? My assumption was that it's persistent.
I agree the warning isn't as specific or actionable as perhaps it would be ideally, but seeing as the browser has no idea why the SSL keys are being logged (it could just be for debugging purposes) or how to fix it without breaking things further, I'm not sure what more it could say.
Yeh, I acknowledge it's a difficult problem to solve, but I think if you have messaging at all, it should probably be a lot clearer, and link to some kind of article explaining the situation (which could cover the legitimate use cases such as anti-virus usage etc.)
Well, your(and my) parents would download an .exe file to play Farmville and run it with admin privileges by clicking yes on the user account control popup. So, maybe a web browser is not the safest place for parents...
Ok, dumb question. If apparently any kind of technique to intercept an HTTPS stream makes security experts frown, how are you actually supposed to inspect them if you have a legitimate reason? (e.g. monitoring unusual behavior of your own system)
Or is the security best-practice to just trust any app not to upload my contact list?
The SSLKEYLOGFILE approach is a good one; the warning being considered for Chrome just makes it clear when it’s in use.
(Not that you could detect it by inspecting decrypted HTTPS if a closed-source app really wanted to secretly upload your contact list. In that sense, security best practice is minimal app permissions and reproducible builds.)
> Not that you could detect it by inspecting decrypted HTTPS if a closed-source app really wanted to secretly upload your contact list.
In theory yes. If every app had their own hand-crafted binary format, scanners would be out of luck. However, in practice, developers value existing tooling and most of the actual data on the wire seems to be formatted in a manageable number of well-known formats (JSON, XML, url params, protocol buffers, etc). If nothing else, a scanner could at least find out with some reasonable certainty that an app is trying to obfuscate something.
I think the amount of detection and analysis tools that exist give some hinds that even if you cannot analyze everything, there is a lot of things you can find out.
> In that sense, security best practice is minimal app permissions and reproducible builds.
Reproducible builds of what? We haven't even got this to work for most open-source software and with closed-source software, you per defintion doesn't even have anything to build in the first place.
> If nothing else, a scanner could at least find out with some reasonable certainty that an app is trying to obfuscate something.
Only if the developers did a bad job of hiding it. You can tell a positive from decrypted traffic, but not a negative. It’s a useful first step before putting more effort into reverse engineering, sure.
> Reproducible builds of what?
Of open-source software. The context was “security best practice”, so anything closed-source is a no-go.
It's also formulated in a way that clearly implicates "this is bad, don't do that!".
The warning makes sense if shown as part of a shortlived debug session to a developer. However, this is caused by a program that a non-technical user has installed permanently on the device.
So I'm confused how legitimate TLS inspection is supposed to work for this user group.
To my understanding, this exports the session keys of an active TLC connection. Those are temporary keys that were created during the handshake of a particular TLS connection and are only valid for this particular connection.
So, if this data is picked up immediately by a network sniffer, it can decrypt the currently active TLS connection. However, the keys will not allow anyone to decrypt any past or future connections.
This should be correct. This is super useful for developers and operations people to debug traffic ... Or for security/monitoring software (e.g. company or parents monitoring people). But limited use otherwise. Considering the hoops you go through to turn this in, this is usually okay, but it is not necessarily apparent to end users when it is on.
Again, these are _secret_ keys. That's why the word SECRET n capital letters appears in that output at the end. Symmetric cryptography is used to actually transport data, and so it uses secret keys. These are agreed between client and server for each session and by getting a copy of them you can read (and in principle modify) the data as it passes between them. A private key would be a key that only one party knows.
The notification is a reminder that this is an unsupported configuration of the browser software, useful for developers but not really intended for your garbage "Anti-virus" software to try to hook into. Just remove/ disable the AV?
> Chrome isn't exporting the private key. It's importing the key you give it.
No. It is _exporting_ the _secret_ key.
It can't import the key, in many modern key agreement schemes neither client nor server gets to dictate the keys used, if you used a fixed or predictable value instead of a random one you just give up your security, you gain nothing. So the keys are (and should be) random for each session.
I just want to state that some kind of clear-text inspection of content is and should be absolutely expected for security and DLP purposes in an enterprise environment. If TLS is going to become un-MITM-able, then we need to do it on the host.
Which is the desired result, right? Key escrow forces you to be explicit about who you're allowing to decrypt your traffic rather than letting it be everyone by default.
The average user doesn't think like that. They see, "oh in order to get to the next level of farmville I just have to modify this really easy shortcut!"
Time to check again, Wireshark can consume TLS 1.3 keys from a client or server to decrypt the session using the environment variable described here. I'm not actually sure which version you need, maybe 2.6 or later?
No, that would usually be intermediary. If you want to be more specific you can say reseller or broker.
Monster in the middle is at least cute and conveys the authors intent that this agent is untrusted and assumed malicious.
People in this thread clearly don't like being called a monster which I think demonstrates exactly that words matter and these ones are doing their job.
No one here is objecting to it as a standalone phrase, but as a replacement for a perfectly good phrase that existed all ready. There is no reason to change existing terminology and cause confusion; who decided this was a problem, any way? It reminds me of Bro being renamed to "zeek" because of the whole "brogrammer" thing, even though it was named before any one ever started complaining about that after Big Brother. It's not a real issue. I wouldn't have a serious problem with it, except that some one who wants to learn more is now stuck searching for one of the three other people who decided this was an actual issue and used it instead of MITM. Again, same as with Bro: now you have to search for two terms, even if you're familiar with the distinction. I can find posts going back to the 90s on Bro; "zeek" has very little in comparison.
Monster has negative connotations. The word he should have used, if an alternative to "Man" is needed, is "Marklar". No negative connotations, and is objectively even more fun than "Monster".
> Some have protested that "monster" has negative connotations, but anyone who grew up with Sesame Street or modern Disney movies knows that’s an unfair stereotype. And Monster is more fun. You like fun, don't you? Don't you?!?
It shifts the narrative to demonize MITM. Ironic seeing a Cloudflare link, given that they are MITMing all traffic.
You are not a monster if you are doing it, it's corporations who are monsters if they try to prevent you from doing it and you are fighting for freedom from them. So it's freedom-in-the-middle.
It depends on the point of view and the situation.
If you are a free software developer reverse-engineering a graphics driver, you sure want to be able to intercept the traffic between the graphics card and the CPU (I don't do driver development so I might be completely off, but I hope you get the point anyway).
However, if you are having a conversation with a secret source, you want this freedom to not be intercepted.
Yes, those are the extremes. But the more common case seems to me that you are an app developer selling user data.
In this scenario, the app developer certainly has an interest not to be intercepted, however the user and actual owner of the device likely would benefit from interception.
I thought it was funny. I didn't see it as trying to remove gender as much as talk about how rubbish the practice is (antivirus programs are huge attack vectors, and I assumed the author was calling the anti-virus a Monster).
Chill out. If you start to find offense in everything. you're not going to have a happy life.
> "Man in the middle" is not only an established concept it also is self-explanatory.
Being comprehensible and established does not make it "good" (sure, this is a relative notion).
I get your point of view about calling the interceptors "monster", but we are calling the whole process an "attack", this could already be considered a judgment call with this reasoning.
Monster are not necessarily evil though. A myth that Monsters, Inc is actively trying to debunk :-)
> All this quixotism towards grammar and language is very stupid and pointless.
Many non-ignorant people think differently, so you need to argue here. Saying they are doing a stupid and pointless thing will not convince them.
Discussions should get more civil over time, not less.
GP never mentions gender in their post, but in terms of politics, it seems to me that this entire thread is a political conversation. It's certainly not technical -- a technical person would not care about whether someone used the term "monster" or "man", since:
a) it changes literally nothing about the technical details of the attack.
b) everyone understands what both terms are referring to.
The only reason why it makes sense for anybody at all to advocate for switching to "monster" or to advocate against switching to "monster" is because they're interested in the politics behind that switch.
From a technical point of view, if using the word "monster" makes some people happy, then why is it a problem for them to do so? My computer isn't going to stop working because of it ;)
If it makes someone feel more accepted, and it isn't causing any confusion, then I'm all for it.
There is a technical reason. I may know, but Google does not. I look up "Man in the Middle" and get many years worth of useful info. I look up "Monster in the Middle", and here's what I get: one result about a cloudflare project, one bodybuilding.com post, one disney wiki post, and several you tube videos about "HuggleMonsters". After those is this discussion. Does that sound like a really good term to use? This looks like some one at cloud flare got pc and used the term, then this guy got in on it. I see no reason to let some company decide what's proper; I'd rather go for decades of security and development expertise.
To add to this, search engines already need to correlate "MITM" and "Man in the Middle". But we don't see anyone here arguing that the expanded form should be preferred to make searching between those two forms easier.
Correlating terms turns out to be a pretty easy problem. It's overlapping terms like "Mongoose (Animal)" and "Mongoose (Database)" that are hard.
I would like person-in-the-middle attack, but unfortunately PITM would not be recognized as well as MITM. And in fact, it seems that we shouldn't really care so much that a person is in the middle, so we might be better off saying "in-the-middle attack" (ITM) anyway.
Today, "man-in-the-middle" sounds familiar but I wonder if in a few decades, saying "man" instead of "person" or "human" will bear more meaning than today, and if expressions like this will sound needlessly confusing and off-topic, like, "How being a man specifically is any relevant? Is there something special to men, relevant to the attack? Why should we care?" (though people would probably understand the history aspect of it; this would still require extra effort).
Languages has been evolving and there is nothing special about MITM that would make this particular expression immutable. We already got gender neutral pronouns in English, for which we are seeing a wide adoption now, and new pronouns feel like a pretty big change, much bigger than an evolution of the MITM expression.
> We already got gender neutral pronouns in English, for which we are seeing a wide adoption now, and new pronouns feel like a pretty big change, much bigger than an evolution of the MITM expression.
Huh? We don't have such pronouns in English. The closest is perhaps the plural "they". I've heard some mutterings about weird, made-up ones, but they seem very fringe and pushed solely for political reasons rather than as a natural evolution of language.
More importantly, what purpose would a "gender-neutral" pronoun serve?
Singular "they" has been used for hundreds of years dating back to the 14th century -- comparatively, it's a very modern trend for people to say that it should only be used in the plural. Even forms like "themself" have a pretty long historical precedent.
> what purpose would a "gender-neutral" pronoun serve?
From a technical perspective, these pronouns allow you to refer to a single person without prescribing their[0] gender. This may have the effect of making some technical writing more accessible.
From a narrative perspective, these pronouns allow you to write about a character who's gender you might not want to reveal yet[1].
And from a political perspective, these pronouns allow individual to assert that they are nonbinary. The political perspective is what gets people annoyed, but it's worth noting that both language and politics are a reflection of society. It's normal for one to influence the other. It's because of this that we consider language and grammar rules to be descriptive, not prescriptive -- they simply describe the words that people use, even if those words are being used for a political purpose.
Ignoring politics, why not use "he" as the gender neutral form and get rid of "they"? For the same reason why it can occasionally be annoying for `0` to be automatically cast to the boolean false in languages like Javascript. If I use the word "he", I don't want someone to have guess whether I'm using it in the gender neutral form or if I'm literally describing the person's gender. Singular "they" serves as a strict typecheck -- it makes "he" into a more useful word because you can use it exclusively to refer to male subjects.
[0]: Also note the usage of singular "their" here, which is almost universally accepted. I've never heard someone argue that we should get rid of singular "their" just because we already have "his" and "her".
[1]: "The cloaked thief stepped into the house. Their eyes scanned left and right, as if they couldn't decide what they wanted to take first." Is the thief a man or a woman? Only the detective will know!
I was also going to speak about the descriptive and prescriptive approaches to languages, and then dropped my paragraphs because it was not clear to me whether OP acknowledged that singular they was a thing in English. I decided to consider that they effectively acknowledged singular they.
By taking a prescriptive approach (telling how people should speak English), maybe singular they can be deemed invalid in English… depending on who is prescribing the usage. But people taking a prescriptive approach do not agree between each others, and even if they did, they would never represent the wide, heterogeneous set of English-speaking people.
Case in point: they do not agree here, but the usage of singular they seems to be more and more recognized / recommended [1]. A descriptive approach will acknowledge a widespread use of anything, regardless of the reasons why things are used.
About politics and languages. Politics are constantly shaping the language. This is not new. It's part of the natural evolution of languages. Politics are not inherently bad neither. We don't have slaves anymore in most countries, thanks to "politics".
Actually, I find politics is actually too vague a word, and some people seem to invoke it as a bad thing, saying that we should focus on technical matters when their view opposes the view of people seeing something belonging to the status quo as an issue (which is a political stance in itself… and considering that technical matters and politics are opposed too, ironically).
You can't really reject an idea "because politics". You may either argue, or disagree respectfully, but there is no such thing as avoiding politics and remaining technical.
> About politics and languages. Politics are constantly shaping the language. This is not new. It's part of the natural evolution of languages. Politics are not inherently bad neither. We don't have slaves anymore in most countries, thanks to "politics".
> Actually, I find politics is actually too vague a word, and some people seem to invoke it as a bad thing, saying that we should focus on technical matters when their view opposes the view of people seeing something belonging to the status quo as an issue (which is a political stance in itself… and considering that technical matters and politics are opposed too, ironically).
> You can't really reject an idea "because politics". You may either argue, or disagree respectfully, but there is no such thing as avoiding politics and remaining technical.
All of these are very valid points; I do have a political issue with it as much as anything else. I don't believe it is incumbent upon me to alter the manner in which I speak and write for the convenience of another. There are also, of course, the issues of grammatical horror and the fact that "they" as a singular simply feels clumsy and unnatural when spoken.
> I don't believe it is incumbent upon me to alter the manner in which I speak and write for the convenience of another.
It absolutely is incumbent upon you to show people respect in a workplace or school setting. That means not calling Black people the N-word, or mocking Asian accents, or deliberately using the wrong pronouns for trans people.
> grammatical horror
English is already full of them, one more won't do any harm.
> that "they" as a singular simply feels clumsy and unnatural when spoken.
I've grown accustomed to singular they, and I've actually joined a group of people for a week and using singular they was pretty common, and felt way more natural than what I expected. I guess this is a question of habit. Grammar is fine, and singular they would not be the only singular pronoun using the forms "are" and "were" for verb "to be": "you" also does.
tl;dr: he argues that singular they feels wrong to him, and argues in favor of a gender neutral pronoun "pers", derived from "person". I like the idea, though I haven't seen it used anywhere and would not easily use it.
I was thinking about singular they and its derivatives: their, theirs, them. Plural they is also gender-neutral, but its usage is not new nor controversial.
Defending the use of gender-neutral pronouns was not my point, but since you ask what purpose they would serve, here are some reasons I can think of (and this answer is not limited to English):
- to avoid having to specify or think about the gender(s) of the referred person(s), which may be unknown or irrelevant to the subject (to illustrate what I am saying: for instance, if a scientist found something, I don't really care whether they have blue eyes, or breasts, or testicles, or red hair, right, and if I cared, it would still be irrelevant to the discovery in most cases - not always, though: https://www.nature.com/news/male-researchers-stress-out-rode...).
- some people who prefer to be referred to using they (I know some personally, and there was a submission on HN whose author wants that we use they to refer to… them). We therefore should use "they" for them.
- some people do not see themselves as neither male nor female, so a gender-neutral pronoun is convenient for them, and for other people to speak about them.
I usually just stick with generic "he" until I know otherwise; i.e. if a scientist found something, I don't really care whether he has...
I'm not sure I get the idea of referring to a known person as "they", and this is at best a controversial issue bound very tightly to one side of the political aisle. A side with which I do not align. I guess I probably wouldn't ever do this, but I can at least see a possible use. Information appreciated.
Quick follow-up: I saw your reply to another comment; I do not really acknowledge that it is a "thing" with respect to grammatical validity.
I'm not in an English-speaking place, so I can't say how often it is spoken and for how long it has been, but I see it everywhere on HN and in other parts of the web.
It seems that it is more accepted in GB than in the US [1] : “Garner's Modern American Usage (2nd ed., 2003) recommends cautious use of singular they, and avoidance where possible because its use is stigmatized. [...] Garner suggests that use of singular they is more acceptable in British English [...] and apparently regrets the resistance by the American language community: "That it sets many literate Americans' teeth on edge is an unfortunate obstacle to what promises to be the ultimate solution to the problem.”
Singular they seems prescribed in the US too, by The Chicago Manual of Style at least since 1993 for instance [1], and proscribed by others.
There are many possible reasons people would use singular they, I'm not sure we can put them in an homogeneous political group.
It seems generic he is losing acceptance, to the point I wouldn't comfortably use it [2]. It probably depends on the place though.
I would kindly invite you to reconsider using singular they instead of generic he, but this sure is controversial and I'm no one to tell anybody how to speak, and I would not want to neither. And when something about the language feels weird… well, it just feels weird. Languages are very personal and intimate.
I personally tend to rephrase sentences to avoid they, but use it when doing so is too inconvenient.
If there were “woman in the middle” attacks, and people gender-neutralfied it to “witch in the middle”, there would be an uproar.
Yes, male witches are a thing, though it is a rare usage of the term (vs warlock), just like monsters are usually portrayed as male. Also, some women self-identify as witches for religious reasons. I still suspect there would be an uproar.
There are many problems with using a MITM proxy, however. The primary problem is that it’s very very hard to ensure that it behaves exactly as the browser does and that it does not introduce security vulnerabilities.
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?
While browser vendors are wary of any sort of interception of HTTPS traffic
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.
Similarly, the MITM might not support the most secure versions of protocols supported by the browser and the server (e.g. TLS/1.3)
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.
this approach is generally preferable to MITM proxies.
...because it provides no way to modify the content, i.e. being able to do things like block ads, inject stylesheets, and generally behave as the user wants.
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.
(This comment was posted from a browser that does not support even SSL 2.0, but is using TLS 1.2 via a proxy... and I know that 1.3 will be coming sometime in the future. When that happens, everything that goes through it can also start using 1.3.)
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.
> 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.
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
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)?
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.
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.
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.
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.
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.
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.
> 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.
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 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.
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.
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.
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.
