Zeek
Investigating the effects of TLS 1.3 on Corelight logs, part 2
In part 1, I showed how Corelight would produce logs for a clear-text HTTP session. In part 2, I perform the same transaction using TLS 1.2.
Introduction
Welcome to part 3 of my three-part series on TLS. In the previous two articles I briefly introduced TLS, and showed how Corelight would produce logs for a clear-text HTTP session. I then performed the same transaction using TLS 1.2, and compared the logs with those seen earlier. In this final post I will repeat the experiments again, except I will use TLS 1.3.
TLS 1.3
Finally we reproduce our experiment using TLS 1.3. Remember that we have been visiting the Web site enabled.tls13.com, first without encryption, then later with TLS 1.2.
root@freebsd12:~ # curl –resolve enabled.tls13.com:443:104.16.125.34 -v –tls-max 1.3 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.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* 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: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200
< date: Mon, 08 Apr 2019 14:50:28 GMT
< content-type: text/html
< content-length: 140
< set-cookie: __cfduid=d2c2d871edc2da4808cd214c9956e802b1554735028; expires=Tue, 07-Apr-20 14:50:28 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:28 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: 4c450dc90963c1e0-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
Starting with the conn.log, we have the following data.
{“ts”:”2019-04-08T14:50:26.723088Z”,”uid”:”CcB2w32c1AbVFbB6Hb“,”id.orig_h”:”192.168.40.82″,”
id.orig_p”:51511,”id.resp_h”:”104.16.125.34″,”id.resp_p”:443,”proto”:”tcp“,”service”:”ssl“,”duration”:2.49925
3,”orig_bytes”:845,”resp_bytes”:3472,”conn_state”:”SF”,”local_orig”:true,”local_resp”:false,”missed_bytes”:0,”
history”:”ShADadfF”,”orig_pkts”:15,”orig_ip_bytes”:1465,”resp_pkts”:14,”resp_ip_bytes”:4044,”tunnel_parent
s”:[],”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”]}
This is similar to the last conn.log entry for TLS 1.2. Let’s see what we can find by searching on the uid, omitting the conn.log.
$ zgrep CcB2w32c1AbVFbB6Hb *
ssl_20190408_07:00:00-08:00:00-0700.log.gz:{“ts”:”2019-04-08T14:50:27.415393Z”,”uid”:”CcB2w32c1AbVFbB6Hb”,”id.orig_h”:
”192.168.40.82″,”id.orig_p”:51511,”id.resp_h”:”104.16.125.34″,”id.resp_p”:443,”version”:”TLSv13“,”cipher”:
”TLS_AES_256_GCM_SHA384“,”server_name”:”enabled.tls13.com“,”resumed”:true,”established”:true,
”ja3″:”f436b9416f37d134cadd04886327d3e8“,”ja3s”:”907bf3ecef1c987c889946b737b43de8“}
We only have the ssl.log to work with. It reports the TLS 1.3 cipher, and a server name. We do not have certificate details as with TLS 1.2. This is probably the biggest concern in the cyber threat intelligence community, as analysts have lost the ability to profile and link intruders using details in the certificates. The Curl output reported that information, but only because it was in verbose mode for troubleshooting. Finally we have the ja3 and jas3 hashes, which you will notice are not the same as those from the TLS 1.2 experiment. The difference is caused by the client wishing to negotiate a TLS 1.3 session, and the server responding in kind.
Conclusion
TLS 1.3 certainly presents a challenge from the strictly passive network security monitoring point of view. Analysts will have to pay more attention to the identities on either end of the conversation, rather than the information reported by the server during the certificate exchange process. For those who want to introduce middleboxes, it will still be possible to essentially “man-in-the-middle” (MITM) TLS 1.3 connections by installing certificates on endpoints and terminating TLS 1.3 connections at inspection devices. Such a heavy-handed approach introduces its own privacy and resiliency challenges, however.
By showing the changes introduced by TLS 1.3 in logs, I hope readers can try replicating these experiments for themselves, and prepare tools and techniques to capture the data they need to protect their networks. Corelight’s engineers have been working on ways to continue innovating to provide customers the data they need to protect their enterprise and its users. Additionally, we have plans to document and speak on various ways to leverage other aspects of Corelight data to cope with a TLS 1.3 world. Stay tuned!