What does HackerNews think of testssl.sh?
Testing TLS/SSL encryption anywhere on any port
Some headers may be missing [3].
Follow the links from Qualys and SecurityHeaders to get more information on how to remediate the findings. It might also not hurt to open a ticket with Cloudflare to see what else is going on here if you have a paid account.
[1] - https://www.ssllabs.com/ssltest/analyze.html?d=www.teamkenne...
[2] - https://github.com/drwetter/testssl.sh
[3] - https://securityheaders.com/?q=https%3A%2F%2Fwww.teamkennedy...
Use Qualys [1] to test the domain in question to link here or use the testssl.sh [2] code only depends on openssl and bash to test from your machine. If one of the many self hosted nodes, see if you can find a way to reach out to them and kindly suggest they set up certbot or a cron job to renew their certs.
Joinpeertube.org looks good to me [3] so I assume you find a self-hosted node that needs some attention.
If someone here knows of a way to query a list of all the self-hosted domains joined into peertube perhaps we could run testssl.sh against all of them to generate reports. I am not opposed to doing this if someone knows how I can get a list of all the domains using curl.
[1] - https://www.ssllabs.com/ssltest/
[2] - https://github.com/drwetter/testssl.sh
[3] - https://www.ssllabs.com/ssltest/analyze.html?d=joinpeertube....
Have you tried multiple browsers and is your OS CA store up to date?
[1] - https://www.ssllabs.com/ssltest/analyze.html?d=www.gov.uk
The only serious warning I see is "Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat (6 attempts)" They otherwise get an "A+".
Perhaps they have wan accelerators or anycast proxies with bad certs that are region specific?
[1] - https://github.com/drwetter/testssl.sh [depends on bash and openssl]
If hardening SSH it may be safest to first harden the SSH client and ensure one can still connect. Then harden the ssh daemon of a local machine using the same version of openssh used on ones servers to minimize the risk of locking one out of their own machine and having to use a rescue console or ILO. This may be counter-intuitive but going through the hardening process significantly speeds up SSH handshake time which may be most useful to those using Ansible.
[1] - https://www.ssh-audit.com/
[1] - https://www.ssllabs.com/ssltest/
[2] - https://dev.ssllabs.com/ssltest/
[3] - https://github.com/drwetter/testssl.sh
[4] - https://securityheaders.com/
[5] - https://urlscan.io/
[6] - https://bgp.he.net/
[7] - https://www.robtex.com/
[8] - https://www.whatsmydns.net/
[9] - https://www.virustotal.com/old-browsers/
[10] - https://www.whoisds.com/
[11] - https://ssl-config.mozilla.org/
[12] - https://crt.sh/
[13] - https://www.thousandeyes.com/outages/ [commercial site but priceless in my opinion]
[14] - https://downdetector.com/
[15] - https://ednscomp.isc.org/ednscomp?zone=ycombinator.com
[16] - https://www.shodan.io/
[17] - https://validator.w3.org/
In the same spirit of minimal and light weight there is also testssh.sh [2] for testing TLS on HTTPS/SMTPS servers that also depends on bash and openssl.
[1a] - https://www.ssllabs.com/ssltest/
[1] - https://serverfault.com/
The only problem I have run into with various government orgs is the lack of knowledge around implementing intermediate certificates. They will often try to talk people into installing their certs rather than installing intermediate certs correctly. I always point them to testssl.sh [1]
HSTS requires the site is HTTPS with a valid cert. If you own all .io, you can use LetsEncrypt to get that for free. They now even support Wildcard Certs! :-) That said, you would have to choose your targets carefully and/or load balance your requests to LetsEncrypt. There is a rate limit. There are browser plugins that can tell you if a cert just changed, assuming you have been to that site prior.
Then there is Public Key Pinning. This would be great, but I suspect the number of big companies implementing this are low. I don't have numbers, but you can test your favorite sites in Qualys[1] or using testssl.sh[2] that only depends on openssl and bash.
You could proxy all requests to the real root servers for .io and only become authoritative for the ones you wish to target.
Given the small number of zones, I think a modest server could keep up, or you could balance the load on a bunch of VM's. It may take a while for anyone to notice. I am curious actually, how many fellow geeks have nagios/sensu alerts that would tell them if the root server IP's changed.
All of this said, there are BGP attacks you can do that accomplish the same thing for any TLD and the IP's wouldn't even have to change. Only more advanced monitoring tools that keep an eye on route path might notice, but probably would not alert anyone.
[1] https://www.ssllabs.com/ssltest/index.html [2] https://github.com/drwetter/testssl.sh
[1] https://github.com/drwetter/testssl.sh
It only depends on OpenSSL and bash. I find it very useful for reviewing our systems before they go live.