HTTPS-enabled instance may still have 128-bit keys after upgrade

[cfm]

Description

In #6103 (comment), I found that an HTTPS-enabled instance upgraded to v2.1.0~rc1 may still use 128-bit keys rather than the 256-bit keys intended by #5988.

Steps to Reproduce

(HTTPS-only) On the Source Interface index page, verify via the Tor Browser Security Tab that the connection is encrypted not only as an Onion Service but also vi TLS 1.3 with 256-bit keys

Expected Behavior

After rerunning make self-signed-https-certs && ./securedrop-admin install, Tor Browser "Page Info" says (my emphasis):

Connection Encrypted (Onion Service, TLS_AES_256GCM_SHA384, 256 bit keys, TLS 1.3)

Actual Behavior

Tor Browser "Page Info" says (my emphasis):

Connection Encrypted (Onion Service, TLS_AES_128GCM_SHA256, 128 bit keys, TLS 1.3)

Comments

This suggests that an explicit make self-signed-https-certs && ./securedrop-admin install is necessary for #5988 to go into effect on upgrading an existing SecureDrop installation.

[conorsch]

@cfm Are you saying that the test plan for 2.1.0 should permit 128-bit keys? Or are you saying that on upgrade to 2.1.0, prod instances using HTTPS on the Source Interface may break?

[zenmonkeykstop]

As part of #5988, the Apache SSLCipherSuite directive is now not being set on fresh installs and is being removed on upgrades - it might be necessary to set it if we really want to force the expected key length. Mind you, IANACryptographer, but 128-bit AES seems good enough?

[zenmonkeykstop]

I think the test plan (ie me) is at issue here - I got 256-bit keys while working through the case the first time, so I put that in as an expectation. I don't think there's a valid reason to expect that the negotiation would always work out that way. Gonna update the plan, and I think we can close this unless there are any objections.

[cfm]

We've decided out of band that today I'll brush up on TLS 1.3 in order to confirm the conclusion in #6132 (comment).

[cfm]

My research bears out your conclusion, @zenmonkeykstop, in #6132 (comment):

I think the test plan (ie me) is at issue here - I got 256-bit keys while working through the case the first time, so I put that in as an expectation. I don't think there's a valid reason to expect that the negotiation would always work out that way. Gonna update the plan, and I think we can close this unless there are any objections.

Per RFC 8446—

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
and TLS_CHACHA20_POLY1305_SHA256 cipher suites (see
Appendix B.4).

—so both the 128-bit and the 256-bit session keys we've observed are valid.

For what it's worth, Qualys discriminates on the basis of session-key length in rating TLS endpoints, but Mozilla recommends all three cipher suites equally.