
Bad SSL - aburan28
https://badssl.com/
======
FiloSottile
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.)

[1] [https://www.us-cert.gov/ncas/alerts/TA17-075A](https://www.us-
cert.gov/ncas/alerts/TA17-075A) [2]
[https://twitter.com/FiloSottile/status/765230315132559360](https://twitter.com/FiloSottile/status/765230315132559360)

For an easter egg, try to click on "Defunct"...

~~~
MichaelMoser123
amazing, how does one get to know certificate security when its scattered over
a gazillion of RFC's ?

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

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

~~~
djsumdog
Yea, it really should have a short description at the top. That alone would
make the UI instantly more useful.

------
raverbashing
Good concept, but the usability is bad

If you see the dashboard things are clearer, but there's a mismatch between
connected/not connected and what they were supposed to do.

~~~
acdha
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/](https://badssl.com/dashboard/))
is very new — see
[https://github.com/chromium/badssl.com/issues/257](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.

~~~
raverbashing
Ah I see

It's an interesting concept and service, no doubt about it, but giving the
test results as Pass/Fail would be more helpful ;)

~~~
acdha
I think [https://badssl.com/dashboard/](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.

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

~~~
baby
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.

~~~
emn13
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?

~~~
baby
Can you tell me which `red` is not insecure? (or not obsolete)

~~~
emn13
[https://mozilla-old.badssl.com/](https://mozilla-old.badssl.com/) negotiates
to TLS1.2 ECDHE RSA AES128 GCM SHA256 for me (FF54) which is fine.

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

~~~
baby
Yeah I see, this one is more of a server-side problem since it still allow
SSLv3 connections.

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

------
vidyesh
I misclicked and realised how many times this has been posted

[https://news.ycombinator.com/from?site=badssl.com](https://news.ycombinator.com/from?site=badssl.com)

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

~~~
EliRivers
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.

~~~
dcosson
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.

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

------
bigbugbag
I had no idea what was the purpose of this website until I found some
explanation in the comments.

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>

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

------
wbond
I created a complementary resource, [https://badtls.io](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.

~~~
bigbugbag
Always wanted to see what a self-gendered CA root would be like ;P

------
Handgemenge
[https://www.sslshopper.com/ssl-checker.html](https://www.sslshopper.com/ssl-
checker.html) comes to mind

~~~
popey456963
I'm actually more of a fan of
[https://www.ssllabs.com/ssltest/analyze.html](https://www.ssllabs.com/ssltest/analyze.html)
\- it gives you a whole lot more information (although does take longer).

~~~
noja
Both of those sites are for checking remote servers. BadSSL is for checking
what your client browser behavior is.

~~~
Symbiote
But SSLLabs does have a client test, it's even linked to from the BadSSL
dashboard page.

[https://www.ssllabs.com/ssltest/viewMyClient.html](https://www.ssllabs.com/ssltest/viewMyClient.html)

~~~
watter
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.

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

Another failure of minimalism.

~~~
gizmo
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.

~~~
watter
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.

~~~
gizmo
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.

~~~
watter
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.

Just some /constructive/ feedback...

~~~
gizmo
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?

~~~
watter
I didn't submit the link

------
jwilk
Somewhat related: [https://www.howsmyssl.com/](https://www.howsmyssl.com/)

------
Walkman
Last week I made a comparison matrix against Badssl.com for different Crypto
libs on OS X:
[https://gist.github.com/kissgyorgy/54601c883891991f28e49ac1b...](https://gist.github.com/kissgyorgy/54601c883891991f28e49ac1be572be2)

------
buhrmi
this must be really useful when developing your own browser

~~~
samat
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.

------
ikeboy
Chrome on iOS fails revoked and pinning tests.

~~~
tialaramex
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...](https://www.imperialviolet.org/2014/04/29/revocationagain.html)

------
andygambles
Regularly used to test client configurations and also as a training aid when
teaching users about web security.

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

~~~
agwa
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.

~~~
tialaramex
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/](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.

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

------
bigbugbag
Just noticed that this is an unofficial google product, part of chromium
github repository.

------
emondi
Shouldn't spoofed favicon link to http instead of https?

