6 ms·

> doesn’t encrypt the destination IP address How would that work?

by nmjohn 7y ago

brians 7y ago
The simplest system I know to mask destination IP is an anonymizing mixnet. Tor is a good approximation: delegate your privacy to a system design. A CDN, or what Google’s doing with signed exchanges, is a bad approximation: delegate your privacy to an entity. For certain very specific goals, Psiphon is an intermediate solution. Alternatively, “it doesn’t work.” As Colm says elsewhere, the placement of TLS in the stack isn’t compatible with privacy goals. There’s a big project to nudge the current privacy-ignoring design of the Internet into a privacy-respecting design, while continuously maintaining compatibility and providing performance incentives to bring the mega corps along. The engineers pushing that are supremely skilled and passionately motivated. If anyone can do it, they can. I am not optimistic, mostly because I expect the mass of less-skilled but equally-passionate consumers of that technology to latch on to intermediate solutions—like the recent Firefox-CF DoH experiment—and lock them in.
- londons_explore 7y ago
  The test I like to use is "If I go into my bedroom and browse porn online, I expect nobody to know what I'm up to". Today, pornhub.com knows I visited and what I clicked on. My ISP knows I went to pornhub. Even people on my local network know I went to PornHub. Through packet size analysis, all those parties even know what I typed in the search box at PornHub (each possible keystroke results in a different number of bytes of autocomplete Ajax). TLS failed to achieve any of the privacy the user expected. The infosec community has missed the big picfure...
  - jrockway 7y ago
    I don't think those were ever the goals of TLS, they are just some random things you want or think people want. What TLS does is: 1) Prevent your local network or ISP from tricking you into visiting a fake pornhub. If you type that in and it loads over TLS, you know you're at the real one. 2) Prevent your local network or ISP from reading any of the data you exchange with pornhub. This, of course, provides quite a bit of value. It's not everything you want, but it is a big win for many users.
    - Dylan16807 7y ago
      It does the first one. The second one doesn't do so well against packet size analysis.
      - jrockway 7y ago
        Yeah, but that's a pretty obscure attack. All bank customers have the same length account number. All the videos on YouTube have the same length identifier and usually last about 10 minutes and 1 second. Some information is leaked through packet size and timing. But a lot isn't. I am also guessing that 1 capture doesn't give you a very good signal to noise ratio. Sure, if you capture someone's keyboard-interactive ssh exchange 100 times a day for 6 months, you have a lot of data. For your porn searches or whatever, I doubt the sample size is enough to leak a ton of information. And it's certainly better than just letting the person capturing packets read them and see what's in there.
        arkadiyt 7y ago
        > Yeah, but that's a pretty obscure attack. I'm certain nation states work on developing these attacks. Also a commercial company just has to build it once, then they can sell it to ISPs who make money selling your data. > All bank customers have the same length account number. This isn't the only problem with packet size data, there have been compression attacks that can recover plaintext using packet sizes, like CRIME and BREACH. > All the videos on YouTube have the same length identifier and usually last about 10 minutes and 1 second Here's a research paper from 2017 where someone in a MITM position could detect exactly what netflix video you were watching by looking at packet sizes: https://mjkranch.com/docs/pubs/CODASPY17_Kranch_Reed_IdentifyingHTTPSNetflix.pdf https://mjkranch.com/docs/pubs/CODASPY17_Kranch_Reed_Identif... Of course TLS still provides a critical level of security and privacy, but there is room for improvement.
        saurik 7y ago
        You still don't understand. While the average time length of a YouTube video might be 10m1s, the time length of a specific video isn't. Worse, the file sizes are all quite different even if the time length is the same due to video compression. The way these sites work is you download segments of the video of fixed time length (such as two seconds), roughly in order, and so it becomes trivial to fingerprint which video you are watching by what sequence of specific file sizes someone downloads. This is absolutely not an "obscure" attack: it has been used, successfully, to build a tool to guess what city you are looking at with Google Maps. There, tiles are downloaded to render a map (similar to the segments used to render a video on YouTube). While each tile may have a fixed dimension, again, due to image compression, each tile has a different file size. Since tiles are downloaded in clusters, you can pretty readily fingerprint different regions of the map a user is looking at (and if it weren't for local caching, it would work almost instantly 100% of the time, live). With type-ahead searching, as each character you type returns a different list, given the file size response sequence you should be able to determine exactly what search query someone made with almost total accuracy almost all of the time when they type it, with the only reason it ever not working well being due to caches and delayed queries (if you type fast enough on many type-ahead query boxes it will avoid sending queries for the prefixes, to reduce load for something that by the time the result is fetched won't even render).

