Additional bad configurations about badssl.com

[april]

Could probably also do:

• Invalid fingerprint
• Missing required client certificate
• Incorrect key usage (ie, lacks keyEncipherment or serverAuth)
• Presumably you mean a revoked certificate, with OCSP / CT? If not, a certificate for revoked.badssl.com that has been revoked would be a nice demo.

Also, in addition to something like not.badssl.com (which is hilarious), it'd be neat to have a bleedingedge.badssl.com (ie, TLS 1.2, ECDHE, ECDSA, AEADs only).

[lilyanatia]

weak DH would be great... but you'd probably need separate ones for 512-bit and 1024-bit (and maybe 768 as well).

[april]

Weak DH should be really easy to do, but I'm a bit worried about having too large of a pull request for lgarron to deal with. O_o

I think 768 is probably overkill -- I imagine most clients either treat it like 512 or treat it like 1024. Shall we call it broken-diffie-hellman.badssl.com and weak-diffie-hellman.badssl.com?

[lgarron]

I think 768 is probably overkill -- I imagine most clients either treat it like 512 or treat it like 1024. Shall we call it broken-diffie-hellman.badssl.com and weak-diffie-hellman.badssl.com?

I ended up naming the ones we have dh480 and dh512 because:

• it's shorter,
• it's less subjective (the Chrome and Firefox errors for dh480.badssl.com) are actually WEAK_SERVER_EPHEMERAL_DH_KEY rather than "broken"), and
• even the OpenSSL source uses this abbreviation convention.

However, this makes it easy to include dh768. If there are any clients that behave differently with dh768, I think it would it be worth including.

[lgarron]

I've split everything from this issue into individual issues. The first post has been updated with links to the issues.

[april]

IIRC, Safari was the only browser to even have the slightest frowny at dh512; I imagine its behavior changes at dh1024, but I will check when I get a chance.

[lgarron]

Safari don't give me no frowney. :-(

Anyhow, it seems there might be more conversation to be had on DH, so I've made issue #35.

[april]

Weird, it looks like a regression in 10.10. I'm still on 10.9 over here:

http://i.imgur.com/hvAO3Bn.png

[lgarron]

The red lock on your screenshot is probably the favicon. :-P
(I don't see anything else frowny, but then I'm zooming and panning on
mobile.)
On Fri, May 15, 2015 at 20:13 April King [email protected] wrote:

Weird, it looks like a regression in 10.10. I'm still on 10.9 over here:

http://i.imgur.com/hvAO3Bn.png

—
Reply to this email directly or view it on GitHub
#1 (comment).

[april]

That's the favicon? How embarrassing! I thought they all hid the favicon over https for this very reason. Looks like from your screenshot that they changed that behavior in 10.10.

Okay, so then no browser manufacturers alert for 512-bit DH keys. The only people that seem to actually be on top of it are the Qualys folks:

https://www.ssllabs.com/ssltest/analyze.html?d=dh512.badssl.com

... who rightly give dh512.badssl.com a failing grade.

[rugk]

That's the favicon? How embarrassing! I thought they all hid the favicon over https for this very reason.

No. No browser hides the favicon.
FYI that's even a technology which can be used in the attack ssl stripping to trick the user into believing they use HTTPS.

[lgarron]

No. No browser hides the favicon.

While SSL stripping and favicon manipulation are definitely worrisome tricks, I hope you'll concede that Safari does hide the favicon while you're not editing the URL bar, as in the screenshot above. ;-)

[rugk]

Okay, okay. 😃
But I doubt that it shows the favicon on http:// connections...