This message was deleted.
# _general
s
This message was deleted.
d
I don't have an answer, but you could force disabling specific ciphers by launching Chrome with the --cipher-suite-blacklist= option in the mean time?
d
Sadly, no. Chromium decided not to allow that for 1.3 ciphers. https://bugs.chromium.org/p/chromium/issues/detail?id=1502090#c2
â˜šī¸ 1
Oh, just to share a cool site I found along the way... If you ever need it and don't already know about it... https://www.howsmyssl.com/
🙏 1
j
n
sounds like a borked chromium update since chrome and edge are essentially the same product. this just started happening i'm guessing?
d
@jvitech Thanks for the link. I did try that, but that only seems to apply to TLS 1.2 at this point from my testing anyway. Also, Chrome and Edge do not adhere to all of the TLS 1.2 cipher suites listed and will add additional ones, including CHACHA20 with higher priority than the ones from the policy. IE, which no one really cares about any more of course, does manage to use the order provided, but of course doesn't support TLS 1.3. @Nick Casagrande I don't believe there is anything broken with the Chrome and Edge installations. It is just a selection order of the TLS 1.3 cipher suites that Chromium chooses to manage internally and not give any sort of control over to the user. It is my understanding that CHACHA20 is supposed to be more for mobile device use, but most of our servers are choosing that as the top cipher suite. This didn't just start happening...It is really an issue with one website that claims they support CHACHA20 in the TLS 1.3 negotiation process, but then never fully completes the negotiation. I am just trying to work around the broken website by having Chrome/Edge prefer a different cipher suite.
👍 1
Edge and Chrome cipher suites offered:
s
I just put their site through the ssllabs test, https://www.ssllabs.com/ssltest/analyze.html?d=tncourts.gov&hideResults=on you can see the preference in teh cipher suites they support, guessing as long as those cipher suites match your endpoints, you should be good.
d
@Steve Noel Understand what you are saying. I put them through SSLLabs as well and told the site owners via email they aren't properly supporting CHACHA20, haven't heard back from them yet. The problem is their Change Cipher Spec, Client Hello says to use CHACHA20 in a Network trace. But then they don't complete the negotiation properly.
s
yeah, that chacha20 is new to me, never seen that before, msut be needed for something specific in your environment?
lol, just noticing chacha and grease is the word ciphers, ok wtf is that...
d
Also, the vast majority of that stuff I learned yesterday troubleshooting this.
s
too funny, ah, so the chacha is the same thing, well dang. Still think maybe reordering the certs from the client is probably the way to go. So maybe try putting this cipher to the top of the list.
d
That's the crux of the question. I can't find anyway to control TLS 1.3 cipher suite order in Chromium.
l
Have you tried to move a Citrix server to some other OU? Have you tried with a local account? Just to see if some gpo is causing this
s
pretty sure it's just the normal windows cipher GPO
d
We are trying not to disable TLS 1.3 in the client browser, but that is an option to work-around the issue. @Lennart Hermansson We have servers in several different OUs, moving client servers to other OUs is problematic, but I may be able to move a test server to the same OU as servers that are advertising different cipher suite order (same cipher suites, just different order). That's a good idea. I looked through Group Policy and there's nothing I can see that should be controlling things though. I have not attempted a local user either, just domain users, but the same domain user on all of the systems where some work and some don't, so figured there's nothing GPO related to the user account. @Steve Noel See above comments where the normal Windows GPO doesn't seem to apply to TLS 1.3 ciphers suites in Chromium.
s
ah, sorry Dennis
đŸ’¯ 1
m
https://www.theregister.com/2023/12/20/terrapin_attack_ssh/?td=rt-3a "ChaCha20-Poly1305 is said to be "vulnerable and perfectly exploitable" by Terrapin due to the way sequence numbers are used in key derivation. There isn't a cryptographic weakness in this algorithm, just in the way it's used for SSH." Unfortunately I can't reach the .gov site from here but I suspect we will run across similar sites soon if this is the problem.
d
@Michiel Roos Thanks for the information. Good reading, when/if I get a minute or two, I'll read it more indepth.