My weekend project.

* Tries to give all the information you need instead of a rating.

* Open source, so you can self host it.

* Does the entire certificate chain.

* Allows to paste a CRL/Cert

* Validates the certificate, chain, CRL and OCSP (of every cert in the chain)

* Has easy copy-pastable PEM versions of certs

* Ciphersuite enumeration as an option.

* Fast.

Thank you so much for this. Can I fork it to add the ability to accept an HTTP POST for the domain/hostname, and return the persistent results URL back to a webhook? (Slack integration)

I do have a JSON (plain text, readable json) output endpoint planned, but that will be GET as well. Pull requests are welcome though.

It also does custom ports and protocols, for example 8443, 465 (SMTP), 994/995(POP/IMAP) etc.

Custom ports and IPv6 support <3

This is pretty great (and you even managed to snag a short domain name)!

For those who are trying to use the command line (rather than a webapp), "sslscan" performs these checks from a simple CLI tool.

+1 to SSLScan. Last time I checked though, the Windows builds don't work/support the XML output option. Automating this last year involved capturing STDOUT and regexing...

Thanks for doing this, awesome job. May I request IPv6 support?

As far as I can tell the website is accessible via IPv6 and you can run checks on IPv6 only servers. What is missing?

If your hostname is dual stacked it only checks for ipv4 afaik.

Then shouldn't revocation be fixed?

Revocation is Hard. The problem is that the way certificates work is supposed to be asynchronous: You get a certificate from the CA, the client has the CA's public key, so you give the certificate to the client which can verify it without talking to the CA. This is pretty important if you want to secure something that needs to keep working even if it isn't on the internet, or the internet is down, or the CA's servers are down (or under DoS), etc.

But you can't do revocation that way. The client can get the certificate from the server being certified, but it can't get a revocation that way because nothing forces the server provide the revocation.

To do revocation you have to have a database of all the revoked certificates and check every certificate against the database before accepting it. But there are too many revoked certificates to store on the client; the database is too big. And if the client has to query some server then the attacker can DoS or MITM that server.

The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database.

> only issue certificates for a short period of time, like 10 days (but renewed every 7)

That's essentially the situation we're in with OCSP stapling, if you consider the certificate plus OCSP response to be the certificate. (The "must staple" cert extension[1] would make it even more similar.)

[1] https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeatur...

Someone please tell me why doing it that way is better than the following:

You validate yourself in the usual way and present a CSR to the CA. The CA signs the certificate but only with a very short expiration. However, unless the certificate is "revoked", you can come back at any point and the CA will automatically sign an identical certificate with the sole exception of the expiration date. (Then maybe they stop after e.g. two years unless you validate again, to keep an "actual" expiration.)

The advantage of that over OCSP stapling is that it requires zero modification to the client. What advantage does OCSP stapling have over that?

There is another solution, the CRL Distribution Point, or CDP. Entrust implemented this rather elegantly in their product starting in the mid 1990s and still use it today.

Instead of having a monolithic CRL, the CA publishes smaller CRLs and writes the CRL location on which a certificate would appear if revoked in the certificate itself.

In other words, every X certificates, the CA creates a new CDP, call it CDP_n, and all subsequent certificates issued between now and +X from now have the location of CDP_n written in them: That's where you look for their CRL.

+X certificates from now, the CA creates CDP_n+1 and starts writing that into the certs.

The size of X can be set, tuned, based on certificate lifetimes, number of users, etc., etc. If you want your CRLs to be fresher, use a smaller X, have more CDPs.

The other nice thing about the CDP is that it ties the CRL retrieved from wherever (an LDAP repo, a web site, etc.) to the certificate: The certificate contains within its signed payload a reference to the CDP location and the CRL contains within its signed payload a reference to the same location (the issuingDistributionPoint) so you have a high integrity check that the CRL being used to verify the certificate is actually the right one, even if the certificate is valid and therefore not listed thereupon.

This prevents an attacker from fooling you into trusting a revoked certificate by replacing its CRL with one that doesn't match it: The replacement CRL will have the wrong iDP, one that does not correspond to the CDP in the cert.

> The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database.

That can make it less likely that your certs will be used in revocation attacks. It does absolutely nothing to protect your visitors from other compromised certificates.

The "best" known way (to my knowledge) is to use a blockchain, which doesn't have the revocation problem.

Here is a comparison of a blockchain-based approach I'm working on with some other folks called DNSChain to other approaches people have suggested:

https://github.com/okTurtles/dnschain/blob/master/docs/Compa...

Seems like a bloom filter may work to deal with the large database of revoked certificates.

Bloom filters have false positives. Then you need some way to verify that a hit isn't a false positive, and whatever method is used for that will have the same availability problem in verifying a hit in the bloom filter as it would have in obtaining the revocation that way to begin with.

Read Adam Langley's blog about revocation. Only 19.9% of secure sites currently support OCSP stapling [1].

1 - https://www.trustworthyinternet.org/ssl-pulse/

Do note that you need TLSv1.2 to connect to the website, or plain HTTP.

They even made the site AES-256 only, even though Chrome and Firefox don't do AES-256-GCM.

I just manually converted this article from PDF to Markdown and HTML for easy of copy pasting and archiving.

If you like it, please subscribe to Linux Voice. It is an awesome magazine with an awesome team of people. Subscribe via http://shop.linuxvoice.com/ from just GBP 38 and get future issues straight to your door or inbox! (DRM Free PDF's and more available).

How is this different than Wallabag? (http://wallabag.org/) Wallabag is mature, has mobile apps, self hosted or on their servers and allows you to export stuff as PDF, epub or json.

I'm not seeing that they're claiming to be better than anything, just a, "self-hosted alternative to services like Evernote (R), Microsoft OneNote (R) or Google Keep (R)."

Are you a contributor to Wallabag?

I lost confidence in Wallabag when I encountered a bug with the long lasting session. Everytime I want to save a site, I click the plugin icon, have to login, reopen the site I want to save and click the icon again. The bug is several months old and the developers are unable to track it down. It's very worrisome when something as important as authentication isn't properly understood by the developers.

Wallabag doesn't appear to do note taking, just web clipping.

x240 here as well, except for (documented on the arch wiki) boot grub parameters for the acpi (brightness, suspend etc) it all works out of the box. Battery life with the extended 2 batteries is about 9 hours.

Is the database available somewhere? I can imagine that some providers want to scan for their ranges to inform their users. The following is time-consuming:

    $ while true; do curl -sk https://srsly.de | html2text | awk '/Address/ {print $2}' | tee -a vnsservers; done
    $ sort -u vncservers | wc -l
    3128

Here's a dump of an Elasticsearch database with 7573 of them in it and whois information attached to each document: https://shining-inferno-2609.firebaseio.com/.json

Here's an `asn_country_code`-based aggregation of countries:

  {
    "took" : 2,
    "timed_out" : false,
    "_shards" : {
      "total" : 5,
      "successful" : 5,
      "failed" : 0
    },
    "hits" : {
      "total" : 7612,
      "max_score" : 0.0,
      "hits" : [ ]
    },
    "aggregations" : {
      "countries" : {
        "doc_count_error_upper_bound" : 5,
        "sum_other_doc_count" : 1894,
        "buckets" : [ {
          "key" : "cn",
          "doc_count" : 1891
        }, {
          "key" : "us",
          "doc_count" : 1155
        }, {
          "key" : "de",
          "doc_count" : 894
        }, {
          "key" : "kr",
          "doc_count" : 457
        }, {
          "key" : "ch",
          "doc_count" : 398
        }, {
          "key" : "mx",
          "doc_count" : 244
        }, {
          "key" : "ru",
          "doc_count" : 178
        }, {
          "key" : "ca",
          "doc_count" : 171
        }, {
          "key" : "it",
          "doc_count" : 167
        }, {
          "key" : "gb",
          "doc_count" : 163
        } ]
      }
    }
  }

This is fun:

$ curl ping.gg/monitoring@me.com/127.0.0.1 [ ok ] Ping alert created for host '127.0.0.1' and email 'monitoring@me.com'. Check your email to activate it.

Haha, I actually thought about replying a "you are an smartass" error when someone subscribes to to 127.. or ping.gg itself :)

There is an alert limit per host, so not everyone will be able to do the same. Congrats!

Why not just blacklist local-only IP ranges?

Do note that XS4ALL is owned by KPN, which is a monolith like Comcast or Verizon. If the authorities come knocking hard enough, KPN will make sure it it shut down, or worde. XS4ALL is a good provider, I enjoy my IPv6 and fiber to home very much, service is good, they still provide a shell server which I use for IRC, I like them

I do however have my doubts about KPN...

Sad as it might be, I have to agree with you. Upon acquisition, KPN said it will let XS4ALL be as independent as possible, and as far as I can tell, they put their money where their mouth is (let them fight court battles, where KPN (the ISP) does not), but if there is little legal room for XS4ALL to move in, KPN will make sure XS4ALL complies.

On the other hand, XS4ALL is always looking for the boundaries of privacy and free speech -- if there is no more (legal) room left, and as such have reached the boundary, I have no doubt they would comply. But they probably make a big stunt out of it again, using it as a marketing opportunity, which KPN, of course, will have no problems with. As long as they comply with the law.

Very simple and very nice, how cool! Good job.