TLS fingerprint and mobile security

The use case

Mobile applications are replacing the traditional web applications. Some techniques are developed to identify the requests are coming from official application - which they own and not from emulators.

We have some enterprise’s features as Appcheck from Google and DeviceCheck from Apple.

These features use cryptography to validate whether requests are coming from authorized devices and applications. Despite the complexity of system design, we must revalidate messages from Google and Apple again before proceeding with any further action.

Simple solution: The JA3 - Simple TLS client’s fingerprint

JA3 is developed by Salesforce. It calculates the order of Client Hello’s fields (TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats), same client and TLS library should return the same JA3. The value depends on TLS library and client version supporting TLS cipher, extension’s order. if we own the implementation in our app, the value should be fixed for whitelisting purpose.

The implementation must be based on TLS initiation, where the application constructs the Client Hello’s fields. However if the Client Hello’s order extensions are the same, how do we check if it’s authentic? Google uses GREASE for another purpose, and we can leverage this for our purpose by adding a specific GREASE extension with our chosen ciphersuite and ALPN. It requires rewriting the JA3’s calculation, as it defaults to ignoring GREASE’s values and strictly follows the extension’s order from server side.

Since the TLS handshake is invisible to our users, it should not be relayed from malious actors. Of course, it’s weaker than Appcheck, which involves two-way validation through signed requests and platform providers like Google/Apple. Nevertheless, this is the easiest way to implement and explore some new ideas.