Customise TLS 1.3 cipher suites

[Forza]

1. Caddy version (caddy version):

caddy 2.4.5 built with xcaddy

2. How I run Caddy:

a. System environment:

Gentoo Linux, open-rc

b. Command:

caddy run

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

tnonline.net:443 {
	tls /etc/letsencrypt/live/tnonline.net/fullchain.pem /etc/letsencrypt/live/tnonline.net/privkey.pem {
		curves x25519 secp521r1 secp384r1 secp256r1
		ciphers TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_256_GCM_SHA384
	}
	log {
		output file /var/log/caddy/tnonline.net_443.log {
			roll_size 100MiB
			roll_keep_for 100d
		}
		format json
	}
	encode zstd gzip
	root * /var/www/domains/tnonline.net/htdocs/nextcloud
	
    header {
		Permissions-Policy interest-cohort=()
        Strict-Transport-Security "max-age=15768000; preload"
    }
    
	# .htaccess / data / config / ... shouldn't be accessible from outside
	@forbidden {
		path /.htaccess
		path /data/*
		path /config/*
		path /db_structure
		path /.xml
		path /README
		path /3rdparty/*
		path /lib/*
		path /templates/*
		path /occ
		path /console.php
	}
	respond @forbidden 404

	# Redirect CardDAV and CalDAV endpoints
	redir /.well-known/carddav /remote.php/dav 301
	redir /.well-known/caldav /remote.php/dav 301

	php_fastcgi unix//run/php-fpm/php-nextcloud.socket {
		# Needed to remove index.php from URLs.
		#env front_controller_active true
	}
	
	file_server
}

3. The problem I’m having:

I want to remove TLS_AES_128_GCM_SHA256 from cipher suites. However it seems the suites for TLS 1.3 are still hard coded.

TLSv1.2 (server order)
 xc02c   ECDHE-ECDSA-AES256-GCM-SHA384     ECDH 521   AESGCM      256      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 xcca9   ECDHE-ECDSA-CHACHA20-POLY1305     ECDH 521   ChaCha20    256      TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLSv1.3 (no server order, thus listed by strength)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256

4. Error messages and/or full log output:

5. What I already tried:

6. Links to relevant resources:

The following post from 2017 says that TLS cipher suites are set in stone in order to protect the user from doing harm on themselves. I don’t particularly agree. Can this limit be lifted?

Specify TLSv1.3 Cipher Suites

No. Cipher suites for TLS 1.3 are set in stone. We use Go’s stdlib for TLS facilities, and it doesn’t allow configuring cipher suites, because from a security perspective, it’s a risk to allow users to potentially shoot themselves in the foot.

[matt (Matt Holt)]

@Forza

The following post from 2017 says that TLS cipher suites are set in stone in order to protect the user from doing harm on themselves. I don’t particularly agree. Can this limit be lifted?

You’ll have to take it up with the Go team, we don’t have control here. But I agree with the Go team’s decision.

crypto/tls: TLS 1.3 ciphers are not configurable

[Forza]

@matt

But I agree with the Go team’s decision.

I do not. It effectively means that no go-based client can use AES256 with Caddy. This is imho quite an odd choice.

[matt (Matt Holt)]

Ok. Well, you can argue with the Go team on their issue tracker.

@Forza

means that no go-based client can use AES256 with Caddy

That’s not true; Go and TLS 1.3 both support AES-256.

[Forza]

@matt

That’s not true; Go and TLS 1.3 both support AES-256.

Although technically they do, they will prefer AES-128. In effect AES-256 could not be used. Of course with a client based on something else than Go, then they can negotiate AES-256 with Caddy. Just not Go clients.

[francislavoie]

Additional reading:

Automatic cipher suite ordering in crypto/tls - The Go Programming Language

Removing knobs from security software/libraries means there’s a much stronger baseline for the web to be secure. Allowing configuration is too strong a risk of users shooting themselves in the foot unless they are literally cryptographers and know what they’re doing.

The Go team has very good reasons for choosing to do it this way, and as you can see in the above article, they’ve explained why they chose that ordering.

[Forza]

Thanks for the link to the blog entry.

This though, must surely be wrong. AES-256 is not more relevant to post-quantum encryption than AES-128. They are basically saying that AES-256 isn’t useful and so does not select it.

AES-256 has a larger key than AES-128, which is usually good, but it also performs more rounds of the core encryption function, making it slower. (The extra rounds in AES-256 are independent of the key size change; they are an attempt to provide a wider margin against cryptanalysis.) The larger key is only useful in multi-user and post-quantum settings, which are not relevant to TLS, which generates sufficiently random IVs and has no post-quantum key exchange support. Since the larger key doesn’t have any benefit, we prefer AES-128 for its speed.

And

Why not make TLS 1.3 cipher suites configurable? Conversely, there is no tradeoff to make with TLS 1.3, as all its cipher suites provide strong security. This lets us leave them all enabled and pick the fastest based on the specifics of the connection without requiring the developer’s involvement.

Again this means AES-256 won’t ever be used between two Go implementations or between Caddy webbserver and clients that have no preference - unless they don’t support AES-128 or only support ChaCha.

@francislavoie

Allowing configuration is too strong a risk of users shooting themselves in the foot unless they are literally cryptographers and know what they’re doing.

In what way? I wanted to use AES-256 or ChaCha in my own private setup, and with Caddy I cannot because of this choice.

[francislavoie]

@Forza

In what way? I wanted to use AES-256 or ChaCha in my own private setup, and with Caddy I cannot because of this choice.

But why? There’s really no good reason to use anything but the defaults. You gain nothing in terms of security or performance.

[Forza]

Does AES-256 have no security advantages over AES-128? I’ve heard that before and I am a little surprised that AES-256 keeps existing if that is the case. From what I read, AES-256 uses a different key exchange schedule, which could be considered weaker, not that there seems to be any viable attack there yet? Another New AES Attack - Schneier on Security

But to answer your question. Personally, I’d like to choose higher bits if it is has higher security , however little the benefit is.

[francislavoie]

@Forza

Does AES-256 have no security advantages over AES-128?

For TLS, no. Because it’s all transactional traffic, the raw TLS bytes are not stored somewhere long-term, etc. AES-128 is just faster, which is more desirable for TLS traffic.

Mozilla decided to prioritize 128 over 256 because they thought there was less potential risk of timing attacks, and the performance trade-offs were not worth it.

Confusing rationale

(bunch of various discussion in links you can click through from that issue)

The point is, if you’re not a cryptographer, don’t spend time worrying about this. Let them do their jobs and pick the right defaults, because they know better. They’ve studied this stuff for years upon years.