An incredibly useful resource, well maintained by some of the best people in the PKI space, recently quoted by US-CERT [1] and so quick to use that I try it before starting to use any browser.
A year ago it made me find out that the most popular iOS Tor browser doesn't check certificates at all. [2] (Use OnionBrowser instead.)
I have no idea what I'm looking at. Do I need to enter a domain name some place? What domain is this telling me about? I scroll to the bottom of the page, it's telling me what browser and OS I'm on ... ok, maybe this page is showing me how bad my browser is at SSL?
Oh, these things are clickable. "This pages contains a lone password field not wrapped in a <form> tag." Um ... yeah? Oh, you're saying that my browser renders that and it probably shouldn't.
dh2048 is green let's click that. "dh2048.badssl.com uses an unsupported protocol. ERR_SSL_OBSOLETE_CIPHER"
Alright, I give up. I have no idea what I'm looking at.
Edited to add:
If this site is reporting issues with my browser, why does it seem to say that Chrome supports dh2048 (this item is green on the page) but then following the link the browser complains that it's unsupported? Either the point of this site is not obvious, or it cannot be trusted to know the right things about my browser.
To clarify: this doesn't show what's supported and what's not, that's for you to find out by clicking things. It shows things in green that are generally considered secure. For example, 2048-bit finite-field ephemeral Diffie-Hellman (that's dh2048.badssl.com) is generally still considered secure, but Chrome doesn't allow it, so that's why you get that error even though the website shows it as green.
Chrome does so for tangentially related, mostly-fine reasons. Generally dh2048 doesn't really exist on much of the Internet: because clients that don't do ECHDE (only DHE) are also generally limited to 1024-bit FFDH. That's not as good (not totally busted, but not great either). Anything that does 2048 bit FFDH probably also does ECDHE, and ECDHE is much better from a performance perspective and marginally better from a security perspective.
The best classical attacks put P-256 at about 128 bits of security, and 2048 bit FF at about 112. Neither is problematic at present. FFDH has some other problems: because the other peer communicates the field over which you're going to work, a poorly configured or malicious peer could pick a bad field or a small subgroup. (That's a little esoteric, but since there's no good reason to keep it around anyway....)
> badssl.com is meant for manual testing of security UI in web clients.
And my understanding is that green things are things that are good (security wise), red is bad. You'll have to test yourself if they work with your browser.
Took me a little while to understand as well but it's supposed to test your client. You browser should be able to display the green links without errors and should refuse to navigate to the red ones since they are insecure for one reason or an other (weak algorithms, broken SSL etc...)
That's mostly correct, except for some definitions of "should". Chrome connects to the Mozilla "Old" config, which is fine. The "Old" config does not mean "only old/bad ciphersuites", it means: "support old/bad clients". Chrome negotiates AES128GCM with ECDHE on my desktop, so it is rightfully pretty happy.
Meanwhile, while 2048 bit FFDH is considered safe, Chrome refuses to connect to it, for reasons that I've elaborated on elsewhere in the thread.
Given what you say - what's the point of this website? After all, a safe client should connect to green things (but might not support everything, fine), and... should also connect to many red things (if they're actually safe).
If you're interested in figuring out what's wrong with TLS configuration on your site, SSLLabs is a much more useful tool. This is for checking if an SSL client (like your browser, but also e.g. a command line tool) is doing something bad.
I'm not being facetious. I'm narrating a user experience. One that still leaves me with a lack of understanding about the purpose of this site. Considering the ranking my comment received, a fair number of other HN readers agree that this site has terrible usability. Early comments addressing the use of the site made guesses that are apparently wrong. I say "apparently" because by now there are quite a few comments clarifying the intent of the site. That intent is not communicated by the site itself.
Chrome tells me dh2048 is "unsupported." If the site says "this is good" and Chrome says it's "unsupported" but then Chrome displays an error code indicating "obsolete," I can't tell who's wrong here. Either Chrome's developers chose the wrong error code, or badssl.com is recommending an "obsolete" algorithm which sounds bad (why would it be obsolete if it's good?) The site taught me nothing.
Maybe the site wasn't intended for a wider audience. (I've see corporate training contracting companies set up similar sites for their students: it is in no way obvious what the intent is unless you have sat through their class.) But it's been linked on a discussion site with a wider audience. Maybe it's a valuable resource, but without an explanation, it's just another website with bad UX.
There seems to be an attitude that appears in tech crowds often enough: well I know what this is, how could you possibly misunderstand? They forget that other humans, with other perspectives and other experiences than their own would lack the context that makes things "make sense." They fail to see through the eyes of someone different. It's bad for user experience. That doesn't mean everything should be designed for everyone. Maybe badssl.com serves its audience well. Maybe it's not intended for a "wider audience." And that's OK.
I have no idea about the extent of gp's knowledge on subject, but I came to the comments section with similar feeling. I literally had no idea what this site is about, what it does, how I can use it...
Even now that some comments have clarified some of this questions I still find the UI confusing and colors simply insane.
This page isn't trying to sell you a product. I get that you're trying to give constructive feedback but if you don't know what you're looking at here, you can just ignore it and move on.
At best the submission title could use an edit so it's clearer what it is, that you don't have to click to ignore it.
I think you're right but missing the context: badssl.com was setup as a resource for security engineers who are running tests. It's great for that and it allows the kind of fine-grained testing which anyone who is developing software, configuring firewalls or group policy, etc. would want — i.e. if you do anything which consumes HTTPS, why not take the time to add a step to your CI process which prevents accidental regressions?
The dashboard (https://badssl.com/dashboard/) is very new — see https://github.com/chromium/badssl.com/issues/257 — and as the person who opened that issue, my context was different: that conversation started among a group of U.S. federal government employees who are often in the situation of needing to use a MITM SSL proxy for compliance reasons and don't directly control it, often lacking even the ability to install software on their primary workstation (not without cause, given the threat model). Being able to run tests in a browser and send the helpdesk a single link saying “These three boxes should not be red, please file high-priority ticket with the network group” is really useful for getting changes through quickly.
I think https://badssl.com/dashboard/ does a good job at that — you could probably do something like what SSL Labs does with a letter grade but I think the Good/Okay/Bad levels is probably the level of nuance you want for a simple “Should I learn more about this?” prod.
What I'd like would be for that to eventually become the default view with an advanced tab for people who want to drill down into the full list of everything available.
Really don't understand the people downvoting in this thread. Apparently a certain percentage of the population believes that if they don't understand the function of an artifact in the world, the maker of said artifact has failed.
It isn't quite projection; seems like more of some wildly misguided consumer-is-king impulse. Browsing academic libraries must be hell.
If I'm browsing a library, then I have some idea what I'm looking for, what the context is around what I'm seeing.
Here, I'm not looking for anything in particular, just browsing around. I have no idea what this thing is right away, and whoever designed it didn't bother to make it clear. There's a million other things out there that are clear right away, so why should I bother to figure this one out?
As someone clearly disagreeing with you, I find it interesting that you mention not understanding "the people downvoting" and then only talk about your impression of the posts that are not downvoted. The downvoted posts seem a lot more needlessly rude to me than the ones they respond to, and I hope I'd see that similarly even if felt different about the issue overall.
The confused top-level comments to me read mostly as expression of said confusion, which to me is completely fair for a place like HN. Of course people want to understand why something could be interesting to them if it is posted & upvoted here.
Posting something without explanation is bad taste :) I completely understand what this thing is for (easy testing of TLS clients) but I can understand the frustration of seeing a link without context.
Although the color-coding is odd; red doesn't mean insecure or even "dubious", even though it does sometimes... So using the site even for testing TLS clients seems a little non-obvious.
At least if the idea was that your client should accept green and reject red connections, the site has definitely failed.
If the idea was just to let you see what happens, then why the color coding?
There may well be obsolete stuff that server does support; but as negotiated, that's pretty much as good as it gets. It even has the new downgrade-prevention extensions on, so support for the old stuff shouldn't be a problem even if your client accepts it (which it need not).
It seems badssl caters to a bunch of insiders who knows about its function, a quick description of what is its purpose and how to use it would make it quite useful to a larger public.
In case you're wondering how you might use this: BadSSL is really convenient for checking clients. Is that weird version of Curl in that PHP webapp totally busted? Answer: probably yes -- although you can use this to find out how it's busted specifically in the context of TLS.
If you have a modern browser, whatever it does is probably fine. Also, consider using Chrome. (Yes, I know about the battery life issues.)
(Curl-from-PHP can be bad for non-TLS reasons! It's a likely SSRF vector, and it often does things like TFTP and Gopher so it will helpfully let you speak all sorts of protocols.)
I'm surprised to see so many negative comments. It's a super straightforward UI, you click on stuff to see how your browser treats that ssl (mis)configuration. This is a great resource, thanks for posting.
You should not be surprised. UI is not UX and UX here is terrible for those who can't figure out what the purpose of badssl.com is.
Simply replacing the page title repeating the domain name by an explicit title along the lines of what's used on ssl labs client test: "test SSL/TLS Capabilities of Your Browser".
https://www.ssllabs.com/ssltest/viewMyClient.html
The UI is straightforward, true. Very simple. That's not the same as good. The comments here indicate that a great many people simply don't understand what they're looking at. That's bad. A straightforward, simple UI is useless if people don't understand what it's telling them.
I understand what people are saying, and I'm offering a contrary opinion, that I found the site useful as-is and I'm glad it was posted despite the fact that HN's rules on not allowing links to include any extra context are leading to some confusion.
Used this in junnit tests. A callback to a specific host caused entire platform to hang 5-10 minutes or untill restart of different batch jobs but also dermed like Translations did it too. Turned out specific certificate with strong key would not be picked up by java provider but in stead fell down to our ncipher hardware box and Got stück. Now we Used httpclient but through Socks proxy and timeout does not Work Then. After That Bouncy Castle was put before ncipher as provider and was tested with all those Certs to avoid similar problems.
So far it appears that latest Safari on macOS is fully vulnerable to pinning, would only alert about a revoked certificate on second access to the page (?), and doesn’t care about insecure password/credit card forms.
I created a complementary resource, https://badtls.io to allow for automated testing of TLS client libraries. It uses its own self-gendered CA root to allow for generating certificates that exhibit different edge case conditions.
A few practical differences are that badtls.io is designed to be easy to run locally and having simple Python scripts to generate new keys and certs.
For my TLS libraries I utilize both badssl.com and badtls.io to provide more diverse coverage.
It took me going to this page to understand what was going on, I assumed it was a web server test. The report was more pratical too, telling me what I'm protected against, not just a bunch of yes/no things that I have to go reference. I'm on a phone in portrait mode though so maybe it is just a formatting thing.
If this is meant for general technical consumption, it's sorely lacking in usability. After several seconds, I guessed that it might be referring to something about my browser.
Some of the colours seem to indicate badness. Clicking on things provides no additional information, but then makes me wonder if it's meant to be an example of a bad webpage and there's nothing wrong with my browser.
Took me awhile to figure out what's going on, way longer than it should have. A one-sentence description at the top would have cleared it up.
It is indeed the site itself that intends to be "bad". The site intentionally serves SSL certificates that are invalid or bad in various ways. Each subdomain is bad in a different way. You can test your code against these domains to ensure your code rejects the invalid or bad certificate.
This site isn't meant for general technical consumption. I don't understand why you would think otherwise. Why does this page have to explain what all the different cyber suites are, how SSL handshaking works, or why some hashes are no longer considered secure for cryptographic purposes? There are plenty of other websites out there that provide SSL primers. This website doesn't need to do that.
This isn't a failure of minimalism, it's a pretty cool page for people who are curious about the different SSL weaknesses that have been discovered over the years.
It should at LEAST say it is targeting the browser for the tests, not someone's ssl site. I had no idea it was testing my phone until I went to the other test site link in the footer. I can't believe you go to such length defending the "UX" when it isn't even obvious what the test is for. Seriously.
The site has no such obligation. The site is for a very specific target audience: people who write web clients/web browsers. So the site isn't created for you, and it isn't meant for general consumption, and it doesn't have to explain anything.
It's a tool for web client developers, like it says in the github README. Which is one click away.
If the developers of this tool posted this as a SHOW HN, then yes, you'd have a point. But that's not what happened here.
Actually I am a developer and this is useful to my work so it is targeted exactly at someone like me. It would still help to have a description without going to github.
Sure, it would help, in that it would have saved you a single click.
If you had submitted the link to HN with a descriptive title, then there wouldn't have been any confusion here either. So you're complaining about the site not saying what it does (even though it says so right in the README) while at the same time submitting the link to HN with a title that doesn't say what the link is about.
As some /constructive/ feedback, do you appreciate the irony?
He might think otherwise because it climbed to the top of HN but doesn't have any explanation (here or on the actual page) of what it does or who/what it might be useful for.
And for people who are curious they can read the comments here that explain what it does or click on the large github banner in the corner and check out the README.
Calling this site a "failure of minimalism" is unnecessary and mean.
For me main use case is to test browsers our employees use and to educate users on examples. Previously I've been using ssl quality labs test history to find some bad ssl examples, but this is much more convenient.
It's probably not helpful to think of this as "passing" vs "failing" but as a way to examine the behaviour so you understand it and aren't blind-sided. It's secondarily useful for demonstrating a particular behaviour in software (e.g. "Actually Chrome doesn't verify CRLs or OCSP") without needing to cook up your own tests or stumble onto a suitable site for testing each time.
The Chrome developers have an extended defence of why their browser behaves as it does for revocation, which is pretty interesting, and the long-term plan is OCSP-stapling, which fixes things, but understanding the badssl.com features as "pass" vs "fail" rewards the simplest possible check-the-boxes approach and that's unfortunate.
I'd say it also fails the others, because simply pressing 'continue' makes the warning dissapear without any visual indication that the connection is insecure.
The certificate at no-subject.badssl.com has an empty subject field, but it still contains the subject domain name in the Subject Alternative Names (SAN) extension.
Using the original X.509 subject field for the domain name has been deprecated for some time, and modern TLS clients look at the SAN extension instead.
1. Does this certificate have at least one SAN dnsName or SAN ipAddress? If so, go to step 3.
2. Look at the certificate Subject for a Common Name, is this definitely a valid Fully Qualified Domain Name or an IP address written out as ASCII text? If so, pretend we found exactly one SAN, with this dnsName or ipAddress in it, otherwise abort, invalid certificate.
3. Check that one of the SANs we found matches the server we expected to talk to, for URLs in a browser this means exactly matching the name in the URL so e.g. even if www.example.com has address 10.11.12.13, a certificate for 10.11.12.13 is no good for URLs starting https://www.example.com/
Getting rid of step 2 is a desired end state for popular web browsers, because that step is complicated, and complication increases the chance of making a mistake. Mozilla has signalled they intend to abolish step 2 for public trusted CAs (not any CAs added by the user) and Chrome has talked about the same. The public CAs have been required for many years to include a SAN, but the usual incompetence and inertia interferes in enforcing this. People who bought a "perfectly good" certificate which is missing SANs will invariably blame their web browser, not the certificate vendor who sold them a defective product.
Common Names are notionally limited to 64 characters in length, most FQDNs are shorter, but definitely not all of them, especially in some countries where long-winded names for things have a strong history like Germany. So this is another reason to stop trying to squeeze FQDNs into the Subject's Common Name.
Common Names remain useful for naming certificates that aren't for a TLS service, such as CA certificates themselves, or indeed personal client certificates, just not really for web sites.
A year ago it made me find out that the most popular iOS Tor browser doesn't check certificates at all. [2] (Use OnionBrowser instead.)
[1] https://www.us-cert.gov/ncas/alerts/TA17-075A [2] https://twitter.com/FiloSottile/status/765230315132559360
For an easter egg, try to click on "Defunct"...