SSL/TSL tests (ssllabs.com or the likes) #17
Labels
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: friendica/friendica-directory#17
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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?
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.
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:
or
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.
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?
Test mode
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
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.
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.
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 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.