An ExtraHop trainer was recently visiting a customer and observed SSL/TLS sessions with the version set to "Other" in our SSL/TLS metrics. I was asked about what this might be and wasn't sure. My first stop was to check out metrics from our office network. Sure enough, "Other" was the third most popular SSL/TLS version listed, behind TLS 1.2 and TLS 1.3. Interesting!
Switching to the records view, I filtered on SSL Open records, selecting those with "Other" as the version. I noticed something right away: all the hosts involved were Facebook-owned domains: edge-mqtt.facebook.com, www.facebook.com, video-sea1-1.xx.fbcdn.net, scontent-sea1-1.xx.fbcdn.net, lithium.facebook.com, graph.facebook.com, graph.instagram.com, i.instagram.com, external-sea1-1.xx.fbcdn.net, etc.
I pick one of the records and click on the link to go to the packets view. Another click and I'm downloading a packet capture and launching Wireshark.
The ClientHello version is set to 1.2, but these days that doesn't tell us the full story. For unfortunate yet necessary reasons, TLS 1.3 sets the ClientHello version to the TLS 1.2 value, and introduced an extension called supported_versions where the real list of supported TLS versions appear. Sure enough, there's a supported_versions extension here, and it contains the value for TLS 1.3: 0x0304, which we recognize. Another version is also listed, though: 0xfb1a. Huh.
The ServerHello response also has a supported_versions extension and the version the server selected is (unsurprisingly at this point) 0xfb1a. That's why we report the version as "Other": this is not a version we recognize!
So what's TLS version 0xfb1a? After some hunting around I came across a mention of this value in Facebook's TLS 1.3 implementation called Fizz, which they open sourced it last August. Here's the announcement.
Fizz includes custom TLS versions. Here's where 0xfb1a is defined. Looks like 0xfb1a corresponds to TLS 1.3 draft 26 (the real draft version is 0x7f1a). There's a function that maps from their custom versions to the real versions.
Mystery solved, but I was curious as to the point of having a custom TLS version. This function offers a good clue:
"Early data" is a new feature in TLS 1.3 also known as 0-RTT. It can make some things faster but also comes with some risks. Looks like Fizz can be configured to always initially allow or disallow early data or initially allow early data but only if the TLS version used is one of their custom TLS versions. Interesting. Why Facebook felt they needed this functionality is a good question for Facebook!
Starting with ExtraHop 7.5 we added labels for these versions using the same labels Fizz uses. Version 0xfb1a will show up as "TLSv1.3-draft-26-fb" instead of "Other".
In looking around, we saw that the excellent TLSfingerprint.io, which looks at TLS network traffic at the University of Colorado Boulder, also shows the custom Facebook versions on their "Top versions", and that the fine folks at Suricata also noticed Facebook's custom TLS versions. Has anyone else noticed?
If you're interested in digging further into TLS 1.3 implementation and best practices, we actually recently spoke with top researchers at EMA about TLS 1.3 and how it affects incident response—watch the recorded webcast here.