SSG your forum TLS configuration is as old as Android 4.4

[alwaysbroke]

At the time when the internet migrated to TLS 1.3 it was noted: TLS 1.2 is a mess, and people still using TLS 1.2 would likely do it wrong. There's so many ways to do HTTPS wrong with TLS 1.2. I just never thought I'd see it on a site I use. I once said that SSG's TLS configuration is okay. I take it back now.

SSG please check your server configuration on SSL Labs and compare it to any other secure website. Compare yourself to Facebook's configuration, or Mozilla's. Do you know what you'll find? You'll find:

You don't support Windows XP, you don't support Windows 7. Yet your TLS configuration is so old you could comfortably support Android 4.4 and Windows XP without much difficulty. Your TLS configuration is so old you still use ciphers with a DH parameter size of 1024.

Your first two preferred ciphers date back to Android 4.4 and they both use Diffie-Hellman for key exchange, not ECDH. DHE is known to consume more bandwidth than ECDH in addition to requiring more compute resources.

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

For your reference all "modern" web browsing device support ECC in some form. Devices which do not support elliptic curve have all been recycled because they're useless.

In fact the first time we encounter ECDH in your supported list of cipher is at position #15 and #16 (out of 21 TLS 1.2 ciphers). Even worse is that positions #3 though #14 are riddled with CBC-based ciphers . It's a well known fact that only GCM-based ciphers from TLS 1.2 are considered (probably) secure (enough). Let's summarize so far, positions #1 and #2 date back to Android 4.4, then #3 though #14 are (with two exception) all using CBC which is strongly discouraged in favor of GCM alternatives. Out of 21 TLS 1.2 ciphers your forum server reportedly supports, only two are considered to be without known weaknesses. Those two are relegated to position #15 and #16. Which means there are more weak/old ciphers in your supported cipher list than modern/secure. Consequently you have many more ways you can fail the user of this forum site.

Every single cipher that your forum supports, and which provide forward security, are considered weak/old. Except two at position #15 and #16. Positions #8 through #14 are ciphers which do not support forward security. You literally have a block of weak/forward-secure cipher, followed by a block of weak/non-forward-secure cipher, followed by the only ECDH ciphers with forward security (and they're also the only ones not considered weak overall).

Let's look at mitigating protocol factors: Your forum server apparently supports Secure Renegotiation. A feature which is known to be broken unless you use/support TLS 1.3. I mean there are literal CVE that deal with the brokenness of secure renegotiation. It doesn't work properly unless you use TLS 1.3. Your forum is limited to TLS 1.2. Which means you have a garbage dump of supported TLS ciphers, and you support secure renegotiation, on TLS 1.2. The correct solution is to disable secure renegotiation unless using TLS 1.3. How secure do you really think a cipher, from circa Android 4.4, is going to be when initialized with a DH parameter of size 1024. That's rhetorical.

Your server apparently supports Downgrade prevention via TLS_FALLBACK_SCSV. Which would be wonderful if your TLS configuration were more modern. Heck if you even supported TLS 1.2 in a secure way this could be useful. That would require getting rid of any CBC-based ciphers, which you don't do. So you don't do TLS 1.2 correctly, and thus downgrade prevention won't work properly.

Overall, with the exception of two ciphers at position #15 and #16, you have weak forward security. You have an unbelievable 14 ciphers to choose from, which are all weak for forward security, before reaching the two that might be considered secure from a yr-2015 perspective.

This configuration is broken so many ways I struggle to find one thing right. To continue using TLS 1.2 would, at a minimum, require that you understand to configure GCM instead of CBC-based ciphers. Then you would have to consider the overhead from your first two (DH preferred) cipher compared to any modern ECDH-based cipher. I think the only solution would be to support TLS 1.3 because of sane-defaults.

SSG, please consider your server configuration at SSL Labs. Please also consider how your result compares unfavorably with (any) alternatives. Mozilla has a nice server configuration generator, along with guidelines:

