4 ms·

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 inspec

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 7y ago
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.
- theamk 7y ago
  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.
xg15 7y ago
> 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 7y ago
  > 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 7y ago
    > 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.

xg15 7y ago

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.

theamk 7y ago
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.

xg15 7y ago

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