Live data from Hacker News

Spying on HTTPS

textslashplain.com

11–20 of 121 posts

Re: Spying on HTTPS

#11

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…

> AFAIK there is no general protocol insecurity with TLS

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.

Re: Spying on HTTPS

#12
post #8

Earlier quoted context omitted.

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.

Re: Spying on HTTPS

#13

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?

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.

Re: Spying on HTTPS

#14
post #5

Earlier quoted context omitted.

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.

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

Re: Spying on HTTPS

#15
> monster in the middle (MITM)

That’s not what it stands for. There’s nothing sexist about using an acronym the same way everyone else does.

Re: Spying on HTTPS

#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?

Re: Spying on HTTPS

#17
post #15

> monster in the middle (MITM) That’s not what it stands for. There’s nothing sexist about using an acronym the same way everyone else does.

Gender neutral and more accurate, it might not be how everyone else uses it but you got the meaning, no?

Re: Spying on HTTPS

#18

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.

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)?

Re: Spying on HTTPS

#19
post #9

Earlier quoted context omitted.

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

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

Re: Spying on HTTPS

#20
post #15

> monster in the middle (MITM) That’s not what it stands for. There’s nothing sexist about using an acronym the same way everyone else does.

Gender neutral and more accurate, it might not be how everyone else uses it but you got the meaning, no?

"Man in the middle" is not only an established concept it also is self-explanatory.

Furthermore calling intercepters "monsters" is also a highly insensitive thing to do, if we're going to play the virtue signaling card.

All this quixotism towards grammar and language is very stupid and pointless.

Post reply on HN