[Rpm] Does RPM measurement *require* a valid SSL certificate

[Omer Shapira]

> On Oct 20, 2021, at 11:30 AM, Christoph Paasch via Rpm <rpm at lists.bufferbloat.net> wrote:
> 
> 
> 
>> On Oct 15, 2021, at 8:10 AM, Rich Brown <richb.hanover at gmail.com> wrote:
>> 
>> 
>> 
>>> On Oct 14, 2021, at 4:27 PM, Christoph Paasch <cpaasch at apple.com> wrote:
>>> 
>>> On 10/13/21 - 17:57, Rich Brown via Rpm wrote:
>>>> 
>>>>> On Oct 13, 2021, at 3:45 PM, Randall Meyer <rrm at apple.com> wrote:
>>>>> 
>>>>> We could add a “—insecure/-k” switch as a feature enhancement to the CLI.
>>>> 
>>>> Or maybe just ignore the certificate. More options is worse, if you have to implement/explain/justify them. 
>>> 
>>> Ignoring is not a good option. Otherwise, traffic could be intercepted and
>>> one could cheat its RPM-value by having a local termination-point on its AP.
>> 
>> I see your concern, but I'm trying to balance that against my hope that RPM Servers can be widely deployed. I'm especially hopeful they'd be in our home routers, so we can check the local connections via Wi-Fi. 
>> 
>> To be clear about my concern: it's easy enough to stand up code to respond to the HTTPS requests. But it's a whole lot more work to get a signed SSL certificate, and that could discourage alternate implementations.
>> 
>> Help me think through the threat model and the use cases. (Sorry if I'm being wordy or redundant. Writing things out helps me think things through...) Use cases:
>> 
>> - People using the built-in iOS and macOS clients testing against Apple servers, or Apple-provided CDNs, all have access to signed SSL certificates. This is a huge use case, so I don't have to worry about that.
>> 
>> - People using those clients but specifying a different RPM Server. It'll be one of those implementations from the github networkQuality/server repo, or an OpenWrt package, or random router manufacturer's own built-in RPM Server. 


Several thoughts:

1. The `/usr/bin/networkQuality` is using HTTP2, since this is the prevalent protocol used for exchanging information over the Internet today. I’m sure you know that HTTP2 is tightly couples with TLS 1.2. The point is that it’s quite unlikely that someone is able to implement HTTP2 server while not being able to provide a valid TLS certificate during the handshake.

2. The notion that “it’s easy enough to stand up code to respond to HTTP” - this may be true, but the role of the server is not to just respond, it will have to actually saturate the link. This requires sufficient processing power to send the data at the required rate. Hence, the boxes that rely on a SOC to move the bytes, and have low power master CPU may not be able to saturate the link.

My point is that it’s unclear that the devices at the lowest price point will be able to implement the RPM server correctly, and I’d be quite curious to learn otherwise. In the absence of evidence that this is possible at all, we may be trying to solve a problem that does not exist.


> And these users, will already have to specify the custom server in the command-line with the "-C" option. So, it will be easy for them to also specify "-k/--insecure".
> 
> Because, the alternative would be to add a "-K/--secure" option to allow users who want to test against a non-standard server to be 100% sure that they are actually not being MITM'ed. And we are definitely not going to add a "--secure" option. Security/privacy is the default, not the other way around :)
> 
> 
> Christoph
> 
>> 
>> - People who write their own client. (Side note: I'd love to see reference Python and Javascript implementations.) These will test against the default Apple RPM servers, or some custom server.
>> 
>> Does that cover all the use cases?
>> 
>> Then let's consider the threats...
>> 
>> - I agree that it would be bad for the builtin clients, using default settings, to get MITM'd. But Apple's extensive SSL machinery covers that threat.
>> 
>> - Any client (builtin or homegrown) going against a non-Apple RPM Server is subject to all sorts of uncertainties. What if the Go or Swift server has been (poorly) modified? Or that it's running on an 80MHz Pentium :-) I suspect that the signed/not-signed certificate is the least of the worries.

I would make an argument that RPM server that’s unable to procure an SSL certificate should not be trusted to saturate the network correctly.  Because of that, the RPM numbers are likely to be either incorrect or inconclusive, which has the potential of hurting the credibility of the RPM metric.

Continuing this argument, requiring a valid (not self-signed) SSL certificate allows asserting that the implementor of the server is capable of implementing it correctly. 

Back to the point of “making RPM metric available on the bottom price point devices” - we may want to get to the drawing board and to think of the ways of using different type of traffic for such devices.


>> My proposal:
>> 
>> I would be tempted *not* to have a command-line option to "accept insecure connections." Instead:

Hm. The client does not accept connections. The purpose of the SSL certificate is assert the identity of the server. If my understanding is correct, what you meant is “not having a command line option to forgo validation of the server’s identity”.


>> - A builtin client using the default RPM server could refuse to talk to an RPM server with an unsigned certificate, as it apparently does now.
>> 
>> - A builtin client connecting to a user-specified RPM server could accept any connection, and note in the output both the actual RPM Server used, and whether the certificate was signed.
>> 
>> - A homegrown client could work the same.
>> 
>> Is this reasonable behavior? What would be the downsides?

Several… 

1. Apple’s stance on the user’s privacy is strong enough to avoid proliferation of insecure HTTP. Hence, the “trust everyone by default” behavior is unlikely to fly. This of course does not prevent “a homegrown client” to have different values.

2. Lack of SSL certificate is one of those “smells of poor implementation”, which opens a door for eroding the credibility of the metric. In this sense, starting with the requirement to have a valid SSL certificate by default seems to be the right strategic choice.

3. It’s often best to minimize the surprise. In general, “forfeiting the right to know who’s the server we are talking to” is something that requires some explicit input from the user. Given that using a non-standard server is already predicated by user adding parameters, the use of `-k` flag (following the vocabulary that’s been set by the ssh) seems the right thing to do.

>> Thanks
>> 
>> Rich
>> 
>>> 
>>> 
>>> Christoph
>>> 
>>>> 
>>>> In the context of an RPM test, where there would be (max) dozens of SSL calculations per second, I suspect that the difference between a self-signed certificate and a "real one" would be negligible.
>>>> 
>>>> Thanks.
>>>> 
>>>> Rich
>>> 
>>>> _______________________________________________
>>>> Rpm mailing list
>>>> Rpm at lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/rpm
> 
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm