x509.log
In the last section we looked at Zeek’s ssl.log
, a source which offered
details on TLS connections. In this section we will look an associated source,
Zeek’s x509.log
. The x509.log
captures details on certificates
exchanged during certain TLS negotiations. We will compare sessions using TLS
1.2 and TLS 1.3
For details on all of the fields in the x509.log
, please refer to
X509::Info
.
Inspecting the x509.log
When TLS 1.2 Applies
In the following example, we return to the traffic generated by Curl using TLS
1.2. For reference, here is the ssl.log
entry for that activity.
{
"ts": 1598377391.921726,
"uid": "CsukF91Bx9mrqdEaH9",
"id.orig_h": "192.168.4.49",
"id.orig_p": 56718,
"id.resp_h": "13.32.202.10",
"id.resp_p": 443,
"version": "TLSv12",
"cipher": "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"curve": "secp256r1",
"server_name": "www.taosecurity.com",
"resumed": false,
"next_protocol": "h2",
"established": true,
"cert_chain_fuids": [
"F2XEvj1CahhdhtfvT4",
"FZ7ygD3ERPfEVVohG9",
"F7vklpOKI4yX9wmvh",
"FAnbnR32nIIr2j9XV"
],
"client_cert_chain_fuids": [],
"subject": "CN=www.taosecurity.com",
"issuer": "CN=Amazon,OU=Server CA 1B,O=Amazon,C=US"
}
This ssl.log
entry mentions four cert_chain_fuids
, or certificate
identifiers. We see each of them in the following entries in the corresponding
x509.log
data:
{
"ts": 1598377391.938343,
"id": "F2XEvj1CahhdhtfvT4",
"certificate.version": 3,
"certificate.serial": "0B58BC3898391F36592BA1BE1F6B03EF",
"certificate.subject": "CN=www.taosecurity.com",
"certificate.issuer": "CN=Amazon,OU=Server CA 1B,O=Amazon,C=US",
"certificate.not_valid_before": 1590969600,
"certificate.not_valid_after": 1625140800,
"certificate.key_alg": "rsaEncryption",
"certificate.sig_alg": "sha256WithRSAEncryption",
"certificate.key_type": "rsa",
"certificate.key_length": 2048,
"certificate.exponent": "65537",
"san.dns": [
"www.taosecurity.com",
"taosecurity.com",
"*.taosecurity.com"
],
"basic_constraints.ca": false
}
{
"ts": 1598377391.938343,
"id": "FZ7ygD3ERPfEVVohG9",
"certificate.version": 3,
"certificate.serial": "067F94578587E8AC77DEB253325BBC998B560D",
"certificate.subject": "CN=Amazon,OU=Server CA 1B,O=Amazon,C=US",
"certificate.issuer": "CN=Amazon Root CA 1,O=Amazon,C=US",
"certificate.not_valid_before": 1445472000,
"certificate.not_valid_after": 1760832000,
"certificate.key_alg": "rsaEncryption",
"certificate.sig_alg": "sha256WithRSAEncryption",
"certificate.key_type": "rsa",
"certificate.key_length": 2048,
"certificate.exponent": "65537",
"basic_constraints.ca": true,
"basic_constraints.path_len": 0
}
{
"ts": 1598377391.938343,
"id": "F7vklpOKI4yX9wmvh",
"certificate.version": 3,
"certificate.serial": "067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6",
"certificate.subject": "CN=Amazon Root CA 1,O=Amazon,C=US",
"certificate.issuer": "CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\\, Inc.,L=Scottsdale,ST=Arizona,C=US",
"certificate.not_valid_before": 1432555200,
"certificate.not_valid_after": 2145834000,
"certificate.key_alg": "rsaEncryption",
"certificate.sig_alg": "sha256WithRSAEncryption",
"certificate.key_type": "rsa",
"certificate.key_length": 2048,
"certificate.exponent": "65537",
"basic_constraints.ca": true
}
{
"ts": 1598377391.938343,
"id": "FAnbnR32nIIr2j9XV",
"certificate.version": 3,
"certificate.serial": "A70E4A4C3482B77F",
"certificate.subject": "CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\\, Inc.,L=Scottsdale,ST=Arizona,C=US",
"certificate.issuer": "OU=Starfield Class 2 Certification Authority,O=Starfield Technologies\\, Inc.,C=US",
"certificate.not_valid_before": 1251849600,
"certificate.not_valid_after": 2035129156,
"certificate.key_alg": "rsaEncryption",
"certificate.sig_alg": "sha256WithRSAEncryption",
"certificate.key_type": "rsa",
"certificate.key_length": 2048,
"certificate.exponent": "65537",
"basic_constraints.ca": true
}
These four certificates offer a lot of detail for defensive teams. Defenders can search their data repositories for values that appear in other certificates, perhaps identifying associations among intruder activity patterns.
Inspecting the x509.log
When TLS 1.3 Applies
In the following example, we return to the traffic generated by Curl using TLS
1.3. For reference, here is the ssl.log
entry for that activity.
{
"ts": 1598983678.585087,
"uid": "CcJfBs3hXLJn7oHVu7",
"id.orig_h": "192.168.4.142",
"id.orig_p": 58802,
"id.resp_h": "13.32.202.2",
"id.resp_p": 443,
"version": "TLSv13",
"cipher": "TLS_AES_128_GCM_SHA256",
"curve": "x25519",
"server_name": "www.taosecurity.com",
"resumed": true,
"established": true
}
Notice that we see no reference to file identifies for certificates. That means
there is no x509.log
for TLS 1.3! (The section title was a bit of a trick
question.)
Remember from the previous material that when ESNI or ECH are in play, the
server name field in the ssl.log
is also missing.
Conclusion
This section showed that the default x509.log
provides several details of
interest to defenders, even when inspecting encrypted traffic. As
administrators and intruders deploy newer encryption technologies, however,
defenders will find it increasingly difficult to differentiate among normal,
suspicious, and malicious traffic.