From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A85983B29E for ; Wed, 20 Oct 2021 14:30:30 -0400 (EDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 19KIJ0IW024310; Wed, 20 Oct 2021 11:30:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=wnhcuCulJoQ3iVeeBlC40SRtgXPw14p+B8qxopesS+A=; b=FbRSpw8kvzOKmhLHwitp8L9CVI9ZYcDTmH/ih5lFDHdQ3iUi1J75p4gjZsG/Z1Pq7Dij UF2Tiuv8TPRAuKv6BbXbnG9DgUPLDzqjevgsWWw99lES+h3yJ7c0cP3Qe+I90MzOd8Sj nZgcIyrVJghVt2jPkzTpTZVpgIqUStEpCi141H3KBlKlKOsS/t5IpfrdkZ2f6mt7Qzej jntp2RiTffEL7k477j90WJ0h7PkuF2usFIM4umn8e+TL7v22yGgKMwThhmxeXtdUzprV K+cOzNMti3z5ZaarJ5WdSbDXG/jflvsN0kxPJVcTxZPo0Sf15dPJTlgTBlMlt8kOQ4JE XA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3bqwd4w83t-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Oct 2021 11:30:29 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R1A00KFDGQS54B0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 20 Oct 2021 11:30:28 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1A00P00GJMFI00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 20 Oct 2021 11:30:28 -0700 (PDT) X-Va-A: X-Va-T-CD: 206c6d8179461ac5cfede4250501cb29 X-Va-E-CD: e5fcb99dfaa3d438d88c8d566ac15812 X-Va-R-CD: 1f7d9b5a682a61669d687c9c4835ed84 X-Va-CD: 0 X-Va-ID: c655e7c1-1aff-4b49-b9ed-b1493fb8427c X-V-A: X-V-T-CD: 206c6d8179461ac5cfede4250501cb29 X-V-E-CD: e5fcb99dfaa3d438d88c8d566ac15812 X-V-R-CD: 1f7d9b5a682a61669d687c9c4835ed84 X-V-CD: 0 X-V-ID: 0da6993f-3016-4a28-be1b-0f08b6303640 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_06:2021-10-20, 2021-10-20 signatures=0 Received: from smtpclient.apple ([17.192.155.152]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1A00CCZGQSD400@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 20 Oct 2021 11:30:28 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Christoph Paasch In-reply-to: Date: Wed, 20 Oct 2021 11:30:27 -0700 Cc: Randall Meyer , 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.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-10-20_06:2021-10-20, 2021-10-20 signatures=0 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: Wed, 20 Oct 2021 18:30:30 -0000 > On Oct 15, 2021, at 8:10 AM, Rich Brown = 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 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 >=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