From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 120023CB41 for ; Fri, 15 Oct 2021 12:38:47 -0400 (EDT) X-Auth-ID: jf@jonathanfoulkes.com Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: jf-AT-jonathanfoulkes.com) with ESMTPSA id 8BA7323A17; Fri, 15 Oct 2021 12:38:46 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Jonathan Foulkes In-Reply-To: Date: Fri, 15 Oct 2021 12:38:45 -0400 Cc: Christoph Paasch , rpm@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B7910A6-9157-40DD-8C50-FE42AEDB7797@apple.com> <8F8B59C1-9FB7-4B3E-9C15-14180721FEA8@gmail.com> To: Rich Brown X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Classification-ID: 9e8f12c7-7709-4c23-b08c-4af04cb02aae-1-1 Subject: Re: [Rpm] Does RPM measurement *require* a valid SSL certificate X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 16:38:47 -0000 Good thread, and as one of the guys eager to deploy what Rich calls for > I'm especially hopeful they'd be in our home routers, so we can check = the local connections via Wi-Fi. > or random router manufacturer's own built-in RPM Server.=20 Yep, that would be me ;-) > I would be tempted *not* to have a command-line option to "accept = insecure connections." Instead: I like simplicity, so yes to this. > - 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. Again, also see this as reasonable, as the user is the one explicitly = stating where they want to go. The UI can be as vocal as it wants about = risks, just let me get there. So if I specify iqrouter.lan as the target, I get a result and the state = of any certs used. Same if I stand up an RPM server on a MacMini on my local lan. Or a test = server on a transient AWS instance. Cheers, Jonathan > On Oct 15, 2021, at 11:10 AM, Rich Brown via Rpm = wrote: >=20 >=20 >=20 >> On Oct 14, 2021, at 4:27 PM, Christoph Paasch = wrote: >>=20 >> On 10/13/21 - 17:57, Rich Brown via Rpm wrote: >>>=20 >>>> On Oct 13, 2021, at 3:45 PM, Randall Meyer wrote: >>>>=20 >>>> We could add a =E2=80=9C=E2=80=94insecure/-k=E2=80=9D switch as a = feature enhancement to the CLI. >>>=20 >>> Or maybe just ignore the certificate. More options is worse, if you = have to implement/explain/justify them.=20 >>=20 >> 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. >=20 > 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.=20= >=20 > 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. >=20 > 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: >=20 > - 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. >=20 > - 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.=20 >=20 > - 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. >=20 > Does that cover all the use cases? >=20 > Then let's consider the threats... >=20 > - 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. >=20 > - 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. >=20 > My proposal: >=20 > I would be tempted *not* to have a command-line option to "accept = insecure connections." Instead: >=20 > - 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. >=20 > - 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. >=20 > - A homegrown client could work the same. >=20 > Is this reasonable behavior? What would be the downsides? >=20 > Thanks. >=20 > Rich >=20 >>=20 >>=20 >> Christoph >>=20 >>>=20 >>> 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. >>>=20 >>> Thanks. >>>=20 >>> Rich >>=20 >>> _______________________________________________ >>> Rpm mailing list >>> Rpm@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/rpm >>=20 >=20 > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm