[Suggestion] Update Server-Client from TLS 1.2 to TLS 1.3

TLS 1.2 was released in 2008, and since then outdated with the release of TLS 1.3 in 2018, patching a slew of vulnerabilities and optimizing authentication handshakes down to a third of the former version.

Current traffic between client and server is roughly 25% handshake and reauthentication. By upgrading, you will have effectively reduce authentication packet traffic to about 8% total traffic in the SIPs Session!

There are 898 CVE Record Exploits & Vulnerabilities for TLS 1.2 and SSL+...

What are some important SSL and TLS vulnerabilities?

A number of outdated cryptography features resulted in vulnerabilities or enabled specific kinds of cyber attacks.

Here is a non-exhaustive list of TLS 1.2 cryptography weaknesses, and the vulnerabilities or attacks associated with them.

RSA key transport: Doesn’t provide forward secrecy
CBC mode ciphers: BEAST and Lucky 13 attacks
RC4 stream cipher: Not secure for use in HTTPS
Arbitrary Diffie-Hellman groups: CVE-2016-0701
Export ciphers: FREAK and LogJam attacks
A lot of TLS 1.2 features have been removed in addition to those listed above. The idea is to make it impossible for someone to enable the vulnerable aspects of TLS 1.2. This is somewhat like when the government made it illegal to manufacture new cars without seatbelts: The goal of the regulations was for seatbelt-less cars to be phased out so that everyone would be safer. For a while, drivers could still choose to use older car models and be less safe, but eventually those more dangerous cars disappeared from the roads.

Easy optimization and might solve some hacking issues too!

List: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=TLS

Notes: SIPS Session Initiation Protocol is a signaling protocol used for initiating, maintaining and terminating real-time sessions

Wrel, PM me for an invoice.

And what client are you going to use here, Chicken Little?

The whole industry has just now bumbled from TLS 1.0 to 1.2. not all Windows clients aren't even using TLS 1.3 so if the server requires it then voila ... TCP Reset after the TLS Server Hello.

I do not think this is true. Where did you find this?

The TLS used by the client is just for launcher and initial auth. There is no optimization needed for basically a one off process.

The SIP traffic is not using TLS at all. The sip verbs are clear text on the wire. You would know this if you looked at the traffic.

And even if it were, SIP is only the signaling protocol. They are using part of the features of a SIP dev kit. It does registration and provides a wrapper for whatever SDP payloads they are using. May be some signalling for the various channel joins and such, I assume but haven't looked. BUT... again it's just the signaling. Media is going to flow out of band over some RTP or possibly SRTP (which is a joke since the keys are in unencrypted SIP payloads) via out of band UDP.

And this has nothing to do with the actual gamedata. This is all just VOIP related, and not even the media at that!

If you can find some specifics about how daybreaks implementation of TLS is vulnerable, by all means open a support ticket (not public forum post).

Until then I see no benefit whatsoever in this recommendation.

Don't bother with the invoice, you couldn't afford it.

Note: You could harmlessly ADD TLS 1.3 to the server. Removing TLS 1.2 would be a disaster.

You've already lost credibility with this. Honestly, for future reference, don't try to belittle an industry professional on open and expect someone to take your reply as serious. I'm a professional, so I will take the high road on your response, but in true form, will not receive another reply on this topic.

Wrong. TLS 1.3 has been around for a while and it's the current industry standard.

Wireshark packet captures during several sessions.

Wrong. During session handshakes occur as well.

I used the incorrect term for session traffic. My mistake. It is in reference to the entire game session, not just the launcher.

Correct, I misused SIP in this instance, however reference above.

There are over current 800 exploits in TLS 1.2. Take your pick.

I know you don't.

I would never contract you for anything remotely close to system engineering and cybersecurity.

For your own reading on the topic:
Implementation and Industry Standard:
https://csrc.nist.gov/publications/...ssing-visibility-challenges-with-tls-13/final

https://csrc.nist.gov/News/2019/nist-publishes-sp-800-52-revision-2

Nice watered down blog on importance of TLS 1.3:
https://beaglesecurity.com/blog/article/importance-of-tls-1-3-ssl-and-tls-vulnerabilities.html


Brief watered down article on TLS 1.3 over 1.2:
https://www.a10networks.com/glossary/key-differences-between-tls-1-2-and-tls-1-3/

https://www.supportpro.com/blog/tls-1-3-for-more-faster-and-secure-internet/


A Faster TLS Handshake
TLS encryption and SSL decryption require CPU time and add latency to network communications, somewhat degrading performance. Under TLS 1.2, the initial handshake was carried out in clear text, meaning that even it needed to be encrypted and decrypted. Given that a typical handshake involved 5 – 7 packets exchanged between the client and server, this added considerable overhead to the connection. Under version 1.3, server certificate encryption was adopted by default, making it possible for a TLS handshake to be performed with 0 – 3 packets, reducing or eliminating this overhead and allowing faster, more responsive connections.

Wrong.

TLS 1.3 is NOT easily backwards compatible with TLS 1.2 without an application mod to ensure all sessions remain encrypted.
The one side would attempt to run the session unencrypted TLS 1.2 and TLS 1.3 would reject it since TLS 1.3 has mandatory encryption. Would be simply better engineering and business decision to just upgrade to TLS 1.3.

Take a look at:

https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-compatibility-risks-known-issues


"TLS 1.3 Not Directly Compatible with Previous Versions
TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to consider when upgrading to TLS 1.3:

TLS 1.3 uses a half-close policy, while TLS 1.2 and earlier use a duplex-close policy. For applications that depend on the duplex-close policy, there may be compatibility issues when upgrading to TLS 1.3.
The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application may use unsupported signature algorithms.
The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot negotiate a TLS 1.3 connection.
The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and earlier. If an application hardcodes cipher suites that are no longer supported, it may not be able to use TLS 1.3 without modifications to its code, for example TLS_AES_128_GCM_SHA256 (1.3 and later) versus TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (1.2 and earlier).
The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and earlier. The compatibility impact should be minimal, but it could be a risk if an application depends on the handshake details of the TLS protocols."

*sigh*
You are so sure of yourself.

It doesn't have to be backwards compatible.

If you add TLS 1.3 to a server that already has TLS 1.2 it will accept client connections from both TLS 1.2 and 1.3 clients.

If you try to replace TLS 1.2 with 1.3 then a TLS 1.2 client will simply get a TCP Reset in response to a TLS Client Hello.

So yeah. EXACTLY what I said... "Note: You could harmlessly ADD TLS 1.3 to the server. Removing TLS 1.2 would be a disaster."

Oh boy. Be careful. If you start playing that card someone else might play theirs. Not all "industry professionals" are the same. Let your words and ideas speak for you.

LOL sure thing buddy. Here's a fiddler excerpt from a connection to this obscure website...

CONNECT www.google.com:443 HTTP/1.1

Host: www.google.com:443

Connection: keep-alive

User-Agent: xxx

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.3 (TLS/1.2)

Just like IPv6. We're working on it but the world is not at TLS 1.2 yet. The kicking and screaming about TLS 1.0/1.1 just died off a few years ago.

Show me. Show me how the UDP gamedata and the UDP voice data which constitutes the vast majority of the traffic is secured by TLS.

Something something industry professional...

It doesn't work that way. Show me which one is applicable and can be exploited, and what the exploit would accomplish. No chicken little stuff. Actionable.

I am probably providing support to whatever company or govornment you already work for. Doubt you would know though.

I cannot begin to tell you how much this mansplaining cracks me up. Thank you.

Like I'm sitting here with source code to actual TLS implementations and several SIPstack implementations. I'm not working on either at the moment but have a memory dump opened where the callstack in the crashing thread is down inside some 3rd party network driver. I don't have source or symbols to it so it's all disassembly and hair pulling. I'll figure it out eventually but it's got me stressed the **** out. So this whole thing has given me a chance to vent and chuckle. Thank you.

Your suggestion to implement TLS 1.3 is ... nice?

I don't see where it buys anything at all though. It won't make the game one bit faster. Users wouldn't even notice the shortening of the sign in. And there is no exploit I see threating the game that would warrant the: code time, test time, and regression risk to a whole large section of the playerbase.