From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1AFF93B2A4 for ; Fri, 15 Oct 2021 11:10:14 -0400 (EDT) Received: by mail-qt1-x834.google.com with SMTP id g17so800991qtk.8 for ; Fri, 15 Oct 2021 08:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AgIe7qQEVk4Ej7SkVr6pjVZs43nIQviAM69X0X4U6ts=; b=G2Ix2RZlldL9tGls+Je1qb4u01AG24de7g6y5sbXek/UQP1pl9xy2nbSgswV2blU+/ 8aAbBzAEHyGn5YEHTg/dn62/T9nW1arFEox9KnK5ILhZC4PBsKQ9cxKV+Y6YSkGzCP4M wmL4yQh5h6a55BAknGrYXvgraQa5q26mD601+z22g7p2DmppRgs1j989vHyfJCzk5aia Erw+CRJCDt4uP9/RuEtEtCQCV7JU9XLYG00qRKo4VYtzt1puoj16P/JqOmYImXWp4Pm7 SENr9EQvIE8WhpaDY6LhQ5kB20XEWxKi/K1y72K07i38NXgppGlVHSIU5fC2RUcB6uQo QUVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AgIe7qQEVk4Ej7SkVr6pjVZs43nIQviAM69X0X4U6ts=; b=XnDRG3IVztzIx+jt9IzEoGibtwUDy1LyqbGF4ud9prEt2N9i2wmAAt/nBDU/dR2TtL +CccoqfMxs7qE8g/LiOrbf6nJAlQxCjVCNIsCnJDa/1TFK4kPCBAvKb2TlYFrsZzkAXt jyTbo8C/SwMacPC/HpgTVt2BFgpeSVT9M7dLmMNP8uj829viGOmcdcZhOBydJTse25j+ kAI92LFSP3pD0fBZnojkuNgEATjsVkPyAIGwv5iqIdRqKicrce8F96pZcIvFoR2wjoVC TCySHEAIsKtcQ5vYTi8sOxcdbK6QyFQ4aceSiw0gyV38nTXObtZhWosZlgAHQhAnbxWY 4XnA== X-Gm-Message-State: AOAM531OCpwD7zG2w2yKmqDfbUGUT+BSJUY5LiK1LPoe/ykPwJSUmj5f bc/i/igbhyiABp7qajr/e/I= X-Google-Smtp-Source: ABdhPJwyBOhf9pHtGioV4VwO4wa6xlgE6fAkVNKq9Li3nf25P7vE0eE52dOy1eLZQmVJwpy9aikzHg== X-Received: by 2002:ac8:7d4c:: with SMTP id h12mr11135931qtb.90.1634310613485; Fri, 15 Oct 2021 08:10:13 -0700 (PDT) Received: from richs-mbp-pro.lan ([198.55.239.186]) by smtp.gmail.com with ESMTPSA id a13sm2875679qtn.4.2021.10.15.08.10.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Oct 2021 08:10:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Rich Brown In-Reply-To: Date: Fri, 15 Oct 2021 11:10:12 -0400 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: Christoph Paasch X-Mailer: Apple Mail (2.3608.120.23.2.7) 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 15:10:14 -0000 > 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. 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 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.=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. 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 >=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