Can't connect from IE11/Win7 because CBC cipher is removed from default ciphers

[noobow34]

First of all, I can't explain well in English because I'm Japanese.
If you can't understand this issue,please close this issue.
Very sorry.

1. Which version of Caddy are you using (caddy -version)?

0.11.4 with 72d0deb

2. What are you trying to do?

Do SSL Server Test https://www.ssllabs.com/ssltest/index.html

3. What is your Caddyfile?

mydomain {
        proxy / https://localhost:5001 {
                insecure_skip_verify
        }
        gzip
        tls email
}

4. How did you run Caddy (give the full command and describe the execution environment)?

systemctl start Caddy.service by hook.service plugin

5. Please paste any relevant HTTP request(s) here.

request from https://www.ssllabs.com/ssltest/index.html
or
request from IE11/Win7 direct

6. What did you expect to see?

Can be connect from IE11/Win7.
IE11/Win7 is not modern,but still supportted.
I think should be able to connect.

7. What did you see instead (give full error messages and/or log)?

SSL Test result is below


maybe can't connect IE11/Win7 etc

when without 72d0deb

8. Why is this a bug, and how do you think this should be fixed?

removed cbc cipher from default ciphers in 72d0deb

Win7 is not support default ciphers in 72d0deb
https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-cipher-suites-in-windows-7

I think
In TLS1.3,CBC cipher should be remove,
but when connect with TLS1.2, CBC cipher enable.

9. What are you doing to work around the problem in the meantime?

downgrade to 0.11.4 without 72d0deb

10. Please link to any related issues, pull requests, and/or discussion.

Bonus: What do you use Caddy for? Why did you choose Caddy?

I'm using in my website https://ja-fleet.noobow.me/ (Information site of Japanese aircraft)
As a reverse proxy.backend is ASP.net Core.
Reason of choose caddy,easy config very secure.

[noobow34]

sorry
already discussed in
in #2399 (comment)

[mholt]

Thank you, your attempt at english is good. :)

Sorry, but older clients just aren't supported anymore. They'll need to be upgraded to support secure, efficient cryptography.

[noobow34]

Thank you,I understood.

They'll need to be upgraded to support secure,

I think so too,strongly.

I will continue use caddy.
I think caddy is the best web server.

[My1]

well I can see that internet explorer is plain ugly but if IE11 (the newest version) fails on win7 (a still supported and very much used OS) it gets fun.

one thing someone might want to add to the docs may be how too add IE-compatible crypto without entiretly killing off security, for example a computer repair person may want their site to be accessible with not the most modern clients, because there is a big chance people who actually use those may need help from them.

[magikstm]

I agree with @My1. I think this issue should be considered.

I think it blocks website usage to legitimate users that may still use browsers that didn't reach end of life yet. I still get several visitors using unsupported browsers following this change.

I added images and opened a discussion here:
https://caddy.community/t/caddy-0-11-5-tls-issues-on-ie11/5297

[My1]

I have found something very intresting when looking at a the list of caddyseerver.com's current algos and IE11's algos, which perhaps might be a breakthrough in this.

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?

if yes this could be a major breakthrough on this.

[My1]

Left Opera, right obviously IE11 on win8.1, this looks promising. dont have a win7 currently at hand, but someone with win7 may try, so basically as long as there are no other roadblocks to EC certs this may just be awesome.

[midzer]

@My1 your proposed fix doesn't work for me on Win7 :/

To bad I had to downgrade Caddy, as IE market share is still around 9% in germany according to https://de.statista.com/statistik/daten/studie/13007/umfrage/marktanteile-der-browser-bei-der-internetnutzung-in-deutschland-seit-2009/

[My1]

okay? that kinda sux.

although I just threw a look at our little caddy and it seems to work according to ssllabs.

that image is big, so just a link here.

as you can see that caddy has just 3 ciphers in for both TLS 1.2 and 1.3

AES-GCM with SHA256 and SHA348 and chacha-poly

[mholt]

To clarify, I'm pretty sure you can still support old clients if you want to, but you have to specifically configure those cipher suites to be enabled -- they're just not enabled by default anymore.

[My1]

sure but at least from what I saw regarding supported ciphers and a quick test from SSLLabs current caddy should play nice with IE11 on standard settings provided you have an EC cert (sure, knocks anything older than vista out but better than knocking IE out as a whole)

but even then I would be in favor of a doc note which mentions a good way to throw IE11 in without blowing up security completely.

[magikstm]

@My1 I agree with your suggestion. A page detailing how to implement this would be welcomed.

It is considered a breaking change for some Caddy users and a "suggested" way to continue having the old behavior would help them maintain at least the previous level of security.

[tobya]

As previous discussed this is also an issue with safari on some older versions of iOS. I will confirm iOS version

[deanishe]

but you have to specifically configure those cipher suites to be enabled

This is the problem. Caddy's main selling point (for me, at least) is its zero-hassle handling of HTTPS.

Dropping support for a browser with ~10% market share takes the "zero" right out of the "zero hassle".

So now I have to set up TLS by hand, but unlike with nginx/apache, there's not much information out there on how to do that.

IE11 is far too popular a browser for any webserver with aspirations to not support it, imo.

[mholt]

Enabling all cipher suites is just one line:

ciphers ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-AES256-CBC-SHA ECDHE-RSA-AES128-CBC-SHA ECDHE-ECDSA-AES256-CBC-SHA ECDHE-ECDSA-AES128-CBC-SHA RSA-AES256-CBC-SHA RSA-AES128-CBC-SHA ECDHE-RSA-3DES-EDE-CBC-SHA RSA-3DES-EDE-CBC-SHA

But your configuration is weaker this way.

It's time for clients to upgrade to secure protocols and cipher suites that have been in use for a decade.

[My1]

3DES? is this an XP config?
but one thing that might be awesome would be some shorthands that allows for caddy to auto-set compatibility settings like for example:

compatibility ie11
or
compatibility xp

which would add no more than the nessecary ciphers/protocols to give those what they need.

XP would enable TLS1.0 and also add the cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA to the existing cipher list this is the only one (aside from a DHE_DSS one which is otherwise identical) that IE8 on XP that are not red insecure on ssllabs

IE11 would obviously enable TLS1.2 if not already done and add the most reasonable ciphers, probably TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256 at least IF and ONLY IF RSA certs are needed and/or used.

[midzer]

Finally, I made this to work with @My1 config suggestion from the forums:

I had to remove .caddy folder from users $HOME directory to trigger caddy refetching all those certs.

Now IE11 is supported properly (as shown in posted ssltest screenshot).

[My1]

@mholt should it be considered an issue that caddy doesnt get new certs when you change the key type?

[whitestrake]

@deanishe

Caddy's main selling point (for me, at least) is its zero-hassle handling of HTTPS.

Dropping support for a browser with ~10% market share takes the "zero" right out of the "zero hassle".

The feature focus from Caddy's perspective is "Secure by Default", not necessarily "zero-hassle".

10% market share is disappointing to have to drop by default, but the argument is that without dropping it, Caddy would be less "Secure by Default". This is a question of "opt-in insecurity" vs. "opt-in security", and given Caddy's focus, the answer is pretty obvious.

So now I have to set up TLS by hand, but unlike with nginx/apache, there's not much information out there on how to do that.

This is worded like there's an issue with information availability, but I think the problem you have is actually information prevalence, because what you want is available - the configuration is well documented and published on the official website. Specific examples are given, including on request in this thread.

Yes, you're more likely to find the exact, specific answer you're looking for with a quick Google of a simple search term + "nginx"/"apache". So many people use those servers and many ask the same common questions on many different forums across the internet. We can't really replicate that.

IE11 is far too popular a browser for any webserver with aspirations to not support it, imo.

Caddy does support IE11. You just need to configure it away from the secure defaults.

That's not to say we can't make it simple and easy to do, though. Nobody's going to argue that serving IE11 clients isn't a legitimate use case any more. So the idea of a shorthand for compatibility - given the market share of this particular client - makes sense to me as a feature request. And, yeah, Caddy probably should be designed to retrieve new certs when you change the key type...

[My1]

by the way might it be a good idea to make EC certs the default already? I mean at least on Windows you have to go back to XP for not being able to use EC certs (and that is only if you are on IE, use firefox and you can go for EC as far as I remember), and as confirmed by @midzer already, with EC certs we can both keep CBC chipers FAR away from our setup as well as still have IE support, on top EC usually means less overhead.

sounds like a great deal to me...

by the way according to GlobalSign ECC is available from
Browsers (all except FF need an ECC compatible OS)
IE7
Safari 4
Firefox 2
Chrome

OS:
Vista
Mac 10.6
Android 4

while they don't have iOS listed I wouldnt worry about those too much to be honest.

[deanishe]

Enabling all cipher suites is just one line:

Thanks. My sites are accessible again now.

It's not the number of lines, it's knowing what to put in them. Crypto is hard, and caddy made it something I didn't have to think about because it Just Worked. It doesn't Just Work any more because it no longer supports a browser that is regrettably still popular.

But your configuration is weaker this way.

OTOH, it works for everyone.

It's time for clients to upgrade to secure protocols and cipher suites that have been in use for a decade.

I agree, but until they do, those of us running webservers have to suck it up.

[mholt]

@My1 Yes, I think you are right, it is probably time to switch to EC certificates as the default. Will try to do that before 1.0. (Pull request, anyone?)

[My1]

@mholt before anyone does a PR on this, wouldn't it be a good Idea to choose whether we are going for p256 or p384? (personally I would say p384 because more security but there's probably a reason why RSA defaults to 2048, notably device power)

[mholt]

We'll do p256.

[My1]

okay. after searching in caddy to no end yesterday, I pulled up Agent Ransack today just to note that Certmagic was the one at fault here -> caddyserver/certmagic#37

I successfully compiled caddy using the fix

here is a compiled exe, along with a caddyfile that was used but removed any domains.

caddy.zip

[My1]

so as mholt fixed it. future releases (or just self compiling master) should run this fix fine.

that way we won't need to actively weaken the crypto for IE11.