Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bad SSL

badssl.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Bad SSL

#71

Post by amenod »

dcosson wrote: post #52
delinka wrote: post #22

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 tag." Um ... yeah? Oh, you're saying that my browser renders t…

Is this some kind of comedy bit you're doing? You clearly understand the gist of what's going on and instead of asking for minor clarifications you're being unnecessarily facetious. The single point of contention seems to be whether this site is showing you what your browser claims to support, or whether it's showing you its own opinions of which configurations are safe to use. I believe it's the latter (but you're r…

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.

Re: Bad SSL

#72

Post by delinka »

dcosson wrote: post #52
delinka wrote: post #22

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 tag." Um ... yeah? Oh, you're saying that my browser renders t…

Is this some kind of comedy bit you're doing? You clearly understand the gist of what's going on and instead of asking for minor clarifications you're being unnecessarily facetious. The single point of contention seems to be whether this site is showing you what your browser claims to support, or whether it's showing you its own opinions of which configurations are safe to use. I believe it's the latter (but you're r…

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.

Re: Bad SSL

#73

Post by tialaramex »

agwa wrote: post #47
joombaga wrote: post #36

No-subject is surprising to me. Why would Chrome allow that? Doesn't that open it up for MITM?

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.

In particular, the usual algorithm is this:

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.

Re: Bad SSL

#75

Post by tialaramex »

ikeboy wrote: post #41

Chrome on iOS fails revoked and pinning tests.

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.

https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

Re: Bad SSL

#76

Post by yuhong »

The fun thing is that the old SHA1 roots pulled from browsers also happens to be the SGC roots.

Re: Bad SSL

#77

Post by baby »

_jal wrote: post #63

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.

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.

Re: Bad SSL

#78

Post by emn13 »

lvh wrote: post #56
simias wrote: post #33

Earlier quoted context omitted.

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 elabo…

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).

What's the point?

Re: Bad SSL

#79

Post by emn13 »

baby wrote: post #77
_jal wrote: post #63

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.

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?

Re: Bad SSL

#80

Post by baby »

emn13 wrote: post #79
baby wrote: post #77

Earlier quoted context omitted.

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?

Can you tell me which `red` is not insecure? (or not obsolete)
Post reply on HN