UX and bugfix for reporting with advice to query censys.io

[polarathene]

Did you check the documentation in ~/doc/ or, if it is a different problem: Did you google for it?

Yes the official docs in this repo briefly touch on it:

Please note that if you use the same RSA certificate elsewhere you might be vulnerable too. testssl.sh doesn't check for this but provides a helpful link @ censys.io which provides this service.

Which is still a bit vague regarding where the link came from.

what exactly was happening, output is needed

Report outputs a URL like so:

 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=52B60CAD53077F1D7D77F43D1FCF4C654172DBA0953E7E6D6CC723C829259A31 could help you to find out

It's not immediately clear from the description what "could help you find out" meant, especially when that URL results in:

WARNING: Your search did not return any results.

Followed by a bunch of other information below it.

I vaguely recall seeing censys.io mentioned elsewhere for looking up CT logs, as this certificate being tested is private and not issued from a public CA I was confused about the URL existing, thinking it was sourced from the certificate, not generated as a search query ("https://censys.io/ipv4?q=$cert_fingerprint_sha2" in the script).

So now how the value is sourced is clear.

what did you expect instead?

Perhaps this would be more helpful?:

 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           You can check for servers discovered using this certificate by querying it's fingerprint at: https://censys.io/certificates?q=52B60CAD53077F1D7D77F43D1FCF4C654172DBA0953E7E6D6CC723C829259A31

Additionally, as I've corrected in the suggestion above, the wrong censys.io endpoint was being used (ipv4 instead of certificates). Thus the URL would always fail to lookup results regardless.

[drwetter]

Well, the point is to provide a means to lookup where a certificate is being used. So

https://censys.io/ipv4?q=57652487DF0CAAB3CF9C517DC7C03CC23C6E9B89344289CCD56D72168847BA3E

is helpful whereas

https://censys.io/certificates?q=57652487DF0CAAB3CF9C517DC7C03CC23C6E9B89344289CCD56D72168847BA3E

is not.

For the descriptive text: of course that can be improved. But your suggestion is longer and I felt mine was already too long. In fact I just thought about shortening it.

Of course the URL is empty/has a 404 if the host is not reachable. There are no good means to suppress the lookup when e.g. port 443 is not exposed in the BBI. That has to be left to the user.

[polarathene]

Well, the point is to provide a means to lookup where a certificate is being used. So

https://censys.io/ipv4?q=57652487DF0CAAB3CF9C517DC7C03CC23C6E9B89344289CCD56D72168847BA3E

is helpful whereas

https://censys.io/certificates?q=57652487DF0CAAB3CF9C517DC7C03CC23C6E9B89344289CCD56D72168847BA3E

is not.

That's a tricky one, when I brought this up, I had done an ipv4 search on a public site modworkshop.net and providing the certificate shows no results: https://censys.io/ipv4?q=259E9794A2F2204E45EBA76A47325BD3DCC94DE788C81B4DDB22259871368564

However, I can lookup the certificate directly: https://censys.io/certificates?q=259E9794A2F2204E45EBA76A47325BD3DCC94DE788C81B4DDB22259871368564

You can do a less than obvious ipv4 hosts lookup from the 2nd link via the "explore" button/menu. Which likewise returns no results. I don't know why that is, but generally the hosts should all be IPs that the registered SANs in the certificate point to, you're not likely for example to find the certificate you provided to be served from somewhere that DNS for those domains aren't setup for as that'd fail to establish a secure connection? (although it's nice to see a list of hosts when it works)

Personally, if a URL is going to be provided like this, it'd be a bit more useful to provide a URL that's more likely to have a result?

---

For the descriptive text: of course that can be improved. But your suggestion is longer and I felt mine was already too long. In fact I just thought about shortening it.

Sure! But for the docs where it was also a bit vague, perhaps the additional verbosity for clarity would be helpful? Would you like me to open a PR for it?

If you'd like a shorter variant, perhaps remove the trailing text after the URL, and just prepend the URL with "Query for IPv4 hosts:"? Or avoid the generated URL entirely, and just mention to use the cert sha-256 fingerprint at censys.io?

---

Of course the URL is empty/has a 404 if the host is not reachable.

It doesn't 404, it redirects to a help page on how to use censys.io (without really saying what it's about, so it ends up being a little confusing what you're looking at). Sometimes I see a orange box tip warning me that there was no results. You also can only view 10 queries within 24 hours without a registered account.

I wasn't sure initially why the URL was being provided or how it was generating that URL (not realizing it was the SHA-256 fingerprint of my cert), I was thinking that maybe I somehow leaked my cert registration to a CT log that testssl.sh had discovered.

There are no good means to suppress the lookup when e.g. port 443 is not exposed in the BBI. That has to be left to the user.

Not sure what you're referring to about suppressing a lookup when port 443 isn't exposed or what BBI is (I tried googling a few queries but didn't seem to find anything relevant).

Was this referring to visiting the censys.io URL? My cert was generated, served and tested entirely locally with my docker-compose test environment. It ran on an isolated network. The host machine however where I view the results reported from testssl.sh has public internet access where I view the URL provided just fine.

I wasn't complaining about the URL not being reachable, but that I misunderstood it's legitimacy (it wasn't some reference/resource, it didn't have anything to do with an information leak, it was just a dynamically generated query where the contents was a fingerprint, and the URL may potentially have some results but in my case obviously did not).

---

TL;DR

• ipv4 query can still have no results, even for hosts on the public internet that have a result for certificates query.
• I was confused what the URL was about from the vague report and doc descriptions and the non-optimal "no results" page (as a first experience from visiting censys.io), rather than a page with results that would have made much more sense (a 2nd test on a public website also gave the non-optimal experience, adding to the confusion).
• There was no 404 with the censys.io URL, port 443 was accessible.
• Main gripe from a UX viewpoint and a user who was not familiar with how testssl.sh was trying to help me, the report text or docs were too vague when paired with a censys.io URL that finds no results.
• I am happy to attempt a PR if you like on either the report text or README doc?