
Spying on HTTPS - rom1v
https://textslashplain.com/2019/08/11/spying-on-https/
======
2T1Qka0rEiPr
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.

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

~~~
2T1Qka0rEiPr
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.

~~~
Ajedi32
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?

~~~
2T1Qka0rEiPr
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.

~~~
Ajedi32
_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.

~~~
2T1Qka0rEiPr
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.)

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

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

~~~
xg15
> _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.

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

~~~
xg15
> _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.

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

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

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

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

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

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

~~~
exabrial
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!"

------
commandlinefan
Last I checked, Wireshark can't be configured to decrypt a TLS 1.3 session (at
least not yet).

~~~
tialaramex
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?

------
ignoramous
Is MITM, as described in this article, using sslkeylogfile possible on Chrome
for Android?

------
imvetri
Around two weeks back chrome hid its address bar.

Could it be a coincidence or both are related?

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

~~~
burkaman
I have seen it in at least one other project:
[https://blog.cloudflare.com/monsters-in-the-
middleboxes/](https://blog.cloudflare.com/monsters-in-the-middleboxes/),
[https://github.com/cloudflare/mitmengine](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?

~~~
aiCeivi9
Are we also going to change the middleman to middlemonster?

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

~~~
mises
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...](https://github.com/cloudflare/mitmengine/blob/master/processor.go)

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

------
sagebird
Listener in the middle is most accurate and Politically Correct.

~~~
Sephr
MitM can imply modification as well as eavesdropping. Meddler in the Middle
makes more sense.

~~~
dijit
Human in the middle?

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

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

~~~
xg15
> _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.

