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

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

[Rich Brown]

I was about to send out the following invitation on the OpenWrt Forum (forum.openwrt.org) when I saw the following in https://github.com/network-quality/server

> NOTE: The networkQuality CLI tool will only connect to a server presenting a valid SSL certificiate [sic]. If you are using a custom CA, ensure the CA is trusted by the system.

This constraint dramatically complicates the rollout of networkQuality servers. In fact, it makes it impractical to run on a home router without a lot of farbling around with Let's Encrypt, etc.

Would the use of a self-signed certificate invalidate the RPM readings? If not, could this constraint be relaxed? Thanks.

Rich


======= Proposed Invitation to OpenWrt developers =========

Subject: Seeking RPM Server package for OpenWrt

Apple has designed an RPM Tool for macOS 12 and iOS 15 that measures the "responsiveness" of your network connection. (Responsiveness is the inverse of latency - the lower the latency, the higher the responsiveness.) 

The RPM Tool counts the number of round-trips per minute (RPM) while the line is fully loaded. A higher number (1,800 RPM and above) is excellent (that's 30 round-trips per second). Below 1,000 RPM is pretty bad. You can read more about it at:

https://www.bufferbloat.net/projects/bloat/wiki/toward_a_consumer_responsiveness_metric#a-proposed-metric-rpm 

Apple has servers that let you test the responsiveness from your device to their network infrastructure. But the RPM test can work locally, as well. It's often the case that local conditions, such as poorly-performing or weak Wi-Fi, dominate the connection. It's important to know whether it's your Wi-Fi, your router, or your ISP (and their connection to the rest of the world) that's causing problems.

Your mission, should you choose to accept it, is to implement the server end of the RPM tooling. It would likely be an OpenWrt package, and would listen to requests from the client on your phone/laptop so that it could measure responsiveness from the device to the router.

There's a full protocol spec in Section 5 of: https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-00#section-5

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

[Randall Meyer]

> On Oct 13, 2021, at 12:18 PM, Rich Brown via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> I was about to send out the following invitation on the OpenWrt Forum (forum.openwrt.org) when I saw the following in https://github.com/network-quality/server
> 
>> NOTE: The networkQuality CLI tool will only connect to a server presenting a valid SSL certificiate [sic]. If you are using a custom CA, ensure the CA is trusted by the system.
> 
> This constraint dramatically complicates the rollout of networkQuality servers. In fact, it makes it impractical to run on a home router without a lot of farbling around with Let's Encrypt, etc.
> 
> Would the use of a self-signed certificate invalidate the RPM readings? If not, could this constraint be relaxed? Thanks.
> 

We could add a “—insecure/-k” switch as a feature enhancement to the CLI.

As for the performance difference between self signed and CA-issued certs, that’s something we have not explored.

-Randall

(And fixed the spelling error. Thanks!)



> Rich
> 
> 
> ======= Proposed Invitation to OpenWrt developers =========
> 
> Subject: Seeking RPM Server package for OpenWrt
> 
> Apple has designed an RPM Tool for macOS 12 and iOS 15 that measures the "responsiveness" of your network connection. (Responsiveness is the inverse of latency - the lower the latency, the higher the responsiveness.) 
> 
> The RPM Tool counts the number of round-trips per minute (RPM) while the line is fully loaded. A higher number (1,800 RPM and above) is excellent (that's 30 round-trips per second). Below 1,000 RPM is pretty bad. You can read more about it at:
> 
> https://www.bufferbloat.net/projects/bloat/wiki/toward_a_consumer_responsiveness_metric#a-proposed-metric-rpm 
> 
> Apple has servers that let you test the responsiveness from your device to their network infrastructure. But the RPM test can work locally, as well. It's often the case that local conditions, such as poorly-performing or weak Wi-Fi, dominate the connection. It's important to know whether it's your Wi-Fi, your router, or your ISP (and their connection to the rest of the world) that's causing problems.
> 
> Your mission, should you choose to accept it, is to implement the server end of the RPM tooling. It would likely be an OpenWrt package, and would listen to requests from the client on your phone/laptop so that it could measure responsiveness from the device to the router.
> 
> There's a full protocol spec in Section 5 of: https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-00#section-5
> 
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

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

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]


> On Oct 13, 2021, at 3:45 PM, Randall Meyer <rrm@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. 

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

[-- Attachment #2: Type: text/html, Size: 1784 bytes --]

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

[Christoph Paasch]

On 10/13/21 - 17:57, Rich Brown via Rpm wrote:
> 
> > On Oct 13, 2021, at 3:45 PM, Randall Meyer <rrm@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.


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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

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

[Rich Brown]

> On Oct 14, 2021, at 4:27 PM, Christoph Paasch <cpaasch@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@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/rpm
> 

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

[Toke Høiland-Jørgensen]

Rich Brown via Rpm <rpm@lists.bufferbloat.net> writes:

>> On Oct 14, 2021, at 4:27 PM, Christoph Paasch <cpaasch@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@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.

FYI, I maintain luci-app-acme on OpenWrt which makes it quite easy to
get a letsencrypt certificate. Requires the router to have a public IP,
and you need a domain name, but once you have that it's pretty point and
click :)

Not universal, but maybe doable for someone who is likely to deploy an
RPM server?

-Toke

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

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]


> On Oct 15, 2021, at 12:38 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> FYI, I maintain luci-app-acme on OpenWrt which makes it quite easy to
> get a letsencrypt certificate. Requires the router to have a public IP,
> and you need a domain name, but once you have that it's pretty point and
> click :)

I love luci-app-acme, but... I want to be able to point the RPM client at 192.168.1.1 and blast my Wi-Fi to smithereens (or not, if I have a good driver :-)

Thanks.

Rich

[-- Attachment #2: Type: text/html, Size: 3882 bytes --]

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

[Jonathan Foulkes]

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. 

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 <rpm@lists.bufferbloat.net> wrote:
> 
> 
> 
>> On Oct 14, 2021, at 4:27 PM, Christoph Paasch <cpaasch@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@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/rpm
>> 
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

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

[Christoph Paasch]

> On Oct 15, 2021, at 8:10 AM, Rich Brown <richb.hanover@gmail.com> wrote:
> 
> 
> 
>> On Oct 14, 2021, at 4:27 PM, Christoph Paasch <cpaasch@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@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. 

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

> 
> - 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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/rpm

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

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

OK. I am convinced and satisfied by this outcome.

> On Oct 20, 2021, at 2:30 PM, Christoph Paasch <cpaasch@apple.com> wrote:
> 
>> - 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. 
> 
> 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".

- People using Apple's iOS client have no option (today) to specify a custom server. If one becomes available, I imagine it'll have a checkbox that says, "Accept insecure certificate"

- People using Apple's macOS client can use both -C and -k to accept the insecure certificate.

- People using homegrown RPM clients will use the client's options, presumably that match the Apple clients. 

Thanks again.

Rich

[-- Attachment #2: Type: text/html, Size: 3139 bytes --]

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

[Omer Shapira]

> On Oct 20, 2021, at 11:30 AM, Christoph Paasch via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> 
> 
>> On Oct 15, 2021, at 8:10 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>> 
>> 
>> 
>>> On Oct 14, 2021, at 4:27 PM, Christoph Paasch <cpaasch@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@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. 


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’m sure you know that HTTP2 is tightly couples with TLS 1.2. The point is that it’s 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 “it’s easy enough to stand up code to respond to HTTP” - 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’s unclear that the devices at the lowest price point will be able to implement the RPM server correctly, and I’d 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".
> 
> 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
> 
>> 
>> - 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.

I would make an argument that RPM server that’s 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. 

Back to the point of “making RPM metric available on the bottom price point devices” - 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:
>> 
>> 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 “not having a command line option to forgo validation of the server’s identity”.


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

Several… 

1. Apple’s stance on the user’s privacy is strong enough to avoid proliferation of insecure HTTP. Hence, the “trust everyone by default” behavior is unlikely to fly. This of course does not prevent “a homegrown client” to have different values.

2. Lack of SSL certificate is one of those “smells of poor implementation”, 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’s often best to minimize the surprise. In general, “forfeiting the right to know who’s the server we are talking to” 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’s been set by the ssh) seems the right thing to do.

>> 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@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/rpm
> 
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm

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

[Toke Høiland-Jørgensen]

Omer Shapira via Rpm <rpm@lists.bufferbloat.net> writes:

> 2. The notion that “it’s easy enough to stand up code to respond to
> HTTP” - 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.

I'll add another complication to this, at least for Linux: TCP Small
Queues (TSQ). If the server responding to the requests is the AP, TSQ
can do a quite good job of keeping those streams from saturating the
queues of the WiFi interface, meaning you won't expose any bloat that
may be hiding there. This varies between implementations, but it's quite
possible to have an AP that has no bufferbloat when running a test
against a server on the AP itself, but is severely bloated when
forwarding packets.

-Toke