search

drwetter / testssl.sh

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

Rating #100

Closed drwetter closed 1 year ago

drwetter commented 9 years ago

can be done with return values of functions, global vars

drwetter commented 9 years ago

c&p'ed from #31:

For the rating I guess the best is a global variable. It starts with hundred (equals 100%) and then each step comes a penalty. So far so good. The difficult part is a fair rating. If you look at SSLlabs: they have a 10 page PDF for this. So one needs to put "some" thoughts into it. And: it's changing over time as new bugs hit the streets or it becomes public e.g. that EC curve ABC is compromised or whatever.

ajbouh commented 9 years ago

@drwetter,

Have you seen sslrate over at https://github.com/einaros/sslrate/blob/master/sslrate.py? They claim to have implemented something like SSLlabs ratings for sslyze xml output.

Beyond just a rating, they include a check against known bad certificates in openssl-blacklist. I did the (admittedly minimal) work to unpack openssl-blacklist to be usable without debian/ubuntu package tools. If it'd be useful, I can contribute that unpacking logic back to this project somehow.

Ideally I'd like to have a strict set of requirements that must be met, as a part of our in-house continuous integration tests. Most of testssl.sh's tests are perfect for this, except for the OCSP ones, as they appear to assume that an external/third party server would be accessible during testing.

drwetter commented 9 years ago

Hi @ajbouh

Am 07/22/2015 um 08:59 PM schrieb ajbouh:

@drwetter https://github.com/drwetter,

Have you seen sslrate over at https://github.com/einaros/sslrate/blob/master/sslrate.py? They claim to have implemented something like SSLlabs ratings for sslyze xml output.

ok, thx. Reads interesting.

Beyond just a rating, they include a check against known bad certificates in openssl-blacklist. I did the (admittedly minimal) work to unpack openssl-blacklist to be usable without debian/ubuntu package tools. If it'd be useful, I can contribute that unpacking logic back to this project somehow.

Thx for the reminder. Comment:

yeah, well. It's certainly a "nice to have", so I opened an issue (#146). But as that was ages ago and I think the likeliness of still detecting broken keys/certificates is incredibly small, it's just a matter of completing this project.

If you feel like doing this in bash, pls go ahead.

Ideally I'd like to have a strict set of requirements that /must/ be met, as a part of our in-house continuous integration tests. Most of testssl.sh's tests are perfect for this, except for the OCSP ones, as they appear to assume that an external/third party server would be accessible during testing.

@ajbouh, if you can use a proxy, it should work (just checked). If you cannot use a proxy and testssl.sh e.g. stalls or there's another problem please file a bug with a detailed description.

Thx for all your thoughts!

Cheers, Dirk

hickford commented 7 years ago

(I was about to post this separately. but found this bug)

Hi. Have you thought about scoring servers with a grade A to F? Grades are great because anyone can compare them, without technical knowledge.

The SSL Labs server test gives a colour-coded grade A to F, with a summary of problems at the top. For example https://www.ssllabs.com/ssltest/analyze.html?d=personal.natwest.com

  • This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
  • The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.

I'm working on a 'name and shame' site for ISPs in my country, which have a poor standard of configuration on their email servers (vulnerable to POODLE, and so on). It's not possible to use SSL Labs to test email servers because it only allows tests port 443.

drwetter commented 7 years ago

@hickford : thanks for the flowers ;-)

The primary question is not how (A to F / some percentage / whatever) ... the question is who's doing it and when :-) And: it is not that easy to get it right (see discussions sometimes @ SSLlabs). I think starting with a baseline should be the right thing.

Yes, actually as the primary focus in the past has been on TLS and HTTP: it's in reasonably good shape. For all other protocols it's worse. For a few talks I gave I have been citing this paper: TLS in the Wild: An Internet-wide Analysis of TLS-based Protocols for Electronic Communication (http://www.internetsociety.org/events/ndss-symposium-2016/ndss-2016-programme#session1), PDF @ https://www.internetsociety.org/sites/default/files/blogs-media/tls-wild-internet-wide-analysis-tls-based-protocols-electronic-communication.pdf/ . See table 3 @ p7

drwetter commented 6 years ago

see also #327 for machine-readable result

drwetter commented 6 years ago

How SSLlabs is doing the rating is actually open, see e.g. https://community.qualys.com/docs/DOC-6321-ssl-labs-grading-2018.

There could be other rating methods though and if you ask myself I would rather do some things differently and I would like to have the freedom to do so. But to get a rating done properly is hard if you follow discussions @ SSLlabs. So taking that as a first step isn't maybe the worst idea. ;-)

Looking at it from the standpoint as an architect: rating could be pluggable as a module. So as an idea if a user e.g. wants SSLlabs rating she/he runs --rating ssllabs and testssl.sh picks the module up from e.g. ~/include/ratings/ssllabs.inc . If somebody else comes up with a different rating idea, it can be placed in the same directory.

There are "only" two difficulties: a) If rating is a module it still needs information from the main code (hooks?) or at least parse the result somehow b) A more a practical matter: who does that :-) After 3.0 my preference was to speed up testing and reorganize

BryanQuigley commented 5 years ago

I'd like to do a similar site to you @hickford (except with banks/government sites) . Would love to see any code if you've already got started.

I think it's cleaner to just have testssl export json and then have a separate script provide a grade/numerical score. Thoughts?

drwetter commented 5 years ago

I think it's cleaner to just have testssl export json and then have a separate script provide a grade/numerical score. Thoughts?

I would say it's easier to implement, not necessarily cleaner -- whatever you mean by that ;-) Post processing is also not that user friendly,