21–30 of 121 posts
> 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?
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?
I don't think normal software should need to take account of every way anti-viruses might abuse features.
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…
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.
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?
Idk for what that is useful besides Virus Scanners, but personally I would like my browser to make its own key and never leak it or accept new ones.
> 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 think it's equally understandable, and monster is objectively a more fun word. Seems like not a big deal?
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.
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…
> 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?
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.
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.
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.