https://wiki.mozilla.org/Security/Server_Side_TLS

Your compatibility is "old" due to your support for ciphers with a DH-parameter size of 1024. You don't even support the game running on devices this old.

This configuration is compatible with a number of very old clients, and should only be used as a last resort.

Mozilla is saying the LOTRO forums need a TLS configuration update. TLS 1.3 will help by setting sane defaults. Until then, there's no way I'm connecting my in-game accounts with the forum. This is genuinely upsetting to see. It makes me wonder what you're doing with in-game ciphers (using Android 4.4 ciphers probably).

Edit: SSG, this TLS configuration is so old, a modern browser ends up connecting with cipher 0x9d. That's TLS_RSA_WITH_AES_256_GCM_SHA38 4. In case you haven't checked a list of TLS cipher:

https://wiki.mozilla.org/Security/Cipher_Suites

That's at the bottom of the list of intermediate compatibility. This list is sorted by security provision. The green at the top is all TLS 1.3, and the yellow is TLS 1.2 ciphers. The farther down the list you go, the less recommended the cipher. This selection of 0x9d means the secure connection lacks forward security. That's how outdated your TLS configuration is. During the connection handshake my browser tells your forum server "I support these ciphers", your forum server responds with "lets use the least secure 0x9d". It's absurd.

Look at the top of the list. What do you see for the first and second "yellow" (TLS 1.2) cipher?

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

This means the forum server "claims" to support a cipher from Android 4.4 which is still considered (probably) secure. The forums server claims this is the most preferable (it's position #1 and #2). It (your forum server) instead chooses the least preferable, less secure cipher. One which is lacking forward security. So the problem is even worse. Not only is your forum TLS configuration outdated, it chooses the least secure option, in spite of having better options. That means your TLS configuration isn't just old, you're also using old OpenSSL. The reason the server chooses the less secure option is due to the outdated OpenSSL which is not compatible with modern browsers.

[DavidmeetHal]

Is this part of the reason why my forum page often will not load up on Google, Edge, and Safari? I have this issue on 3 different browsers on my PC and phone.

[alwaysbroke]

Is this part of the reason why my forum page often will not load up on Google, Edge, and Safari? I have this issue on 3 different browsers on my PC and phone.

Probably not. The issue I'm discussing in the OP has to do with an old TLS configuration. It will typically manifest itself as a weak cipher selection made in spite of more secure alternatives.

I actually only started looking at this part after looking at VPN IP address blocklists. I made a thread to point out the issue to anyone using a VPN. Then I noticed when everything appears to be working, it's actually not all okay. So what you would actually see (in this case) is your browsers will work, but the cipher is weak. If it's multiple browser, and you're using a VPN, I would treat it like a VPN IP being blocked. If you're not using a VPN there's still one more issue (which I've not investigated yet).

This bug maybe: You're looking at a thread, you decide to sign-in to comment, done. You get redirected (sometimes) back to the thread (great). Only you find the redirect doesn't load and in your address bar you'll see two things. You'll see the original address, and you'll see a new addition "&s=a645d33b6759470cd23498..." . Like a new parameter added to the url. If you delete the parameter, leaving the original address, everything loads okay. With the parameter though...not loading.

What do those three browser say? Any error message? Is there any new parameter added to the url?

[DavidmeetHal]

On my phone I get taken to a blank page on Safari when logging in or hitting submit on a post. And after that I have to recycle once and sometimes twice to get the page to load up.

I get the error messages on a white screen on my PC with Edge and Google, but I’m on my phone right now, and won’t be home for a while.

Thanks for the response and explanation!

[alwaysbroke]

No worries. Thanks to your comment I realized I should update my other thread with a bunch of different browser results.

I can confirm the blank page you see on Safari Mobile is not related to a VPN IP block. That would generate a different error message. It's also not related to the issue from this thread's OP. It may be you're experiencing the forum bug due to extra parameter. When you experience the issue next time check the address bar for any additional parameter at the end (like &s=...).