SSL/TSL tests (ssllabs.com or the likes) #17

Open
opened 2018-11-20 17:06:03 +01:00 by AndyHee · 8 comments
AndyHee commented 2018-11-20 17:06:03 +01:00 (Migrated from github.com)

SSL security and reliably varies considerably depending on a range of factors.

The green HTTPS button on its own may give the impression --to non-expert users-- that a particular server is "safe".

Hyperlinking this button would be enhancement that not only gives convenient access to a specific test site, but may also raise awareness of issues surrounding the HTTPS protocol.

https://www.ssllabs.com/ssltest/analyze.html?d=friendica.hubup.pro&hideResults=on

SSL security and reliably varies considerably depending on a range of factors. The green HTTPS button on its own may give the impression --to non-expert users-- that a particular server is "safe". Hyperlinking this button would be enhancement that not only gives convenient access to a specific test site, but may also raise awareness of issues surrounding the HTTPS protocol. https://www.ssllabs.com/ssltest/analyze.html?d=friendica.hubup.pro&hideResults=on
MrPetovan commented 2018-11-20 17:19:45 +01:00 (Migrated from github.com)

The green HTTPS label displays the result of self-signed, expired and otherwise invalid certificate checks so it isn't just a check on the URL.

Does SSL Labs provides an API for background SSL checks?

The green HTTPS label displays the result of self-signed, expired and otherwise invalid certificate checks so it isn't just a check on the URL. Does SSL Labs provides an API for background SSL checks?
AndyHee commented 2018-11-21 04:23:53 +01:00 (Migrated from github.com)

Yes, there is: https://www.ssllabs.com/projects/ssllabs-apis/

But it's not really meant for testing "other" people's severs.

I've to read the terms and condition in more detail. If we want to got down this road, than I think we would need permission of the server owner. Possibly via an opt-in agreement via the admin panel when setting the directory URL.

Yes, there is: https://www.ssllabs.com/projects/ssllabs-apis/ But it's not really meant for testing "other" people's severs. I've to read the terms and condition in more detail. If we want to got down this road, than I think we would need permission of the server owner. Possibly via an opt-in agreement via the admin panel when setting the directory URL.
AndyHee commented 2018-11-24 03:17:39 +01:00 (Migrated from github.com)

Background

OK, I've read the terms and condition and it seems generally possible to use their APIs for Friendica.
We'd need to follow their requirements in terms of user consent and acknowledging SSL Labs though. The license of the command-line client for their APIs is: Apache License 2.0.

In addition, SSL Labs (a non-commercial research project) and Qualys (the related US-based company) appear sound on the surface in terms of ethical issues.

Conceptual questions

We should consider how such SSL/TSL tests will be conducted in the Friendica network. The two obvious options are:

  • A) Centrally at directory level, directories are testing all known nodes and display their results,
    or
  • B) De-centrally at sever level, each node testing itself (with for instance an enabled plugin) and submitting the result to their directory.

Both methods have advantages and disadvantages; both are within the scope of the T&C.

Arising questions for deliberation should be addressed in terms of reliability, robustness, technical realization, and others.

### Background OK, I've read the terms and condition and it seems generally possible to use their APIs for Friendica. We'd need to follow their requirements in terms of user consent and acknowledging SSL Labs though. The license of the command-line client for their APIs is: Apache License 2.0. In addition, SSL Labs (a non-commercial research project) and Qualys (the related US-based company) appear sound on the surface in terms of ethical issues. ### Conceptual questions We should consider how such SSL/TSL tests will be conducted in the Friendica network. The two obvious options are: - **A)** Centrally at directory level, directories are testing all known nodes and display their results, or - **B)** De-centrally at sever level, each node testing itself (with for instance an enabled plugin) and submitting the result to their directory. Both methods have advantages and disadvantages; both are within the scope of the T&C. Arising questions for deliberation should be addressed in terms of reliability, robustness, technical realization, and others.
MrPetovan commented 2018-11-24 14:57:25 +01:00 (Migrated from github.com)

I think it should be an optional test at the directory-level. Does that mean we need to ask every single probed server for their consent?

I think it should be an optional test at the directory-level. Does that mean we need to ask every single probed server for their consent?
AndyHee commented 2018-11-25 16:18:50 +01:00 (Migrated from github.com)

Test mode

an optional test at the directory-level

OK, I'm indifferent on this point, and only want to hear specific rationales for either options. If we don't have any other input, lets go for the directory-level option.

Would you like me to ask at the developers forum, if people would like to comment on this point?

Opting-in by submitting to directory

Does that mean we need to ask every single probed server for their consent?

