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.