Hi,
I'm researching ja3 and ja3s tls signatures.
With resumed tls connections there is no complete
handshake etc. Does it make sense to calculate a ja3
on resumed tls ?
Regards,
Daniel
Hi Daniel,
unless I am missing something, there should be no difference in the signature of a resumed and a new connection for JA3. I don’t remember them hashing anything in that has to do with session resumption.
Johanna
Hi Johanna
I was thinking the same but after the results i became insecure about this.
I have attached 2 examples.
Daniel
Example 1
resumed false
{
"cipher": "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"established": true,
"client_cert_chain_fuids": "[]",
"curve": "secp256r1",
"issuerdn": "CN=DigiCert ECC Secure Server CA,O=DigiCert Inc,C=US",
"ja3s": "7d3eb4120cd50e889bcd3f3783be0f82",
"subject": "CN=*.adnxs.com,O=AppNexus\\, Inc.,L=New York,ST=New York,C=US",
"cert_chain_fuids": [
"FwvSeKet5kqNoujSf",
"FNxask2v3HjNVTB5ff"
],
"dest_asname": "AppNexus, Inc",
"next_protocol": "http/1.1",
"type": "tls",
"version": "TLSv12",
"sni": "ib.adnxs.com",
"src_ip": "192.168.1.93",
"src_port": 58443,
"uid": "Cfc50Q1EnIW0GAYWch",
"dest_ip": "37.252.172.40",
"validation_status": "ok",
"resumed": false,
"ja3": "b20b44b18b853ef29ab773e921b03422",
"dest_port": 443,
"timestamp": "2018-12-16T17:16:44.801Z"
}
next resumed true
{
"cipher": "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"established": true,
"ja3s": "02bdc318d9f618eea3e10d0a7ba25ba0",
"dest_asname": "AppNexus, Inc",
"next_protocol": "http/1.1",
"type": "tls",
"version": "TLSv12",
"sni": "ib.adnxs.com",
"src_ip": "192.168.1.93",
"src_port": 58446,
"uid": "CyYQVc1FuxLDABqxpj",
"dest_ip": "37.252.172.40",
"resumed": true,
"ja3": "334da95730484a993c6063e36bc90a47",
"dest_port": 443,
"timestamp": "2018-12-16T17:16:45.071Z"
}
Example 2
resumed false
{
"cipher": "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"established": true,
"client_cert_chain_fuids": "[]",
"curve": "secp256r1",
"issuerdn": "CN=DigiCert ECC Secure Server CA,O=DigiCert Inc,C=US",
"ja3s": "cabc8aadc20a64fa7156022319d177c0",
"subject": "CN=*.adnxs.com,O=AppNexus\\, Inc.,L=New York,ST=New York,C=US",
"cert_chain_fuids": [
"FCxxdLhSpJHRDMYv4",
"FYW4Fs3VrkciMfUhc6"
],
"dest_asname": "AppNexus, Inc",
"next_protocol": "http/1.1",
"type": "tls",
"version": "TLSv12",
"sni": "secure.adnxs.com",
"src_ip": "192.168.1.93",
"src_port": 55912,
"uid": "CvUDsF40fhpESTJlLd",
"dest_ip": "37.252.172.40",
"validation_status": "ok",
"resumed": false,
"ja3": "5c118da645babe52f060d0754256a73c",
"dest_port": 443,
"timestamp": "2018-12-27T15:43:45.898Z"
}
resumed true
{
"cipher": "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"established": true,
"ja3s": "93174bff9e6f484d06ff9552fe757554",
"dest_asname": "AppNexus, Inc",
"type": "tls",
"version": "TLSv12",
"sni": "secure.adnxs.com",
"src_ip": "192.168.1.93",
"src_port": 55927,
"uid": "Ctr8MRZepl9Z0r6E6",
"dest_ip": "37.252.172.40",
"resumed": true,
"ja3": "7b1ac424884b798ca987e3e27b99d1a8",
"dest_port": 443,
"timestamp": "2018-12-27T15:43:46.019Z"
}
Hey Daniel! I can help here. So when a TLS session resumes there is still a Client Hello packet, however the details can be different in the resuming hello packet vs the original, producing a different JA3, which will produce a different response from the server and therefore a different JA3S.
Capturing this with JA3 is by design. There could be interesting unique qualities to the resumed negotiations vs the original that could assist in building more complex detections. The fact that Zeek is able to differentiate between new and resumed connections makes it so you can use this data however you want, or ignore it completely. The power of networking metadata is in your hands.
John Althouse
So far ..
First I use a mac with firefox to generate pcap (could be something).
The hashing uses the ssl extensions, cipher and version.
The server extensions at the first connection contains all options
the server can use, but on a resumed connection it uses only the
negociated extensions. For this reason the ja3s for a resumed false
is different from a ja3s with resumed true. This is the same for clients.
If the extensions are stored when the tls connection resumed flag
is false. It could be used for a resumed connection, after a check if
one of the offered extensions is used..., to calculate the ja3s.
Hi,
I have made a change to the j3s script. It stores the server extensions in a table
with the server_name. When a tls connection is resumed it uses the stored extensions.
Result, resumed tls has the same ja3s as none resumed.
Regards,
Daniel
ja3s.bro: