Caddy 0.11.5 - TLS issues on IE11?

Latest changes make main site and forum not usable on IE11.

Is it :

  • Because the minimum protocol version has been pushed to tls1.3?
  • Because the default protocol min and max versions don’t work on IE11?

IE11 is still supported and used on Windows 7, Windows 8.1 and Windows 10.

These users don’t get a chance to fix the issue and become a lost user or customer.

See relevant threads at Github:

https://github.com/mholt/caddy/issues/2496

https://github.com/mholt/caddy/pull/2399#issuecomment-448911385

Max version has been pushed to TLS 1.3, but according to the docs and according to the code I believe IE11 on Windows 7 x64 should be able to use TLS 1.2 with Caddy 0.11.5.

It doesn’t seem to work correctly for these sites.

I don’t believe it’s related to TLS version itself, but rather to the cipher suite selection.

I don’t believe it’s related to TLS version itself, but rather to the cipher suite selection.

Hmm. Maybe.

I tried to validate ciphers available in Caddy compared to the ones I have in IE11.

According to this website: https://www.ssllabs.com/ssltest/viewMyClient.html

IE11 on my Windows 7 x64 machine supports these:

TLS 1.3 No
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ( 0xc028 ) Forward Secrecy 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ( 0xc027 ) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ( 0xc014 ) Forward Secrecy 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ( 0xc013 ) Forward Secrecy 128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 ( 0x9f ) Forward Secrecy 256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 ( 0x9e ) Forward Secrecy 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA ( 0x39 ) Forward Secrecy 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA ( 0x33 ) Forward Secrecy 128
TLS_RSA_WITH_AES_256_GCM_SHA384 ( 0x9d ) WEAK 256
TLS_RSA_WITH_AES_128_GCM_SHA256 ( 0x9c ) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA256 ( 0x3d ) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA256 ( 0x3c ) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA ( 0x35 ) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA ( 0x2f ) WEAK 128
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ( 0xc02c ) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ( 0xc02b ) Forward Secrecy 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ( 0xc024 ) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ( 0xc023 ) Forward Secrecy 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ( 0xc00a ) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ( 0xc009 ) Forward Secrecy 128
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 ( 0x6a ) Forward Secrecy2 256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 ( 0x40 ) Forward Secrecy2 128
TLS_DHE_DSS_WITH_AES_256_CBC_SHA ( 0x38 ) Forward Secrecy2 256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA ( 0x32 ) Forward Secrecy2 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA ( 0xa ) WEAK 112
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ( 0x13 ) WEAK 112
Server Name Indication (SNI) Yes
Secure Renegotiation Yes
TLS compression No
Session tickets No
OCSP stapling Yes
Signature algorithms SHA512/RSA, SHA512/ECDSA, SHA256/RSA, SHA384/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, SHA1/ECDSA, SHA1/DSA
Named Groups secp256r1, secp384r1
Next Protocol Negotiation No
Application Layer Protocol Negotiation No
SSL 2 handshake compatibility No

To compare, here’s an SSL labs test of caddyserver.com that appears to list the ciphers it uses:

https://www.ssllabs.com/ssltest/analyze.html?d=caddyserver.com&s=138.68.240.78#suitesHeading

@Whitestrake thanks for the last link.

My IE11 doesn’t have any of the 3 listed ciphers.

The website lists issues for IE 11 / Win 7 as well.

Yeah. In the Github links above, they do a similar test (not on caddyserver.com, but on another site served by the latest Caddy) with similar results, I believe.

We removed the last of the known-weak ciphers from Caddy’s default cipher suite selection. I have no interest in re-adding them personally, but you are welcome to in your own configurations to support broken and unsupported clients. Just note that cipher suite selection is not customizable in TLS 1.3.

1 Like

but intrestingly, if caddyserver.com plays
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
on an obviously RSA cert

wouldnt this become
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
on an EC cert
which actually is in the supported list?

I think this could be intresting, I am probably going to compile myself the newest version of caddy, and try some stuff later.

1 Like

quick update I got it to work at least on 8.1 (don’t have 7 to test).

https://domain.tld/ {
  tls {
    protocols tls1.2 tls1.3
    key_type p384
  }
  //whatever you need
}

Thanks to @My1 & @matt for their work in making changes to allow IE11 to both continue to work allow users of outdated clients to connect whilst also being “secure by default” - without additional config requirements in Caddy 1.0.0.

