i noticed that after disabling all DHE cipher suites in chrome, going to https://dh512.badssl.com/ still succeeded. it turned out that the browser was showing the page from cache, and clicking the reload button fixed it. but these tests should probably send headers to prevent browsers from caching results.

Here is another test case for your awesome project. A partial wildcard in subjectAltName must not match an IDNA label. For example "x*.example.org" must not match "xn--tst-bma.example.org" (IDNA for tést.example.org).

I fixed the bug in Python and Mozilla last year:
http://bugs.python.org/issue17997
https://www.mozilla.org/en-US/security/advisories/mfsa2014-45/

Either:

• Correctly signed certs that have formatting errors.
• Certs that are corrupted before/after signing.

End-to-end is probably fine (e.g. a local Python script to make sure that badssl.com is giving expected errors/headers/cipher suites/certs).

This requires a separate IP address that doesn't use SNI (or at least defaults to SSLv3 with this particular domain).

Two options:

• mixed-______.badssl.com
• mixed.badssl.com/_____

Possible kinds of content:

• Javascript
• images
• audio
• video
• XHR
• Flash
• font
• css
• iframe
• form

It would also be nice to have combinations of these, or at least a page with all.

See https://www.bennish.net/mixed-content.html for an example with lots of mixed content.

Carried on from here.

Large RSA keys can cause issues on some platforms.

From this comment by @marumari.

@marumari: I presume you meant using a cert chain where the intermediate doesn't actually sign the leaf?

While we're at it (see #18 for rsa1024). This could be useful for testing old/specialized clients.
(But it would probably need a very permissive set of cipher suites for that.)

Since Firefox is looking at supporting this (idea from @noncombatant).

Change the generic subdomain fallback to redirect to help.badssl.com.

