Hacker News Reader

Comment by hansvm | Hacker News Reader

A ton of ISPs use deep packet inspection for various kinds of filtering (and other shenanigans). When they get it wrong it manifests to the user as certain websites or access patterns being inaccessible and the ISPs customer support agreeing that you should have access and being able to do fuck all to fix it. A VPN in the middle usually solves the issue.

View on HN

Wait, I think an ISP cannot inspect the content of packets that are encrypted, say, with HTTPs. In order to inspect TLS encrypted packets you need access to the end-device, controlling the end-router is not sufficient since you would not have access to the device certificates.

If you can prove that an ISP can inspect packets, it would be major news.

They may not need the contents, seeing you're connecting to a netflix IP and having a lot of data transfer may be a good reason to throttle, for example.

* Russia

* Kazakhstan

* China

* Belarus

* Iran

* Mayanmar

- list of countries that are known or suspected to MITM traffic, including SSL

how so they supposedly do it?

SSL certificates have a centralized hierarchy. Many browsers trust a long list of root certificate authorities from multiple countries.

https://cyberscoop.com/russia-tls-security-certificate-autho...

https://jpgamboa.com/china-ssl-authority-revoked-by-browsers...

Do some countries force the browser companies to add their root cert, despite abuse?

I imagine so. I understand that Opera GX, for example, provides a specialized version to Russian IPs that locks down the search engines that can be used.

There are always rumours. And some countries simply openly require computers sold in their country to have their root cert.

Including the US right? And I don't mean in a conspiratorial sense. Just in the sense that they wouldn't deny it because it's their home country (Say Windows certs or Google certs), and at the very least they can issue warrants, gag orders, or triple letter agency bypasses.

Now it only sounds weird when a country exherts their national sovereignity because the US doesn't need to perform any additional steps to install any of their Certs, they have hundreds of them by design.

> Including the US right? And I don't mean in a conspiratorial sense. Just in the sense that they wouldn't deny it because it's their home country (Say Windows certs or Google certs), and at the very least they can issue warrants, gag orders, or triple letter agency bypasses.

Yeah. I don't think the US explicitly requires it but they don't have to, there are more than enough US-based entities with root certificates who they could send a National Security Letter to if they ever wanted one. (Also the US FKPI root certificate is at least shipped by some vendors, although it seems to be disabled by default)

is there oss that will scour and identify iffy certs on a box?

One attempt I know of: https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a... There might be others.

You don't need fully broken encryption to gain useful information. Knowing how much data is transferred, to which servers, and when (especially with details like how various endpoints will inadvertently chunk up HTTPS requests based on the details about the content or how interactive sessions will have certain back-and-forth transmit patterns) is sufficent to generate a traffic "fingerprint" which you can correlate to other users, to automated traces crawling those same servers, and otherwise get a very good sense of what a user is up to online even above and beyond just knowing which IP is being queried.

Toss that into any sort of "anomaly detection" or other such nonsense, and it's easy to create rare edge cases at an ISP level.

It's somewhat analogous to how you can sometimes "reverse" hashes like SHA256. E.g., suppose the thing you're hashing is an IPV4 address. There are only 4 billion of those, so a pre-image attack just iterating through all of them and checking the forward direction of the hash is extremely effective. TLS makes that a little more complicated since the content itself is actually hidden, but time and space side-channels give you a lot of stochastic information. You might not be able to deduce somebody's bank password, but you can probably figure out where in the bank's login flow they are and approximately what they did once they logged in.

It may have been fixed since, but I saw a decent talk about this (defcon, IIRC) using Tinder as an example.

Using timing, amounts of data, and what was being connected to, you could recreate what someone was looking at and swiping direction. (left/right sent different amounts of data)

ip addresses are not encrypted, they are part of the header, not the body. The mailman needs to know the address.

Yes. What I'm saying is that the pattern of data entering the mailbox lets you infer more about the contents than just the sender, especially when you can pattern match against known behavior for that sender.

Are you confusing DPI with MITM or something?

DPI does not require any decryption of payload. Even cheap consumer devices can perform DPI on encrypted traffic. ISPs absolutely use DPI as a part of standard practice, and have been for decades. It is a basic network traffic management tool.

Reply on news.ycombinator.com