> doesn’t encrypt the destination IP address How would that work?

by nmjohn 7y ago

> doesn’t encrypt the destination IP address How would that work?

The simplest system I know to mask destination IP is an anonymizing mixnet. Tor is a good approximation: delegate your privacy to a system design. A CDN, or what Google’s doing with signed exchanges, is a bad approximation: delegate your privacy to an entity. For certain very specific goals, Psiphon is an intermediate solution. Alternatively, “it doesn’t work.” As Colm says elsewhere, the placement of TLS in the stack isn’t compatible with privacy goals. There’s a big project to nudge the current privacy-ignoring design of the Internet into a privacy-respecting design, while continuously maintaining compatibility and providing performance incentives to bring the mega corps along. The engineers pushing that are supremely skilled and passionately motivated. If anyone can do it, they can. I am not optimistic, mostly because I expect the mass of less-skilled but equally-passionate consumers of that technology to latch on to intermediate solutions—like the recent Firefox-CF DoH experiment—and lock them in.

londons_explore 7y ago
The test I like to use is "If I go into my bedroom and browse porn online, I expect nobody to know what I'm up to". Today, pornhub.com knows I visited and what I clicked on. My ISP knows I went to pornhub. Even people on my local network know I went to PornHub. Through packet size analysis, all those parties even know what I typed in the search box at PornHub (each possible keystroke results in a different number of bytes of autocomplete Ajax). TLS failed to achieve any of the privacy the user expected. The infosec community has missed the big picfure...
- jrockway 7y ago
  I don't think those were ever the goals of TLS, they are just some random things you want or think people want. What TLS does is: 1) Prevent your local network or ISP from tricking you into visiting a fake pornhub. If you type that in and it loads over TLS, you know you're at the real one. 2) Prevent your local network or ISP from reading any of the data you exchange with pornhub. This, of course, provides quite a bit of value. It's not everything you want, but it is a big win for many users.
  - Dylan16807 7y ago
    It does the first one. The second one doesn't do so well against packet size analysis.
    - jrockway 7y ago
      Yeah, but that's a pretty obscure attack. All bank customers have the same length account number. All the videos on YouTube have the same length identifier and usually last about 10 minutes and 1 second. Some information is leaked through packet size and timing. But a lot isn't. I am also guessing that 1 capture doesn't give you a very good signal to noise ratio. Sure, if you capture someone's keyboard-interactive ssh exchange 100 times a day for 6 months, you have a lot of data. For your porn searches or whatever, I doubt the sample size is enough to leak a ton of information. And it's certainly better than just letting the person capturing packets read them and see what's in there.
      - arkadiyt 7y ago
        > Yeah, but that's a pretty obscure attack. I'm certain nation states work on developing these attacks. Also a commercial company just has to build it once, then they can sell it to ISPs who make money selling your data. > All bank customers have the same length account number. This isn't the only problem with packet size data, there have been compression attacks that can recover plaintext using packet sizes, like CRIME and BREACH. > All the videos on YouTube have the same length identifier and usually last about 10 minutes and 1 second Here's a research paper from 2017 where someone in a MITM position could detect exactly what netflix video you were watching by looking at packet sizes: https://mjkranch.com/docs/pubs/CODASPY17_Kranch_Reed_IdentifyingHTTPSNetflix.pdf https://mjkranch.com/docs/pubs/CODASPY17_Kranch_Reed_Identif... Of course TLS still provides a critical level of security and privacy, but there is room for improvement.
      - saurik 7y ago
        You still don't understand. While the average time length of a YouTube video might be 10m1s, the time length of a specific video isn't. Worse, the file sizes are all quite different even if the time length is the same due to video compression. The way these sites work is you download segments of the video of fixed time length (such as two seconds), roughly in order, and so it becomes trivial to fingerprint which video you are watching by what sequence of specific file sizes someone downloads. This is absolutely not an "obscure" attack: it has been used, successfully, to build a tool to guess what city you are looking at with Google Maps. There, tiles are downloaded to render a map (similar to the segments used to render a video on YouTube). While each tile may have a fixed dimension, again, due to image compression, each tile has a different file size. Since tiles are downloaded in clusters, you can pretty readily fingerprint different regions of the map a user is looking at (and if it weren't for local caching, it would work almost instantly 100% of the time, live). With type-ahead searching, as each character you type returns a different list, given the file size response sequence you should be able to determine exactly what search query someone made with almost total accuracy almost all of the time when they type it, with the only reason it ever not working well being due to caches and delayed queries (if you type fast enough on many type-ahead query boxes it will avoid sending queries for the prefixes, to reduce load for something that by the time the result is fetched won't even render).