Ruby, Python and PHP were vulnerable to NULL bytes in subject alt name. I fixed the bug for Python and PHP (CVE-2013-4238, CVE-2013-4238, http://bugs.python.org/issue18709).

You may not be able to produce a vulnerable certificate with OpenSSL. I tried but failed. Eventually I used some Ruby code to produce a vulnerable certificate.

hsts.badssl.com doesn't really do anything. It would be great if it had the following behavior:

• Disable redirect to https on http://hsts.badssl.com/?hsts

Then:

• When https://hsts.badssl.com/ initially loaded over HTTPS, set HSTS
• Redirect to http://hsts.badssl.com?hsts
• If it then correctly goes to https://hsts.badssl.com/?hsts, generate a green background. If it instead retrieves http://hsts.badss.com/?hsts, generate a red background.

Right now, the site is simply setting Strict-Transport-Security and displaying a green background. That really doesn't say much, because it'll generate a green background on everything from IE6 to the latest Chrome.

Disable all forward-secret ciphersuites (idea from @noncombatant).

A subdomain serving valid OCSP.

Other OCSP ideas:

• Serve invalid OCSP
• Serve no OCSP but use must-staple.

In particular, for this change I could use test cases for invalid and unrecognized SCTs.

Using settings from Mozilla's TLS config generator.

• mozilla-modern.badssl.com
• mozilla-intermediate.badssl.com
• mozilla-old.badssl.com

Each of the pages should document when the config generator was last used to update the cipher suites for it.

Would be great if badssl had a test for HPKP voilations.

Unfortunately, I can't share the server private key on GitHub, because it's being used for tests that should probably not be MitM-able. And it will become more difficult to obtain publicly signed SHA-1 certs in the near future.

However, it might be useful to use OpenSSL to generate:

• a custom CA
• a server key
• a CSR for *.badssl.com (or maybe localhost?)
• certs used by badssl signed by the CA

... and then provide a way to run that locally for development. (Strawman for getting the same cert behaviour as public certs, even though it would make me uncomfortable: throw away the CA key after signing certs, import the CA key into the trust store, modify etc/hosts to point the desired test domain to localhost.)

https://github.com/edvinanet/tls-o-matic does something similar, so their code might be useful to look at.

April, would you mind adding this?

"Export-grade" ciphersuites (idea from @noncombatant).

(There's probably a slightly more self-descriptive subdomain we could use for this, though.)

Time for flexbox to shine?

From this comment by marumari@.

Most sites that enable DHE, do so to get Forward Secrecy on older clients that don't support ECDHE. By only negotiating TLSv1.2 and TLSv1.1 on the DH2048/1024/512 pages, none of the legacy systems/browsers can even connect to the page. Appreciate this may not be the primary use case for this project/site but it would be very useful to be able to confirm DH2048 support on things like OS X before 10.9, Chrome before 22, Firefox before 23 and lots and lots of mobile devices.

i.e. SHA-1, RC4, mixed content

In Chrome, this would be useful to see the maximum number of warnings/messages.

https://github.com/lgarron/badssl.com/blob/82b1615bb41ec7f99bb4bed3e286194ef054bb2a/domains/preloaded-hsts.badssl.com/index.html#L50

CAs are not supposed to sign these, so it's unlikely we could get a real one for badssl.com.
But we can certainly make a self-signed one for testing.

Styling should stay the same by default. Underline on hover/tap.

From this comment by marumari@ ("ie, TLS 1.2, ECDHE, ECDSA, AEADs only").

This corresponds to connections that Chrome considers modern.

Certificate Issues

• SHA-1 expiring in 2017 (#16)
• OCSP / CT? (#17)
  • Maybe must-staple without stapling?
• weak-rsa.badssl.com (idea from @noncombatant) (#18)
• 10000-sans.badssl.com (giant certificates with many subject alt names)
• missing-intermediary.badssl.com or incomplete-chain.badssl.com (idea from @noncombatant)
• hostname-mismatch.badssl.com or wrong.host.badssl.com (idea from @saschaf)
  • Perhaps make wrong-host.badssl.com work instead, to avoid confusion about which ones are hyphenated?

Cipher Suites / Protocol

• CBC
• SSLv3 (#20)
• TLSv1 (#21)
• Other SSL/TLS versions?
• Mozilla's modern/intermediate/old configs. [#22]
  • Modern one at not.badssl.com? :-P
• no-pfs.badssl.com (idea from @noncombatant) (#23)
• export.badssl.com (export-grade ciphersuites; idea from @noncombatant) (#24)
• Weak EDH key (see demo.cmrg.net). (44df428 and aea4d8e)

Headers

• HSTS
  • preloaded-hsts.badssl.com
• HPKP (#15)

Content

• Mixed Content
• Mixed Scripts (#33)
• mixed-____.badssl.com? (image, audio, video, XHR, Flash, etc.)
• Migrate mixed-content-test.appspot.com? (#32)

Misc

• oe.badssl.com (opportunistic encryption; idea from @noncombatant) (#25)
• http.badssl.com (redirect to HTTP)

From this comment by marumari@.

Similar to subdomain.preloaded-hsts.badssl.com.

However, I'd like a a better name that suggests that the subdomain should give a non-overridable error (if https://hsts.badssl.com was visited).

An incomplete list:

• https://longtermsha-1.comodoca.com/ (#16)
• https://sha1-cross.digicert.support/
• https://sha1-2016.digicert.support/
• https://sha2.digicert.support/
• https://mixed-image.digicert.support/ (#33)
• https://mixed-script.digicert.support/
• https://crypto-cipher.digicert.support/ (RC4?)
• https://crypto-modern.digicert.support/
• https://ct-embed.digicert.support/ (#14)
• https://ct-ocsp.digicert.support/ (#14, #17 )
• https://ct-none.digicert.support/ (#14)

I still insist that the output is static, though. That way, everything can be served, rendered, and debugged more safely.

In addition, it has been very useful for testing that each page is a single resource (with scripts and styles inlined in the page).

I have the full assets => might as well also throw the apple-touch-icon in there?

They're outdated and incomplete.

Perhaps we should also put them under make install or something similar.

Either to its own subdomain, or as a common folder for all subdomains.

Right now I'm leaning towards keeping the two separate, but it's worth considering whether to consolidate both browser security test sites I've made.

The SHA-1 site should probably say SHA-1 2015 and use a SHA-1 certificate that expires in 2015, especially when the SHA-1 2016 and SHA-1 2017 sites go live.

Oddly enough, the official sha1-2016.badssl.com does not generate any certificate warnings in Chrome, but the one that uses my self-signed root does generate a warning. I feel like my behavior is the correct before, and the one that we should be demonstrating, and that the official site is incorrect. I'm not sure why the official sha1-2016.badssl.com doesn't generate a warning in chrome, though.

Is it because its key is pinned or something?

I haven't thought about this much, but there are probably some useful things.

At the very least, something like default-src: https://* with mixed content.

I tried this earlier, and couldn't get the downgrade to work.

Right now, they all redirect to badssl.com. Perhaps we should stop this, in order to avoid people relying on this behaviour.
(We can always add redirect.badssl.com if it's needed. redirect.badssl.com/<directive> is also easy implement.)

The list is getting kind of long. sha256.badssl.com is currently commented out on the front page.

most (all?) clients will accept very bad DH parameters, such as (31-bit subgroup):

-----BEGIN DH PARAMETERS-----
MIICCgKCAQEA////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
///////////////////////////wAAAAHQKCAQEAu6kFl4Jni6wu89MOPQwhFQdz
k4SsloDJnHPB7SBXRjZHIkqVjTCGqO/PA4LqerBfXtgnh33YVaefTtYLQGC0bLqi
19PeEv3n8PaTB+RqMisy54p6mhBQZ2VxkiPKphpljueg1VPTN6GN7f/P2TCFXCE3
VRS3roLvvQ4CikZMyO8xVK58mU5YHv7u8A4b/rilq4m+Hr5upS5zvlKIU1iqi47d
0oyrrY9X9AVT2KtmHUdIhwMKPMWpgGGG/si/jrzPI2jAcuVDGRYx8D1btqhzFWQZ
CvJdDaVVA6JSw0XCp3zq71uzuU4vrLBRskZ/vFVw1FHmUSyR4JcDsu+YLzoT+A==
-----END DH PARAMETERS-----

or (not prime):

-----BEGIN DH PARAMETERS-----
MIIBBwKCAQBed4vGnUmyHOfbuX0tMqo0gVsdd30AOBYfqQppFv3UycvnmSdu1Q95
C/gGHCoK2L+DqRHf4OxuiPz/JpqAJtoBVAbqqf1XOALWliZIo3hJGZxrTUuZPawa
iEmzENZRFFG3IJyQ5/9g9+O2McQfYH6NaAuV8+SA7erVyx0sDjitmgW6fAxeFTVQ
oEeZiYKoyCfLhPFdT5fl4ug7MtXnNEpPjSBovMD5Xs/ZlJ3FDfsV69Swoz7dS+UK
JlCrv7Obf+tlJCMhFJf3A2GNP+RzIJddSn2JbBaTMECgpwgBuKmqkKL6LiDzNML/
rvO1LFfU+tV4bbn+RBiu+OCC2m2ZTgvHAgEF
-----END DH PARAMETERS-----

In particular, if you run cert-generator.sh on a fresh clone, it will print:

Generating BadSSL Certificate Signing Request

Signing BadSSL Default Certificate
Signature ok
subject=/C=US/ST=California/L=San Francisco/O=BadSSL/CN=*.badssl.com
Getting CA Private Key
Error opening CA Private Key ../self-signed/badssl-intermediate.key
139949868869280:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('../self-signed/badssl-intermediate.key','r')
139949868869280:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load CA Private Key

@marumari, would you mind handling this? A simple solution would be to check if self-signed/ contains any certs, and exit an error message.
A nicer solution might be to ask and offer to overwrite the old certs.

Perhaps organize by categories from 9ed944e.

Wanted to use browsershots.org to hit the dh2048.badssl.com page and see which (if any) browsers had problems with 2048bit parameters. I get an error on their site about not being able to access badssl.com/robots.txt.

Their FAQ (http://browsershots.org/faq#) states:

Blocked by robots.txt
Browsershots respects the robots.txt standard. If you want, you can explicitly allow Browsershots by adding a section like this to the robots.txt file on your server:
User-agent: Browsershots
Disallow:
Some pages on browsershots.org are also protected, mainly to keep screenshot result pages out of search engines.