5 ms·

I think you're underestimating the CPU requirements. If a weak Android phone is only able to decode 50Mb/s of TLS traffic, that's not a big problem in practice.

I think you're underestimating the CPU requirements. If a weak Android phone is only able to decode 50Mb/s of TLS traffic, that's not a big problem in practice. It's a slow phone, usually connected to slow networks. On the other hand, if you have a gigabit internet connection at home and it is being bottlenecked to 50Mb/s by that weak device sitting between all of your computers and the internet, then that is a big problem. The CPU requirements for TLS are extremely dependent on the desired bandwidth. At even higher bandwidth, offloading onto accelerators becomes important to be able to do it at all. The cost of handshakes is also nontrivial, and can limit the number of connections per second. For a single device, rarely a big deal. For an entire network of devices, it can be a bigger problem.

lxgr 3y ago
> If a weak Android phone is only able to decode 50Mb/s of TLS traffic That's a lower, not an upper bound. An RPi 4 can encrypt/decrypt AES-256-GCM at more than 300 Mbit/s, according to my rough measurements. That's per core, of which it has four. RSA can be much more expensive, but that's besides the point – the author was claiming that AES-NI makes a meaningful difference here, which I'd really doubt even in the case of TLS. (As mentioned above, it can't help at all for Wireguard.)
- coder543 3y ago
  > 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.
- ComputerGuru 3y ago
  > An RPi 4 can encrypt/decrypt AES-256-GCM at more than 300 Mbit/s, according to my rough measurements. That's per core, of which it has four. But the bottleneck is usually in terminating and establishing SSL connections?
cbsmith 3y ago
The author also seemed to think parsing a <2MB protobuf was CPU intensive. Even for a cheap embedded network device, you'll never convince me that is true.
- coder543 3y ago
  But... can you do it at 1Gbps on a single core of a Raspberry Pi? You have to both parse and then reencode it. 1000Mbps = 125MBps. 125MBps/(2MB/message) = 62 messages per second. 62 messages per second means that you have 16ms to do 5 things: decrypt the TLS, parse the protobuf message, filter the message, encode the protobuf message, encrypt the TLS traffic. If you take more than 16ms, you cannot achieve 1Gbps. We've already established[0] that you can't even hit 1Gbps with just the TLS traffic. The protobuf messages might be fast to parse... but they will still slow things down even further. [0]: https://news.ycombinator.com/item?id=37284909 https://news.ycombinator.com/item?id=37284909
  - cbsmith 3y ago
    > But... can you do it at 1Gbps on a single core of a Raspberry Pi? Probably not, but if you've only got a single Raspberry PI core at your disposal and you're trying to pump 1000 Mbps of network traffic through said Raspberry PI, you've already got significant challenges. > 62 messages per second means that you have 16ms to do 5 things: decrypt the TLS, parse the protobuf message, filter the message, encode the protobuf message, encrypt the TLS traffic. If you take more than 16ms, you cannot achieve 1Gbps. Let's just say you have a system that can do all that in 16ms. I would estimate significantly less than 1ms of that time would be spent parsing and encoding the protobuf message.
    - coder543 3y ago
      > I would estimate significantly less than 1ms of that time would be spent parsing and encoding the protobuf message. It would just be nice to see a representative benchmark on a Raspberry Pi 4. I generally agree with you on that point, but I don't consider anything a "given" on something as weak as a Pi.
mcpackieh 3y ago
I think most people with gigabit internet at home never max out their pipe with a single connection, not even close. The real value of gigabit internet, for most people, is being able to handle numerous family members all doing their thing online at once without stepping on each other's toes.
- coder543 3y ago
  > I think most people with gigabit internet at home never max out their pipe with a single connection, not even close. I don't agree, but for argument's sake, where do you draw the line? What is acceptable? 10Mbps? Each person would have a different answer.
  - mcpackieh 3y ago
    Whatever is the max any streaming service uses.
- lxgr 3y ago
  True, and I'd argue that the most significant benefit Gigabit home internet provides is (at least in many cases) a meaningful upload data rate. Upload congestion, together with massive Bufferbloat powered by horrendously configured CPEs, is what makes home internet connections feel slow most of the time.

lxgr 3y ago

> If a weak Android phone is only able to decode 50Mb/s of TLS traffic That's a lower, not an upper bound. An RPi 4 can encrypt/decrypt AES-256-GCM at more than 300 Mbit/s, according to my rough measurements. That's per core, of which it has four. RSA can be much more expensive, but that's besides the point – the author was claiming that AES-NI makes a meaningful difference here, which I'd really doubt even in the case of TLS. (As mentioned above, it can't help at all for Wireguard.)

coder543 3y ago
> 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.
ComputerGuru 3y ago
> An RPi 4 can encrypt/decrypt AES-256-GCM at more than 300 Mbit/s, according to my rough measurements. That's per core, of which it has four. But the bottleneck is usually in terminating and establishing SSL connections?

cbsmith 3y ago

The author also seemed to think parsing a <2MB protobuf was CPU intensive. Even for a cheap embedded network device, you'll never convince me that is true.

coder543 3y ago
But... can you do it at 1Gbps on a single core of a Raspberry Pi? You have to both parse and then reencode it. 1000Mbps = 125MBps. 125MBps/(2MB/message) = 62 messages per second. 62 messages per second means that you have 16ms to do 5 things: decrypt the TLS, parse the protobuf message, filter the message, encode the protobuf message, encrypt the TLS traffic. If you take more than 16ms, you cannot achieve 1Gbps. We've already established[0] that you can't even hit 1Gbps with just the TLS traffic. The protobuf messages might be fast to parse... but they will still slow things down even further. [0]: https://news.ycombinator.com/item?id=37284909 https://news.ycombinator.com/item?id=37284909
- cbsmith 3y ago
  > But... can you do it at 1Gbps on a single core of a Raspberry Pi? Probably not, but if you've only got a single Raspberry PI core at your disposal and you're trying to pump 1000 Mbps of network traffic through said Raspberry PI, you've already got significant challenges. > 62 messages per second means that you have 16ms to do 5 things: decrypt the TLS, parse the protobuf message, filter the message, encode the protobuf message, encrypt the TLS traffic. If you take more than 16ms, you cannot achieve 1Gbps. Let's just say you have a system that can do all that in 16ms. I would estimate significantly less than 1ms of that time would be spent parsing and encoding the protobuf message.
  - coder543 3y ago
    > I would estimate significantly less than 1ms of that time would be spent parsing and encoding the protobuf message. It would just be nice to see a representative benchmark on a Raspberry Pi 4. I generally agree with you on that point, but I don't consider anything a "given" on something as weak as a Pi.

mcpackieh 3y ago

I think most people with gigabit internet at home never max out their pipe with a single connection, not even close. The real value of gigabit internet, for most people, is being able to handle numerous family members all doing their thing online at once without stepping on each other's toes.

coder543 3y ago
> I think most people with gigabit internet at home never max out their pipe with a single connection, not even close. I don't agree, but for argument's sake, where do you draw the line? What is acceptable? 10Mbps? Each person would have a different answer.
- mcpackieh 3y ago
  Whatever is the max any streaming service uses.
lxgr 3y ago
True, and I'd argue that the most significant benefit Gigabit home internet provides is (at least in many cases) a meaningful upload data rate. Upload congestion, together with massive Bufferbloat powered by horrendously configured CPEs, is what makes home internet connections feel slow most of the time.