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

71–80 of 121 posts

Re: Spying on HTTPS

#71

Post by zzma »

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

Re: Spying on HTTPS

#72

Post by strictfp »

Spivak wrote: post #42
exabrial wrote: post #3

I said awhile back that QUIC leaving out having a "non-s" mode was going to mean people would just leave keys dumping on :(

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.

They could have just added it as a flag to plugins, showing a clear security warning, potentially requiring a review.

Re: Spying on HTTPS

#73

Post by unethical_ban »

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.

Re: Spying on HTTPS

#74

Post by tzs »

burkaman wrote: post #25
egdod wrote: 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.

I have seen it in at least one other project: https://blog.cloudflare.com/monsters-in-the-middleboxes/ , https://github.com/cloudflare/mitmengine I think it's equally understandable, and monster is objectively a more fun word. Seems like not a big deal?

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

Re: Spying on HTTPS

#75

Post by Ajedi32 »

2T1Qka0rEiPr wrote: post #64
Ajedi32 wrote: post #56

Earlier quoted context omitted.

But as I said, the rest of the text on that bar clearly explains what the message means, in terms a layman can easily understand. Is there anything lost by _also_ including the technical information necessary to diagnose the problem?

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.

Re: Spying on HTTPS

#76

Post by 2T1Qka0rEiPr »

Ajedi32 wrote: post #75
2T1Qka0rEiPr wrote: post #64

Earlier quoted context omitted.

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

Re: Spying on HTTPS

#77

Post by xg15 »

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?

Re: Spying on HTTPS

#78

Post by xg15 »

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?

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.

Re: Spying on HTTPS

#79

Post by [deleted] »

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?

[deleted]

Re: Spying on HTTPS

#80

Post by mises »

Spivak wrote: post #45
aiCeivi9 wrote: post #41

Earlier quoted context omitted.

Are we also going to change the middleman to middlemonster?

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.

It turns out even cloud flare used man-in-the-middle in the project, because it was in some other code, I guess: https://github.com/cloudflare/mitmengine/blob/master/process...

(line 24; now wait for some one to realize his "error" and change it.)

Post reply on HN