Notes for anybody having issues with IE11 on Caddy 1.0.0 with default TLS config:

  • You will need to ensure your certificates are ECDSA and not RSA.
  • Prior to Caddy 1.0.0 the default was RSA when requesting a certificate from Let’s Encrypt.
  • Certificates will be automatically renewed using ECDSA upon nearing expiry automatically so max 90 days.It looks like renewals occur using the existing RSA for those certificates created RSA, so manual expiry is required to switch over to ECDSA to get continue IE11 support, see post below

To ensure the an high IE11 user base domain was using the ECDSA and not RSA certificate I forced a certificate renewal. There is probably a better way than this (feel free to comment if there is).

Because I didn’t want all domains to re-request their certificates from Let’s Encrypt at the same time, potentially hitting limits I just forced one domain (in this case example.com) by removing the certificate and restarting caddy.
Note here I do www.example.com as well - don’t forget otherwise you might have example.com working and www.example.com not working in IE11.

mkdir ~/bkup-rsa-old-certs
mv /etc/ssl/caddy/acme/acme-v02.api.letsencrypt.org/sites/example.com ~/bkup-rsa-old-certs/
mv /etc/ssl/caddy/acme/acme-v02.api.letsencrypt.org/sites/www.example.com ~/bkup-rsa-old-certs/
sudo systemctl restart caddy

You can always look for errors in caddy’s logs by quickly running after the restart:

sudo journalctl -f -u caddy

In my case I could see that the new certificate was obtained without issue and testing IE11 connected correctly.

4 Likes

Thanks, that was a helpful summarization!

1 Like

There may be a correction / conformation on my previous assumption:

This appears not be to true, renewals look like they are completed under the existing key and not switching from RSA to ECDSA.

I noticed this via Certificate Transparency Monitoring for renewals today after the upgrade to Caddy 1.0.0.

It looks like forcing a manual certificate renewal is required.

Matt IE11 is still a factor in the industry.
I was amazing that Caddy decide to leave it. I checked your website under IE11 and I saw it his unsupported.
I think Caddy must make sure they support older browser (that other big companies still support them).

Also Caddy must make sure to let people know about this issues before they upgrade to a new version. We’re paying customers and we want to feel good when we’re making an upgrade to a new version. You can’t leave IE11 behind without tell anyone.

Anyway we can’t upgrade to the new version because of that.

1 Like

@job_noam, while we appreciate you’ve got a strong opinion about this, your distress is somewhat misplaced.

It was discussed publicly in the repo - linked above in this thread - although, I think it should have been noted on the releases page as well (it wasn’t explicitly mentioned there, despite being a significant drawback that was noted well before the actual release was issued).

While I think the Caddy project can do better about making sure people are aware of this kind of issue, it’s hyperbolic to claim that they didn’t tell anyone.

Additionally, during that time, it was still supported, just not by default, since a satisfactorily secure method of doing so hadn’t been implemented. You just needed to change some settings in order to get IE11 working fine. That’s moot now anyway.

In the post just three spots above yours, it’s very neatly explained that changes have been made to re-introduce the default support (in a secure manner) in the latest version. You can upgrade. Have a read of the post.

2 Likes

Thank you for the explain Matthew.
I’m not a understand everything with the code and I’m really trying but when I saw caddyserver.com is not support IE11 it was clear to me that it is not supporting.
Also I think something like dropping IE11 from the version need to be write in the release on Github load and clear.
Anyway I think maybe I didn’t understand all this issue, when we will feel we need to upgrade I will hope everything will work without any problems and without the need to change anything in the binary (because we don’t really know how to do that :slight_smile: )

Thanks.

1 Like

@job_noam well it is a bit more complicated. Let me give you a timeline of events

version 0.11.5 (where it was still essentially njot a “full” release) knocked out CBC ciphers with a very good reason but thereby killed down IE11.
Luckily someone (in this case me) noticed one little “loophole” in the cipher list of IE11.

because apparently IE11 DOES support a secure cipher, but under one (in all honesty, stupid) condition:
→ one has to use an ECDSA key/cert for it.

I went and made the needed changes before caddy 1.0, which makes sure that caddy by default supprts IE11 in a secure way.

there’s only one catch (kinda becoming a theme here, lol):
caddy apparently doesnt see that the config wants a different type of key/cert when one already exists for a given host/domain/whatever

The Solution is to delete all your certs
But be careful because LE’s Ratelimiting, you can only request a certain amount of certs in any given timeframe.