Bad SSL
badssl.com
badssl.com
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"...
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.
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.
> 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.
Open the dashboard and it's more 'verbose'.
Red means it didn't connect to that site as it shouldn't in certain situations
For example, in current Chrome, Mozilla "Old" TLS config is red, but Chrome connects fine.
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.
What's the point?
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....)
If you see the dashboard things are clearer, but there's a mismatch between connected/not connected and what they were supposed to do.
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.
It's an interesting concept and service, no doubt about it, but giving the test results as Pass/Fail would be more helpful ;)
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.
It isn't quite projection; seems like more of some wildly misguided consumer-is-king impulse. Browsing academic libraries must be hell.
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.
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?
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).
Biggest Mistakes in Web Design 1995-2015
#2 A Man From Mars Can't Figure Out What Your Website Is
About In Less Than Four Seconds.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.
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.)
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
I
Adding offense to injury it actually shows unhelpful info if you put your cursor on the Badssl title on top of the page.
Allow to suggest a little modification here, replace the following:
<div class="title-bar" title="badssl.com - a memorable site for HTTPS misconfiguration"> badssl.com </div>
with
<div class="title-bar"> badssl.com - manual testing of security UI in web clients </div>
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.
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.
Another failure of minimalism.
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.
Calling this site a "failure of minimalism" is unnecessary and mean.
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.
Just some /constructive/ feedback...
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?
Anyways this kind of info should not be hidden a click away in a github readme, it belongs in the actual web page.
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.
Think of it as expecting to see gas gauges and speedometers (and no grease) on the oil pan of your car.
You people consistently make me feel like a real wonder boy.
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 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.
https://www.imperialviolet.org/2014/04/29/revocationagain.ht...
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.