Get Started

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


          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.

          TLS 1.2

          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 -v –tls-max 1.2

          * Added to DNS cache
          * Hostname was found in DNS cache
          *   Trying…
          * TCP_NODELAY set
          * Connected to ( 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.;
          *   start date: Nov 16 00:00:00 2017 GMT
          *   expire date: Nov 21 12:00:00 2019 GMT
          *   subjectAltName: host “” matched cert’s “”
          *   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:
          > 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=/;; 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=””
          < server: cloudflare
          < cf-ray: 4c450d8a0aa0c186-IAD
          <html xmlns=”” >
          * Connection #0 to host 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.







          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 *






          [],"subject":",O=Cloudflare\u005c, Inc.,L=San

          Francisco,ST=CA,C=US","issuer":"CN=DigiCert ECC Secure Server CA,O=DigiCert



          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.









          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 *



          certificate.subject":",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":[""],"":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 *



          EE53908767470F3CDC612","certificate.subject":"CN=DigiCert ECC Secure Server CA,O=DigiCert

          Inc,C=US","certificate.issuer":"CN=DigiCert Global Root CA,,O=DigiCert



          This is information from the certificate that was used to sign the 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!



            Recent Posts