Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spying on HTTPS

textslashplain.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: Spying on HTTPS

#101

Post by userbinator »

dspillett wrote: post #14
userbinator wrote: post #6

Earlier quoted context omitted.

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

> 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.

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".

Re: Spying on HTTPS

#102

Post by userbinator »

Ajedi32 wrote: post #27
userbinator wrote: post #4

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…

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. ;-)

Re: Spying on HTTPS

#103

Post by userbinator »

zzma wrote: post #71
userbinator wrote: post #4

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…

> 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.

Re: Spying on HTTPS

#104

Post by minitech »

xg15 wrote: post #96
minitech wrote: post #81

Earlier quoted context omitted.

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 para…

> 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.

Re: Spying on HTTPS

#105

Post by userbinator »

Andrex wrote: post #44
userbinator wrote: post #6

Earlier quoted context omitted.

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

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 a…

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.

Re: Spying on HTTPS

#106

Post by andrerm »

xg15 wrote: post #77

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?

> how are you actually supposed to inspect them if you have a legitimate reason?

How is this question any different from FBIs encryption backdoor?

I see everybody here defending this but I truly don't understand. How is different from encryption backdoor on the browser?

Re: Spying on HTTPS

#107

Post by xg15 »

minitech wrote: post #104
xg15 wrote: post #96

Earlier quoted context omitted.

> 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 para…

> 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…

> Of open-source software. The context was “security best practice”, so anything closed-source is a no-go.

Sorry to be blunt, but that is impossible to archieve in practice if you actually want to take parts in modern society.

Re: Spying on HTTPS

#108

Post by topranks »

Rudi9719 wrote: post #16

Honest question, is it possible to have chrome disable the functionality to export the SSL private key? IE on that notification is there a button to deny the stream?

It may be but these keys are ultimately in RAM.

If you are root on the local system (as all AV is,) then ultimately you can collect these keys, the only question is how much work you may have to do.

Re: Spying on HTTPS

#109

Post by mises »

jraph wrote: post #92
mises wrote: post #86

Earlier quoted context omitted.

> 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 a…

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 refe…

Plural they is pretty new in wide-spread usage?

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.

Re: Spying on HTTPS

#110

Post by mises »

jraph wrote: post #99
danShumway wrote: post #90

Earlier quoted context omitted.

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[…

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…

> 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.

Post reply on HN