Improve Handling of PKCS1 Padding Fix

[mfeit-internet2]

Context

• Version of iperf3: 3.17

• Hardware: Any

• Operating system (and distribution, if any): Any

• Other relevant information (for example, non-default compilers, libraries, cross-compiling, etc.): None

Bug Enhancement Report Request

Pardon me for violating the format, but this one's a hybrid. :-)

Re. this bit in 3.17:

This release includes several important bug fixes, as well as a correction for a possible side-channel timing vulnerability. To address this issue, a change has been made to the padding applied to encrypted strings. This change is not backwards compatible with older versions of iperf3 (before 3.17). To restore older (vulnerable) behavior for backwards compatibility, please use the --use-pkcs1-padding flag.

I've just added code to pScheduler's iperf3 plugin that makes it able to suss out whether the opposite end is <= 3.16 and requires the switch or if it's >= 3.17 and doesn't. It works when there are two pSchedulers involved or just one in loopback mode because anything using the new version of iperf3 includes what version it's using. That was easy.

The hard part is single-ended testing, where there's one pScheduler and it has no idea whether the free-floating iperf3 server at the other end is old and requires the switch. If we unilaterally use or don't use the new switch, it will doom us to only being able to talk to 3.16 or 3.17+ systems pretty much forever. Where I am now, I'm forced to break compatibility with 3.16 for these cases. There will be perfSONAR users who won't like this.

I do not want to add a switch to pScheduler's throughput test for this. Tests are supposed to be abstract and the plugins should handle the tools' idiosyncrasies and the end users shouldn't have to figure out what version the other end is running.

Suggested Fix

The iperf3 client and server should exchange version information an adjust their behavior internally rather than forcing the invoker to figure out what versions are involved. This can be done in a non-backward-compatibility-breaking way by following these rules:

• A 3.16 client connecting to a 3.16 or 3.17 server does nothing different because it doesn't know anything about the padding fix.

• A 3.17 client connecting to a 3.16 server should see the absence of version information in the server's data and disable the padding fix.

• A 3.17 client connecting to a 3.17 server should see version information and enable the padding fix.

• A 3.16 server servicing any client does nothing different because it doesn't know anything about the padding fix.

• A 3.17 server servicing a 3.16 client should see the absence of version information from the client and disable the padding fix.

• A 3.17 server servicing a 3.17 client should see version information and enable the padding fix because both ends can handle it.

(The code I added to the pScheduler plugin does essentially this.)

For sites with a hard requirement that iperf3 not operate in a vulnerable mode, I recommend one of the following:

• Add a --fully-secure switch that will abort the test if that happens.
• Look for a configuration file somewhere in /etc, maybe /etc/iperf3.conf that can enable that for all invocations.

I'm past my brain cell quota for the day, so if any of the foregoing doesn't make sense, I'm happy to clarify.

[swlars]

We'll keep this in mind, but we're having trouble coming up with a graceful way of handling this for now.