From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 A308B3B29E for ; Wed, 20 Oct 2021 19:04:24 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 19KN3Dd6007162; Wed, 20 Oct 2021 16:04:23 -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=XNPpNWPqUXsE/0FlYsn4e5WqeKScdqJ3Y/RgkLy4PiI=; b=DwjTdCEAlcmDdgSIFBig1oSnu4/WPya4A2fOtbZ1LBAKihduvFmwoy7fJzjy8bVEvuSB /qR1vTMWkodmMIu+GC8bOcSxWdF4yYP/qvlgxvlx1PeWhIoo5j1i10v7pqqQuDC5TQIs 1AIjyWO+tekZ6xCX9ixhYIttZKmT3HDgJFkWpbj4/sJktcasKTiP8Q3ZghZjfyNP+QWt l2huNets8WWyMpb2kFp7h28+IzI5gHhurUfKmHfM6lZzyAXv5z0I5k1BP3FYFUWgzzPh bI25G+Q42LFjRwV1x4zZuyjaxoHXtdQED2UZfjBLjZ0sJ1134DfsGYk7ltxSxmIkEtY9 xA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3bqt8b42ag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Oct 2021 16:04:23 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) 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 <0R1A00X7CTFB9FI0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 20 Oct 2021 16:04:23 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R1A00F00TDQZ800@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 20 Oct 2021 16:04:23 -0700 (PDT) X-Va-A: X-Va-T-CD: fbf5e08602d1afefb72f28a058485772 X-Va-E-CD: 04e09fee63a94f7fda847c84bbfbdbdf X-Va-R-CD: 44e3f8a9c64ae935e486623ab8964520 X-Va-CD: 0 X-Va-ID: aa53acb3-a998-4b95-a0eb-a68e80255040 X-V-A: X-V-T-CD: fbf5e08602d1afefb72f28a058485772 X-V-E-CD: 04e09fee63a94f7fda847c84bbfbdbdf X-V-R-CD: 44e3f8a9c64ae935e486623ab8964520 X-V-CD: 0 X-V-ID: 03829bc6-607f-487a-8621-c29939b2c04f 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 (unknown [17.11.42.216]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R1A00NGETFAAB00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 20 Oct 2021 16:04:23 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 16.0 \(3696.80.2\)) From: Omer Shapira In-reply-to: Date: Wed, 20 Oct 2021 16:04:22 -0700 Cc: Rpm Content-transfer-encoding: quoted-printable Message-id: <4C9625A0-6276-4073-A43F-A57C22F268C6@apple.com> References: <6B7910A6-9157-40DD-8C50-FE42AEDB7797@apple.com> <8F8B59C1-9FB7-4B3E-9C15-14180721FEA8@gmail.com> To: Christoph Paasch , Rich Brown X-Mailer: Apple Mail (2.3696.80.2) 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 23:04:24 -0000 > On Oct 20, 2021, at 11:30 AM, Christoph Paasch via Rpm = wrote: >=20 >=20 >=20 >> 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 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=E2=80=99m sure you know that HTTP2 is tightly couples with TLS = 1.2. The point is that it=E2=80=99s 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 =E2=80=9Cit=E2=80=99s easy enough to stand up code to = respond to HTTP=E2=80=9D - 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=E2=80=99s unclear that the devices at the lowest = price point will be able to implement the RPM server correctly, and = I=E2=80=99d 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". >=20 > 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 :) >=20 >=20 > Christoph >=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. I would make an argument that RPM server that=E2=80=99s 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.=20 Back to the point of =E2=80=9Cmaking RPM metric available on the bottom = price point devices=E2=80=9D - 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: >>=20 >> 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 =E2=80=9Cnot having a command line option to = forgo validation of the server=E2=80=99s identity=E2=80=9D. >> - 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? Several=E2=80=A6=20 1. Apple=E2=80=99s stance on the user=E2=80=99s privacy is strong enough = to avoid proliferation of insecure HTTP. Hence, the =E2=80=9Ctrust = everyone by default=E2=80=9D behavior is unlikely to fly. This of course = does not prevent =E2=80=9Ca homegrown client=E2=80=9D to have different = values. 2. Lack of SSL certificate is one of those =E2=80=9Csmells of poor = implementation=E2=80=9D, 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=E2=80=99s often best to minimize the surprise. In general, = =E2=80=9Cforfeiting the right to know who=E2=80=99s the server we are = talking to=E2=80=9D 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=E2=80=99s been set by the ssh) seems the right thing to = do. >> 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 > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm