search

drwetter / testssl.sh

Testing TLS/SSL encryption anywhere on any port
https://testssl.sh
GNU General Public License v2.0
7.91k stars 1.02k forks source link

Rating / compliance template #1108

Open drwetter opened 6 years ago

drwetter commented 6 years ago

This is first just a dump of my thoughts which came up after some discussion with David. Feedback is appreciated!

As of now testssl.sh has a rating which is more or less best practice from the perspective of a security consultant/researcher/... . So far so good.

Things may differ if one needs to check against a specific standards like SSLlabs or official ones like NIST (https://csrc.nist.gov/publications/sp800, see also #333) or from German BSI (https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index_htm.html) or any other government or other public standard.

If one wants to check a run of testssl.sh now against any standard, a manual comparison of the results against an own rating doesn't scale beyond a few systems. Logical consequence: Thus a rating template would be great which can be applied e.g. with a switch --template=<awesomeratingtemplate>

For the code it means the current flow has to change. After getting a raw result from the server side, processing it and before pr(ln)_svrty_<severity> and fileout "$jsonID" <severity> is being printed out, a template needs to be applied and based on that the output would then need to be generated.

This seems related to #1085 but goes IMO further as the the "Expectation profiles". They probably can live with the current testssl.sh rating standard and just output the deviation.

drwetter commented 6 years ago

PCI DSS would maybe be another standard to check against

definity commented 3 years ago

Do you have an outline or thoughts on what the structure of the template would look like?

drwetter commented 3 years ago

You don't mean format, right? (For that I believe the easiest to parse would be CSV)

I haven't made my mind up but here is a quick shot for discussion:

<identifier_section>, <identifier_test_in_section>, <expected_value>

The identifier maybe could be a single one like <ID_protocol_TLS10>, <ID_vulnerability_ticketbleed>

Things get more complicated if one wants to have more than a binary result, i.e. a distinction between passed , any value better than passed or totally broken

When people want check differences against previous scans I would rather not use this but a diffed scan (see other issues)

Opinions?

huornlmj commented 1 year ago

+1 indeed (in relation to #2245 )