5 ms·

> That's per core, of which it has four. Which only matters for multiple concurrent connections... a single download would still be a sequential task on a sing

> That's per core, of which it has four. Which only matters for multiple concurrent connections... a single download would still be a sequential task on a single core at 300Mb/s, which I would find to be an unacceptable bottleneck on my gigabit connection. In reality, it would probably only be 300Mb/s for up to 2 connections, since it needs to both decrypt and reencrypt, which could be parallelized onto 2 cores, otherwise 150Mbps for 4 connections if each connection was handled only on a single core. Either way, it would not be possible to MitM 1Gbps of traffic on a Raspberry Pi 4, with the numbers you provided, only 600Mbps total, and only across multiple connections. It would be an extremely noticeable bottleneck.

cbsmith 3y ago
A few points... If you've got a Raspberry Pi 4 as your proxy, aren't you already struggling to pump more than 600Mbps over your network? Even if so, are you really pulling down more than 300Mb/s over a single TLS connection? Even in that scenario, AES encryption/decryption can be parallelized (https://github.com/gurupunskill/parallel-aes https://github.com/gurupunskill/parallel-aes). To me, it seems like a pretty narrow set of scenarios where you'd not have the processing power to decrypt/encrypt at the speed of your network.
- coder543 3y ago
  > If you've got a Raspberry Pi 4 as your proxy, aren't you already struggling to pump more than 600Mbps over your network? The Pi 4 is capable of a full gigabit connection, unlike previous Raspberry Pis. So, no, not fundamentally. > To me, it seems like a pretty narrow set of scenarios where you'd not have the processing power to decrypt/encrypt at the speed of your network. The whole scenario was set up by the comment at the top of this thread: "I'd be really surprised if MITMing TLS on an RPi 4 was actually infeasible, even when using RSA cryptography purely in software."[0] I consider it "infeasible" if it is a significant bottleneck on the network. It could be infeasible for multiple reasons, as you're alluding to, but that only strengthens my argument. > Even in that scenario, AES encryption/decryption can be parallelized An AES implementation that no one uses is not a very compelling argument, except as a hypothetical. Do trusted AES implementations do the encryption in parallel? That's all that matters, IMO. [0]: https://news.ycombinator.com/item?id=37282322 https://news.ycombinator.com/item?id=37282322
  - cbsmith 3y ago
    > An AES implementation that no one uses is not a very compelling argument, except as a hypothetical. The entire whole scenario is hypothetical!!! Yes, there aren't a lot of AES implementations that use CPU & GPU for decryption, but if you're setting up a multicore network device a CPU parallel AES implementation isn't unreasonable. > I consider it "infeasible" if it is a significant bottleneck on the network. So there's a lot of vague terms and hypotheticals, as you say. I would presume it is possible to have a network where data over even a single connection traveled so fast over a Raspberry Pi 4, where you had no access to a parallel implementation of AES, where the performance impact of routing everything through the Raspberry Pi were deemed acceptable, but the consequent slowdown in performance might be deemed "infeasible" by some, yet if you were to drop in a comparable device with an AES-NI capable CPU, the consequent ~4x performance improvement would allow for it to be deemed "feasible". Another "feasible" solution would likely be to spend roughly the equivalent of two months of what you were paying for the Internet connection on the bottleneck you've created in your network. Yes, it's possible to construct the necessary hypothetical, but it's not exactly a common scenario.
    - coder543 3y ago
      > The entire whole scenario is hypothetical!!! I do not agree at all. Some people may actually want to use the technique detailed in the article. Most people do not have a powerful, enterprise-grade router they can run software on, so they would reach for another device. A Raspberry Pi is frequently used for PiHole and similar functions, so it is logical that someone would reach for a Raspberry Pi 4 here. What part of this seems hypothetical? An AES library that might not even work (since no one actually uses it), let alone is likely difficult to integrate into the software stack described in the article is extremely hypothetical in a way that the actual project would not be. That parallel AES implementation is not some proven library with great documentation... it's a random github repo that hasn't been updated in 5 years. If the feasibility of the project depends on that, that seems like a bad place to start. > where you had no access to a parallel implementation of AES You don't. Unless you're saying the author has already integrated this into the described software stack? And proven that it works. > yet if you were to drop in a comparable device with an AES-NI capable CPU, the consequent ~4x performance improvement would allow for it to be deemed "feasible". That does not seem hypothetical. That appears to be extremely real. Of course, the speedup would likely come from multiple factors, not just AES-NI, given that you can't find a Raspberry Pi with AES-NI to have a pure apples-to-apples comparison. > Yes, it's possible to construct the necessary hypothetical, but it's not exactly a common scenario. I have no idea what you're talking about. This scenario is not convoluted like you're trying to make it out to be.
lxgr 3y ago
> Either way, it would not be possible to MitM 1Gbps of traffic on a Raspberry Pi 4 [...] It would be an extremely noticeable bottleneck. For YouTube videos!?
- coder543 3y ago
  Presumably, it has to MitM all traffic going to/from the WAN in order to MitM YouTube traffic. Encrypted Client Hello / Secure SNI / Encrypted SNI prevents the hostname for each connection from leaking in plaintext. DNS-over-HTTPS prevents anyone on the local network from snooping on the DNS lookup to realize which connections are for a given domain name. I guess a sufficiently advanced implementation would stop MitMing a connection once it is not talking to YouTube, but as a broader ad-blocking technique, this would apply to more than just YouTube. Even just focusing on YouTube, lower bandwidth means that you have longer pauses when you skip around any video that isn't super short, as it attempts to buffer that section of the video.
  - lxgr 3y ago
    > Encrypted SNI prevents the hostname for each connection from leaking in plaintext. True, but almost nobody uses that yet. Youtube certainly doesn't. > DNS-over-HTTPS prevents anyone on the local network from snooping on the DNS lookup to realize which connections are for a given domain name. The author of TFA is MITMing their own Apple TV. In that scenario, they could just configure their own DNS proxy as well. But given that there's no eSNI, it's not even necessary. And even if you'd need to MITM all flows to and from YouTube on your local network – that would still be only a few Mbit/s per device, given YouTube's (non-premium) potato-quality data rates.

cbsmith 3y ago

A few points... If you've got a Raspberry Pi 4 as your proxy, aren't you already struggling to pump more than 600Mbps over your network? Even if so, are you really pulling down more than 300Mb/s over a single TLS connection? Even in that scenario, AES encryption/decryption can be parallelized (https://github.com/gurupunskill/parallel-aes https://github.com/gurupunskill/parallel-aes). To me, it seems like a pretty narrow set of scenarios where you'd not have the processing power to decrypt/encrypt at the speed of your network.

coder543 3y ago
> If you've got a Raspberry Pi 4 as your proxy, aren't you already struggling to pump more than 600Mbps over your network? The Pi 4 is capable of a full gigabit connection, unlike previous Raspberry Pis. So, no, not fundamentally. > To me, it seems like a pretty narrow set of scenarios where you'd not have the processing power to decrypt/encrypt at the speed of your network. The whole scenario was set up by the comment at the top of this thread: "I'd be really surprised if MITMing TLS on an RPi 4 was actually infeasible, even when using RSA cryptography purely in software."[0] I consider it "infeasible" if it is a significant bottleneck on the network. It could be infeasible for multiple reasons, as you're alluding to, but that only strengthens my argument. > Even in that scenario, AES encryption/decryption can be parallelized An AES implementation that no one uses is not a very compelling argument, except as a hypothetical. Do trusted AES implementations do the encryption in parallel? That's all that matters, IMO. [0]: https://news.ycombinator.com/item?id=37282322 https://news.ycombinator.com/item?id=37282322
- cbsmith 3y ago
  > An AES implementation that no one uses is not a very compelling argument, except as a hypothetical. The entire whole scenario is hypothetical!!! Yes, there aren't a lot of AES implementations that use CPU & GPU for decryption, but if you're setting up a multicore network device a CPU parallel AES implementation isn't unreasonable. > I consider it "infeasible" if it is a significant bottleneck on the network. So there's a lot of vague terms and hypotheticals, as you say. I would presume it is possible to have a network where data over even a single connection traveled so fast over a Raspberry Pi 4, where you had no access to a parallel implementation of AES, where the performance impact of routing everything through the Raspberry Pi were deemed acceptable, but the consequent slowdown in performance might be deemed "infeasible" by some, yet if you were to drop in a comparable device with an AES-NI capable CPU, the consequent ~4x performance improvement would allow for it to be deemed "feasible". Another "feasible" solution would likely be to spend roughly the equivalent of two months of what you were paying for the Internet connection on the bottleneck you've created in your network. Yes, it's possible to construct the necessary hypothetical, but it's not exactly a common scenario.
  - coder543 3y ago
    > The entire whole scenario is hypothetical!!! I do not agree at all. Some people may actually want to use the technique detailed in the article. Most people do not have a powerful, enterprise-grade router they can run software on, so they would reach for another device. A Raspberry Pi is frequently used for PiHole and similar functions, so it is logical that someone would reach for a Raspberry Pi 4 here. What part of this seems hypothetical? An AES library that might not even work (since no one actually uses it), let alone is likely difficult to integrate into the software stack described in the article is extremely hypothetical in a way that the actual project would not be. That parallel AES implementation is not some proven library with great documentation... it's a random github repo that hasn't been updated in 5 years. If the feasibility of the project depends on that, that seems like a bad place to start. > where you had no access to a parallel implementation of AES You don't. Unless you're saying the author has already integrated this into the described software stack? And proven that it works. > yet if you were to drop in a comparable device with an AES-NI capable CPU, the consequent ~4x performance improvement would allow for it to be deemed "feasible". That does not seem hypothetical. That appears to be extremely real. Of course, the speedup would likely come from multiple factors, not just AES-NI, given that you can't find a Raspberry Pi with AES-NI to have a pure apples-to-apples comparison. > Yes, it's possible to construct the necessary hypothetical, but it's not exactly a common scenario. I have no idea what you're talking about. This scenario is not convoluted like you're trying to make it out to be.

lxgr 3y ago

> Either way, it would not be possible to MitM 1Gbps of traffic on a Raspberry Pi 4 [...] It would be an extremely noticeable bottleneck. For YouTube videos!?

coder543 3y ago
Presumably, it has to MitM all traffic going to/from the WAN in order to MitM YouTube traffic. Encrypted Client Hello / Secure SNI / Encrypted SNI prevents the hostname for each connection from leaking in plaintext. DNS-over-HTTPS prevents anyone on the local network from snooping on the DNS lookup to realize which connections are for a given domain name. I guess a sufficiently advanced implementation would stop MitMing a connection once it is not talking to YouTube, but as a broader ad-blocking technique, this would apply to more than just YouTube. Even just focusing on YouTube, lower bandwidth means that you have longer pauses when you skip around any video that isn't super short, as it attempts to buffer that section of the video.
- lxgr 3y ago
  > Encrypted SNI prevents the hostname for each connection from leaking in plaintext. True, but almost nobody uses that yet. Youtube certainly doesn't. > DNS-over-HTTPS prevents anyone on the local network from snooping on the DNS lookup to realize which connections are for a given domain name. The author of TFA is MITMing their own Apple TV. In that scenario, they could just configure their own DNS proxy as well. But given that there's no eSNI, it's not even necessary. And even if you'd need to MITM all flows to and from YouTube on your local network – that would still be only a few Mbit/s per device, given YouTube's (non-premium) potato-quality data rates.