CONTACT US
forrester wave report 2023

Close your ransomware case with Open NDR

SEE HOW

ad-nav-crowdstrike

Corelight now powers CrowdStrike solutions and services

READ MORE

ad-images-nav_0013_IDS

Alerts, meet evidence.

LEARN MORE ABOUT OUR IDS SOLUTION

ad-images-nav_white-paper

5 Ways Corelight Data Helps Investigators Win

READ WHITE PAPER

glossary-icon

10 Considerations for Implementing an XDR Strategy

READ NOW

ad-images-nav_0006_Blog

Don't trust. Verify with evidence

READ BLOG

ad-nav-NDR-for-dummies

NDR for Dummies

GET THE WHITE PAPER

video

The Power of Open-Source Tools for Network Detection and Response

WATCH THE WEBCAST

ad-nav-ESG

The Evolving Role of NDR

DOWNLOAD THE REPORT

ad-images-nav_0006_Blog

Detecting 5 Current APTs without heavy lifting

READ BLOG

g2-medal-best-support-ndr-winter-2024

Network Detection and Response

SUPPORT OVERVIEW

 

Investigating the effects of TLS 1.3 on Corelight logs, part 3

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!

 

Recent Posts