Hacker News Reader

Comment by xg15 | Hacker News Reader

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?

View on HN

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

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

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

It's also formulated in a way that clearly implicates "this is bad, don't do that!".

The warning makes sense if shown as part of a shortlived debug session to a developer. However, this is caused by a program that a non-technical user has installed permanently on the device.

So I'm confused how legitimate TLS inspection is supposed to work for this user group.

I think the Google's answer is, "it isn't supposed to work"

They pretty clearly believe that they should be the only ones controlling the web experience.

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

By shoving your middlebox somewhere anatomically improbable.

> monitoring unusual behavior of your own system

Anything that tries to connect to the internet for a reason that you didn't both understand and ask for in advance is malware.

> Or is the security best-practice to just trust any app not to upload my contact list?

Yes. That is it exactly.

> Anything that tries to connect to the internet for a reason that you didn't both understand and ask for in advance is malware.

So, everything?

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

All sorts of places intercept HTTPS if they deem it reasonable. There are a wide variety of security products out there for such things.

Reply on news.ycombinator.com