Welcome to part 2 of my three-part series on TLS. In the previous article I briefly introduced TLS, and showed how Corelight would produce logs for a clear-text HTTP session. In this article I will perform the same transaction using TLS 1.2, and compare the logs with those seen earlier. In part 3 I will repeat the experiments again, except I will use TLS 1.3.
Now that we understand how Corelight creates logs for a clear HTTP session, let’s tell Curl to use TLS 1.2. (I actually tell Curl to use “up to” version 1.2. If for some reason the Web server only supported TLS 1.1, then it would use 1.2. Pay attention to the output to see TLS 1.2 was indeed in play.)
root@freebsd12:~ # curl –resolve enabled.tls13.com:443:104.16.125.34 -v –tls-max 1.2 https://enabled.tls13.com
* Added enabled.tls13.com:443:104.16.125.34 to DNS cache
* Hostname enabled.tls13.com was found in DNS cache
* Trying 104.16.125.34…
* TCP_NODELAY set
* Connected to enabled.tls13.com (104.16.125.34) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; CN=enabled.tls13.com
* start date: Nov 16 00:00:00 2017 GMT
* expire date: Nov 21 12:00:00 2019 GMT
* subjectAltName: host “enabled.tls13.com” matched cert’s “enabled.tls13.com”
* issuer: C=US; O=DigiCert Inc; CN=DigiCert ECC Secure Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x28a25000)
> GET / HTTP/2
> Host: enabled.tls13.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200
< date: Mon, 08 Apr 2019 14:50:18 GMT
< content-type: text/html
< content-length: 140
< set-cookie: __cfduid=d7b6bdd779df7b8b73088ec361974d4f01554735018; expires=Tue, 07-Apr-20 14:50:18 GMT; path=/; domain=.tls13.com; HttpOnly
< x-amz-id-2: zr0BZddKmlY6oivxm4U6ZtAHcp0p57pMU0fzQ8QQEBuEiG5omYFmdORDNg6AZqep8JL7ByOHLDI=
< x-amz-request-id: 9FCC1A2D114AC667
< last-modified: Wed, 29 Jun 2016 00:38:23 GMT
< etag: “31e34918942105b9adeff6485029054c”
< cf-cache-status: HIT
< expires: Mon, 08 Apr 2019 16:50:18 GMT
< cache-control: public, max-age=7200
< accept-ranges: bytes
< strict-transport-security: max-age=2592000
< expect-ct: max-age=604800, report-uri=”https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct”
< server: cloudflare
< cf-ray: 4c450d8a0aa0c186-IAD
<
<html xmlns=”http://www.w3.org/1999/xhtml” >
<head
<title>Test</title>
</head>
<body>
<h1>Test</h1>
<p>Testing</p>
</body>
</html>
* Connection #0 to host enabled.tls13.com left intact
* Closing connection 0
In the output, I bolded the fact that client and server agree to speak TLS 1.2, and for a cipher they agree on ECDHE-ECDSA-CHACHA20-POLY1305. This is one of many ciphers they could use. I also bolded the server’s certificate details, showing it was issued by Cloudflare.
Now we turn to the Corelight logs, starting with the conn.log.
{"ts":"2019-04-08T14:50:16.583138Z","uid":"CPxu062o9hhnzZYgT5","id.orig_h":"192.168.40.82","id.orig_p":26102,"id.re
sp_h":"104.16.125.34","id.resp_p":443,"proto":"tcp","service":"ssl","duration":2.75764,"orig_bytes":565,"re
sp_bytes":2945,"conn_state":"SF","local_orig":true,"local_resp":false,"missed_bytes":0,"history":"ShADadfF",
"orig_pkts":15,"orig_ip_bytes":1185,"resp_pkts":16,"resp_ip_bytes":3597,"tunnel_parents":[],"resp_cc":"US","orig_l2_addr":"08:00:27:ac:ed:82","resp_l2_addr":"fc:ec:da:49:e0:10","id.orig_h.name.src":
"DNS_PTR","id.orig_h.name.vals":
["freebsd12.localdomain"],"id.resp_h.name.src":"DNS_A","id.resp_h.name.vals":["enabled.tls13.com"]}
Notice we are speaking SSL over TCP to port 443 in this case. We use the uid to look for associated logs, and omit the conn.log as we have already seen it. I reorder the logs as well to make more analytical sense.
$ zgrep CPxu062o9hhnzZYgT5 *
ssl_20190408_07:00:00-08:00:00-0700.log.gz:{"ts":"2019-04-08T14:50:17.271436Z","uid":"CPxu062o9hhnzZYgT5","id.orig_h":"192.168.40.82","id.orig_p":26102,"id.res
p_h":"104.16.125.34","id.resp_p":443,"version":"TLSv12","cipher":"TLS_ECDHE_ECDSA_WITH_CHACHA20
_POLY1305_SHA256","server_name":"enabled.tls13.com","resumed":false,"next_protocol":"h2","esta
blished":true,"cert_chain_fuids":
["FGjIRV2evoQu3d2zh","FLaFUs2tIsmg3iAQki"],"client_cert_chain_fuids":
[],"subject":"CN=enabled.tls13.com,O=Cloudflare\u005c, Inc.,L=San
Francisco,ST=CA,C=US","issuer":"CN=DigiCert ECC Secure Server CA,O=DigiCert
Inc,C=US","validation_status":"ok","ja3":"00bcd759cb8ad485fdbf1e7a0c5b94b4","ja3s":"fadba6edece
60fdceba33c02c17a0ea3"}
There’s a lot of interest in the ssl.log. Note the presence of TLS 1.2 and the aforementioned cipher. We see the server name from the HTTPS request, followed by a next_protocol field showing that “h2” was seen. This “h2” fields refers to HTTP/2 over TLS, as indicated by this reference.
After the next_protocol field we see two file IDs and then clear text entries extracted from the server public key certificate. These are the sorts of details that have become increasingly important to threat intelligence analysts as more Internet-passing traffic has been encrypted. Finally we see ja3 and ja3s hashes, profiling the client and server encryption parameters.
Our search using the original uid from the conn.log also resulted in two hits in the files.log.
files_20190408_07:00:00-08:00:00-0700.log.gz:{"ts":"2019-04-08T14:50:17.286630Z","fuid":"FGjIRV2evoQu3d2zh","tx_hosts":["104.16.125.34"],"rx_hosts":["192.168.40.82"],"conn_uids":["CPxu062o9hhnzZYgT5"],"source":"SSL","depth":0,"analyzers":["SHA256","X509","MD5","SHA1"],"mime_type":"application/pkix-cert","duration":0.0,"local_orig":false,"is_orig":false,"seen_bytes":942,"missing_bytes":0,"overflow_bytes":0,
"timedout":false,"md5":"8e5bb65c3e40463ce0e97b41705487a5","sha1":"86d44a441ab1cc7aab1f888d9
b26c8dd880058bd","sha256":"fc36cc34880c518d883a7bf1216a2216b7bd108d52986be16fd428909a5a
8ec1"}
files_20190408_07:00:00-08:00:00-0700.log.gz:{"ts":"2019-04-08T14:50:17.286630Z","fuid":"FLaFUs2tIsmg3iAQki","tx_hosts":["104.16.125.34"],"rx_hosts":["192.168.40.82"],"conn_uids":["CPxu062o9hhnzZYgT5"],"source":"SSL","depth":0,"analyzers":["SHA256","X509","MD5","SHA1"],"mime_type":"application/pkix-cert","duration":0.0,"local_orig":false,"is_orig":false,"seen_bytes":944,"missing_bytes":0,"overflow_bytes":0,
"timedout":false,"md5":"c64ae88aeb2cb31198d70483212fb411","sha1":"56ee7c270683162d83baeacc7
90e22471adaabe8","sha256":"458446ba75d932e914f23c2b57b7d192eddbc2181d958e1181ad525174
7a1ee8"}
Observe that the two file ID, or fuid, entries are the same as noted in the previous ssl.log. They are associated with public key certificates as reported by the mime_type fields.
Let’s look for each of these fuid’s in our logs. I omit the files.log and ssl.log entries as we just looked at those.
$ zgrep FGjIRV2evoQu3d2zh *
x509_20190408_07:00:00-08:00:00-0700.log.gz:{"ts":"2019-04-08T14:50:17.286630Z","id":"FGjIRV2evoQu3d2zh","certificate.version":3,"
certificate.serial":"0E4EE4E9D7DAD5E64F0BC4A7C42DFB9D","
certificate.subject":"CN=enabled.tls13.com,O=Cloudflare\u005c, Inc.,L=San Francisco,ST=CA,C=US","certificate.issuer":"CN=DigiCert ECC Secure Server
CA,O=DigiCert Inc,C=US","certificate.not_valid_before":"2017-11-16T08:00:00.000000Z","certificate.not_valid_after":"2019-11-21T20:00:00.000000Z","certificate.key_alg":"id-ecPublicKey","certificate.sig_alg":"ecdsa-with-SHA256","certificate.key_type":"ecdsa","certificate.key_length":256,"certificate.curve":"prime256v1","san.dns":["enabled.tls13.com"],"basic_constraints.ca":false}
Here we see the same certificate information noted from the Curl verbose output. Remember that we only had that information in Curl because we were essentially troubleshooting with it. This information would be lost if we were not collecting it via Corelight from the wire.
Here we look for the second file ID, omitting the files.log and ssl.log.
$ zgrep FLaFUs2tIsmg3iAQki *
x509_20190408_07:00:00-08:00:00-0700.log.gz:{"ts":"2019-04-
08T14:50:17.286630Z","id":"FLaFUs2tIsmg3iAQki","certificate.version":3,"certificate.serial":"0ACB28BA465
EE53908767470F3CDC612","certificate.subject":"CN=DigiCert ECC Secure Server CA,O=DigiCert
Inc,C=US","certificate.issuer":"CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert
Inc,C=US","certificate.not_valid_before":"2013-03-08T20:00:00.000000Z","certificate.not_valid_after":"2023-03-08T20:00:00.000000Z","certificate.key_alg":"id-ecPublicKey","certificate.sig_alg":"sha384WithRSAEncryption","certificate.key_type":"ecdsa","certificate.key
_length":384,"certificate.curve":"secp384r1","basic_constraints.ca":true,"basic_constraints.path_len":0}
This is information from the certificate that was used to sign the enabled.tls13.com certificate signed by Cloudflare. By walking this certificate chain to its root, we can see DigiCert is acting as the global root certificate for this exchange.
If we pause for a moment, we see that a TLS 1.2 secured exchange provides us with many elements for inspection, such as the nature of the certificates involved, to the ja3 and ja3s hashes (which we did not delve into here but are a topic covered in other posts and webinars).
In this article I showed how Corelight creates logs for a session conducted over TLS 1.2. In the next article I will finish the series with a look at TLS 1.3. See you then!