I'd say it will be sufficient if we state in the admin panel that when the node submits to the directory that a SSL/TSL test might be conducted via SSL labs and what certain data will be made public.

Opting out while still submitting to directory

We may also want to give an opt-out possibility for those who want to submit to a directory but request to be excluded from this test.

Directory operators should also able to disable this test entirely via the settings, if they choose to do so.

Scope of Displayed Results

Publishing 5-pages detailed test results for each server would certainly be disproportional and may well not within the remit of the above consent agreement.

So we would presumably only publish the overall letter grade, e.g. A+, A... This I assume would be fine with a clear notice in the directory section in the admin panel. Any other data from the test result should be transitory and hidden in the directory, if it needs to be obtained in the first place.

Nodes with Legacy Code

Here we need to make a decision that only nodes with the right admin panel (i.e. with agreement button) will be tested.

I think, to be on the cautious site, it would be better not to test nodes where the admin cannot see this agreement in the panel, because they run legacy code.

Acknowledgement

If we display the result we must acknowledge SSL Labs in a specifically worded way. It's a short sentence.

I think, this could be added to the footer and possibly also something like a hoover card over the result.

#### Test mode > an optional test at the directory-level OK, I'm indifferent on this point, and only want to hear specific rationales for either options. If we don't have any other input, lets go for the _directory-level option_. Would you like me to ask at the developers forum, if people would like to comment on this point? #### Consent ##### Opting-in by submitting to directory > Does that mean we need to ask every single probed server for their consent? I'd say it will be sufficient if we state in the _admin panel_ that when the node submits to the directory that a SSL/TSL test might be conducted via SSL labs and what certain data will be made public. ##### Opting out while still submitting to directory We may also want to give an opt-out possibility for those who want to submit to a directory but request to be excluded from this test. Directory operators should also able to disable this test entirely via the settings, if they choose to do so. ##### Scope of Displayed Results Publishing 5-pages detailed test results for each server would certainly be disproportional and may well _not_ within the remit of the above consent agreement. So we would presumably only publish the _overall letter grade_, e.g. A+, A... This I assume would be fine with a clear notice in the directory section in the admin panel. Any other data from the test result should be transitory and hidden in the directory, if it needs to be obtained in the first place. ##### Nodes with Legacy Code Here we need to make a decision that only nodes with the right admin panel (i.e. with agreement button) will be tested. I think, to be on the cautious site, it would be better not to test nodes where the admin cannot see this agreement in the panel, because they run legacy code. #### Acknowledgement If we display the result we must acknowledge SSL Labs in a specifically worded way. It's a short sentence. I think, this could be added to the footer and possibly also something like a hoover card over the result.
MrPetovan commented 2018-11-27 03:22:02 +01:00 (Migrated from github.com)

Thanks for the detailed rundown. All this makes me wonder about the compared benefits to the cost and scope of enabling SSL Labs tests. Especially if we need the explicit consent of each node on the new version onwards.

Thanks for the detailed rundown. All this makes me wonder about the compared benefits to the cost and scope of enabling SSL Labs tests. Especially if we need the explicit consent of each node on the new version onwards.
AndyHee commented 2018-11-27 04:04:05 +01:00 (Migrated from github.com)

The alternative would be to contact them at SSL Labs and ask them to grant relaxed licensing terms to us as 'infrastructure providers'. They make provisions for content delivery networks and others.

The alternative would be to contact them at SSL Labs and ask them to grant relaxed licensing terms to us as 'infrastructure providers'. They make provisions for content delivery networks and others.
AndyHee commented 2018-11-27 04:18:48 +01:00 (Migrated from github.com)

the cost and scope of enabling SSL Labs tests

The possible version of text in the admin panel will be rather short; just saying that a SSL/TSL test may be done by SSL Labs if you submit to the directory and your grade will be publicly displayed.

Plus the opt-out switch if deemed necessary and the tracking in the DB what server will be tested.

If we dispense with the opt-out switch and make public announcements that at some point everyone who submits to a directory will be assumed to give implicit consent (by continuing to submit) , than there will be no great opportunity costs.

This is a less cautious reading of their T&C but certainly also possible.

> the cost and scope of enabling SSL Labs tests The possible version of text in the admin panel will be rather short; just saying that a SSL/TSL test may be done by SSL Labs if you submit to the directory and your grade will be publicly displayed. Plus the opt-out switch if deemed necessary and the tracking in the DB what server will be tested. If we dispense with the opt-out switch and make _public announcements_ that at some point everyone who submits to a directory will be assumed to give _implicit consent_ (by continuing to submit) , than there will be no great opportunity costs. This is a less cautious reading of their T&C but certainly also possible.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: friendica/friendica-directory#17
No description provided.