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

[Rich Brown]

> 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. 

- 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.

My proposal:

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

- 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?

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
>