167 lines
5.8 KiB
ReStructuredText
167 lines
5.8 KiB
ReStructuredText
========
|
||
x509.log
|
||
========
|
||
|
||
In the last section we looked at Zeek’s :file:`ssl.log`, a source which offered
|
||
details on TLS connections. In this section we will look an associated source,
|
||
Zeek’s :file:`x509.log`. The :file:`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 :file:`x509.log`, please refer to
|
||
:zeek:see:`X509::Info`.
|
||
|
||
Inspecting the :file:`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 :file:`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 :file:`ssl.log` entry mentions four ``cert_chain_fuids``, or certificate
|
||
identifiers. We see each of them in the following entries in the corresponding
|
||
:file:`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 :file:`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 :file:`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 :file:`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 :file:`ssl.log` is also missing.
|
||
|
||
Conclusion
|
||
==========
|
||
|
||
This section showed that the default :file:`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.
|