BRKSEC-3015.Pdf

#CLUS TLS Decryption on Cisco Security Devices

Tobias Mayer, Technical Solutions Architect BRKSEC-3015

#CLUS Abstract

This advanced session will discuss the approach how we can decrypt TLS encrypted web traffic to be able to inspect it and what challenges we are facing in an enterprise environment. For this, we need to be able to understand how TLS is working and what is required to decrypt this traffic.The second section will then include some best practices for Cisco security products dealing with TLS decryption such as Firepower, WSA and Umbrella. The last part will give an introduction to encrypted protocols such as HTTP/2, TLS 1.3 and QUIC. Those protocols are making it harder to decrypt certain traffic flows and we need to think about complementing technologies that still enforce security in the network. As additional food for thought we will quickly also touch on OCSP Stapling and Google's Certificate Transparency, which are interesting additions to the TLS landscape.This session is intended for network and security architects that want to get a deeper understanding of decryption of web traffic in the enterprise. Attendees should be familiar with the overall concept of HTTP, HTTPS and TLS.

CCIE Security #14390, CISSP & Motorboat driving license… Working in Content Security & TLS Security tmayer{at}cisco.com Writing stuff at “blogs.cisco.com”

“I might skip THAT…! What are you doing to the poor people??“

„That is dry like hell!“

• Understanding TLS

• Configuring Decryption on the WSA

• Configuring Decryption on Cisco Firepower

• Configuring Decryption on Umbrella

• Thoughts about the future

• Certificate Transparency & OCSP Stapling

• HTTP/2 , TLS 1.3 & QUIC

• There are (many...) slides in your print-outs that will not be presented.

• They are there “For your Reference”

For Your Reference

Microsoft pushing TLS with PFS Apple demanding transport security Browser Vendors aggressively pushing https Problems with older TLS versions leading to upgrade of servers to newer protocols and ciphers Poodle, Freak, Beast, …. Google, FB, Twitter encrypting all traffic HTTPS usage influencing page ranking on google Deprecate SHA1, only SHA2+

Google ranking influenced by using HTTPS http://blog.searchmetrics.com/us /2015/03/03/https-vs-http- website-ssl-tls-encryption- ranking-seo-secure-connection/

• SSLv3, 1996

• TLS 1.0, 1999, RFC2246

• TLS 1.1, 2006, RFC4346 • Improved security

• TLS 1.2, 2008, RFC5246 • Removed IDEA and DES ciphers • Stronger hashes • Supports authenticated encryption ciphers (AES-GCM) • TLS 1.3, currently Internet Draft

POODLE SSLv3 Problems with Padding, turn of SSLv3 BEAST Know issues in CBC mode, use TLS 1.1/1.2 with non-CBC mode ciphers (GCM) CRIME/BREACH Compression Data Leak, disable compression in TLS (CRIME), HTTP Compression still there Lucky13 Problem with Padding still exists with CBC Ciphers, use TLS 1.2 with AEAD (GCM) Freak Downgrade to RSA_EXPORT, disable EXPORT CIPHERS, use TLS 1.2 Logjam Force client to downgrade to DHE_EXPORT Grade ciphers, disable DHE_EXPORT Ciphers, use TLS 1.2

SSLv3, 1996, broken by Poodle TLS 1.0, 1999, RFC2246, weakend by BEAST & Lucky13 TLS 1.1, 2006, RFC4346, weakend by Lucky13 Improved security TLS 1.2, 2008, RFC5246 Removed IDEA and DES ciphers Stronger hashes Supports authenticated encryption ciphers (AEAD, i.e. AES-GCM) TLS 1.3, submitted for standard

Protocol used Key Exchange Authentication

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Symmetric Encryption Hash to verify integrity used

old modern Protocol SSL TLS Key exchange RSA EC(DHE) * Authentication RSA EC(DSA) Encryption 3DES, RC4 AES algorithm Encryption mode CBC GCM MAC SHA, MD5 SHA256,SHA368

* Ephemeral DH provides PFS

Using RSA key for authentication and key generation is putting our traffic vulnerable to offline attacks Someone might record out traffic and years later, compromise our Server, get the private key and decrypt all traffic. Diffie-Hellman (DH) is a method to prevent this, but: With static DH, the DH parameters are actually again the private key… DHE is using unique keys for every session, this is called Perfect Forward Secrecy Dynamic parameters for the DH Session are never stored and never re- used

DHE Ciphers use PFS But are heavy to compute… ECDHE Ciphers use Ecliptic Curves and provide PFS Much better performance  Especially in Software

Authenticated Encryption with associated data CBC (confidentiality) + HMAC(integrity) vs. AE(confidentiality & integrity) GCM is the most popular Algorithm https://en.wikipedia.org/wiki/Galois/Counter_Mode No License and fast computing Implemented in OPENSSL

BRKSEC-3005 Cryptographic Protocols and Algorithms - a review

Client Server ClientHello

ServerHello

ServerCertChain & (SrvKeyExchg) Verify Server Certificate & ClientKeyExch Check Crypto Parameters ChangeCipherSpec ClientFinished ChangeCipherSpec ServerFinished Encrypted Data

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 Breaking TLS 1. Generate pub/priv key and root cert 2. Install root cert on client device Client TLS Proxy Server ClientHello ClientHello

(own or modified) ServerHello

ServerCertChain Validate Certificate

Generate spoofed certificate, signed by private Spoofed cert. key from proxy

The client needs to be able to support TLS versions & ciphers also Overview can be found here: https://en.wikipedia.org/wiki/Transport_Layer_Security

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 “We are trying to break into a protocol that was not meant to be broken. Things will sometimes fail.Get used to it” Tobias Mayer, Cisco

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 23 Configuring Decryption on the WSA (and explaining the technology) Certificate installation and usage Browser Companies & CA have phased out SHA-1: https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based- signature-algorithms/ https://googleonlinesecurity.blogspot.rs/2014/09/gradually-sunsetting-sha-1.html https://www.bleepingcomputer.com/news/security/microsoft-bans-sha-1-certificates-in- edge-and-internet-explorer/ Moving to SHA-2 Set of algorithms: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 WSA 9.x+ Generating a self-signed certificate will use SHA-256 by default and 2048 bit RSA key CSR can be sent to a CA but CA needs also to use SHA-256 Importing externally generated certificate and key is possible DSA_SHA256 signed certificates are not supported

• Policy can be based on • Identification Profile (Identity) • URL Category • Web Reputation

• Additional Options

Categories “Pass Through” will still check for certificate errors! Invalid certificate or expired certificate on the server will fail the “Pass through”

Custom URLs (best used for making an exception for decryption) “Pass Through” will bypass all certificate check -> true Pass Through “Decrypt” -> certificates will be checked and the user will get a prompt (“untrusted CA”) Custom categories take precedence over predefined categories!

• Dynamic feed for automatically bypassing the Microsoft recommended domains

• Introduced in WSA 10.x

URL from O365 Repository

Decrypt for End User Notification

Important for transparent requests, not so much for explicit Policy to “Drop” in the Decryption Policy will not display a notification to the End User unless you select this option Otherwise the End User will just get the standard Browser Error

If decrypt for EUN is enabled, and the action is "Drop", WSA will decrypt and produce an EUN page for the following certificate errors: Expired Certificates Mismatched Hostname Unrecognized root CA Other certificate errors - Invalid certificate OCSP - Revoked certificate OCSP - Unknown Certificate OCSP - Other OCSP errors Revoked certificates Black listed certificates

Root CA

Intermediate CA

Server Certificate

Some servers send the server cert only …

Browser checks the extension “Authority Information Access (AIA)” This tells him where to find the next certificate Browser downloads it and can now check if it is valid

New Feature in WSA 10.x Release! Automatically downloads the missing intermediate certificate

Log entry in https_logs in case a missing cert is downloaded:

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 34 Certificate Error Handling Settings on the WSA Default Values provide a good balance between Security and User Experience Remember: EUN in case of a “Drop” requires “Decryption for EUN”! “Drop” : log the certificate error in the access log, decrypt and display EUN “Decrypt” : log the certificate error in the access log, decrypt with a purposely “invalid” certificate and let the client decide if he accepts the connection. “Monitor” : don’t do anything, it’s all on the client to decide…

Certificates can be revoked OCSP is the standard protocol to check if a certificate is revoked (OCSP largely replacing CRL)

TLS Client Hello

TLS Server Hello & Cert TLS Client Web Server with TLS

OCSP Information is found in the “Authority Information Access” extension

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 38 Certificate Revocation Includes OCSP Error Handling “OCSP Result is added to the decission tag in the accesslogs responder OCSP_REVOKED_CERT cannot be OCSP_UNKNOWN_CERT contacted” OCSP_OTHER_ERROR malformedRequest – responder does not understand request due to wrong syntax internalError – responder reached inconsistent state tryLater – responder reachable but not able to respond sigRequired – client is required to sign his request unauthorized – client is not authorized currentTime – problem with the time the request was made

Decrypting device needs to decide whether it should decrypt or not Criteria is usually the requested URL Category We need to discover the HOSTNAME of our destination There are also sometimes other criteria such as Subnet Port Web Reputation User Agents

Should we decrypt? Very often based on URL Category...(think of finance websites...)

Its “youtube.com”

Situation: Hosting Provider with one external IP and several hosted domains internally Each Domain uses its own certificate If a client requests a connection to the IP (shared among the domains), which Server does he want to go to? Which certificate should the server send in his Server Hello?

Finding out the correct destination hostname and mapping to URL Category.... Solution: Usage of SNI (Server Name Indication) is required from Proxy side (supported in v7.7+) Most Browser support it since many years CLIENT HELLO during TLS sends the Host URL:

SNI = www.youtube.com

The requested hostname is usually detected by one of several methods: Transparent Request (Transparent proxy, FW) 1. Check the SNI Name in the TLS Client hello 2. Check the CN Field in the Subject of the Server Certificate Explicit Proxy 1. Usually get the hostname from the CONNECT REQUEST 2. Check SNI , then CN field

Use AsyncOS 10.x Check that AIA Chasing is enabled Check that you have a Sub-CA Certificate signed with SHA-2 Enable TLS 1.2, 1.1 and , depending on your risk evaluation, TLS 1.0. Disable SSLv3 if not already done! Decryption policy of “Drop” requires “Decrypt for EUN” option to be enabled if you want to see the EUN Certificate Errors, “Drop” or “Decrypt” provide logging Check your logs for certificate errors regularly Check on CLI that you have Server Name Indication enabled Check on CLI that you have Fallback enabled

Make sure that OCSP checking is enabled (Drop Revoked) Check the clients & browser versions , verify what TLS Version they are able to support Drop predefined categories in access policies (AP) and decryption policies(DP) for better performance Create a custom URL Category for exception and reference them in AP and DP Check your Cipher String, disable RC4, Export & Keys lower than 128bit See next slide

ASYNC OS 9.1.1 and lower

DEFAULT:kEDH:!EXPORT:!LOW:!RC4

ASYNC OS 9.1.2 and higher EECDH:DSS:RSA:!NULL:!eNULL:!EXPORT:!3DES:!RC4:!RC2:!DES:!SEED:!CAME LLIA:!SRP:!IDEA:!ECDHE-ECDSA-AES256-SHA:!ECDHE-RSA-AES256- SHA:!DHE-DSS-AES256-SHA:!AES256-SHA:DHE-RSA-AES128-SHA

SSL-Policy

Decryption Access-Policy

IPS, App, etc.

Rules are matched top-down

For internal Traffic going outside For external Traffic going to internal server (via passive interface)

NGFW with copy of Server ABC key and cert ABC ABC #$* #$*

Client TAP Server

If the TLS connection uses PFS, traffic inspection is not possible!

Multiple criteria for matching the rule

Some predefined DN of the destination sites that are certificate undecryptable

Certificate Status: Revoked, self-signed, not yet valid, expired, invalid issuer, invalid signature, valid. Cipher suite SSL version

If the certificate matches any of the selected statuses, the rule matches the traffic.

From 6.1 : The system now displays an HTTP response page for connections decrypted by the SSL policy, then blocked by access control rules. However, the system does not display a response page for encrypted connections blocked by access control rules (or any other configuration) FTD cannot support EUN for bad certs at the moment (6.2.1)

No support for OCSP, only CRL CRL can only be added statically to a trusted CA Download CRL manually and upload manually Format is DER or PEM

Upload CRL here...

Block

Exclude Self- Certificate signed Certificate Errors Errors

Include Self- Ignore all signed others

SNI is always enabled No automatic download of missing intermediate certificates Manual upload required No action on certificate check for undecrypted HTTPS connection in the default settings Client is responsible for any error message Can not prompt the client in case you have an error SSL Policy needs to be attached to an access policy

HTTPS decrypt

Umbrella feeds

TALOS & partner feed Intelligent proxy AV

AMP DNS

No insecure ciphers Preferring modern ciphers Good certificate error handling Dedicated error message displayed Usage of SNI, cert revocation, etc… Fixed Cisco certificate for decryption List for to be decrypted websites handled by Cisco Umbrella Not yet a way to influence No automatic intermediate certificate download

If website is needed, bypass them with a „Allow List”

How can we reliably detect if the certificate for the domain we are trying to access is the correct one?

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 66 HSTS & Certificate Pinning HSTS “HTTP Strict Transport Security” - http://tools.ietf.org/html/rfc6797 Protect secure HTTPS Websites against downgrade attacks Web Server can signal to the client that only HTTPS is allowed to interact This signal is transported using a HTTPS Response Header The client behaves as follows Automatically turn any http:// links into https:// links If the secure connection cannot be assured (ex: Self Signed Certificate is used), do not allow the user to override If you want to decrypt using a proxy, a valid CA Certificate is required!

Method to actually compare the Certificate presented from the Server to a “stored” CA Certificate on the Client. Requires a method to ensure the Client is running the latest Version of your Software Applies to centrally updated Applications that connect to predictable Servers Two ways to do it: Incorporate a static list in the application, which of the CA Certificates is expected to be used for signing the server certificate Send a new “Header”(HPKP) to signal within the TLS Handshake that the client should PIN a certain public key for a certain amount of time Chrome connecting to gmail.com, twitter, FF connecting to mozilla.org https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_securi ty_state_static.json

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 69 Certificate Pinning Example: Firefox https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning 0: Pinning disabled 1: Allow User MiTM (with a trusted CA) 2: Strict. Always enforced 3: Enforce Test Mode

Strict Pinning

Google Drive uses Certificate Pinning by default Define a exemption from encryption based on well-known destination IP Addresses Restart Google Drive Client with “unsafe” option Exit Google Drive from the System Tray In the Command prompt, navigate to the Google Drive folder (32 bit - C:\Program Files\Google\Drive. 64 bit - C:\Program Files (x86)\Google\Drive) Enter googledrivesync.exe --unsafe_network

Chrome will deprecate support for Certificate Pinning Goal is to use CT for all certificates, combined with OCSP Must-Staple https://groups.google.com/a/chromium.org/forum/#!msg/blink- dev/he9tr7p3rZ8/eNMwKPmUBAAJ

Certificates can be revoked OCSP is the standard protocol to check if a certificate is revoked (OCSP largely replacing CRL)

TLS Client Hello

TLS Server Hello & Cert TLS Client Web Server with TLS

CRLs OCSP Too big What if OCSP Server is not Does not scale for 100s of CAs responding? Soft-fail? Hard-fail? What if OCSP Server is slow? How long to wait for an answer? Privacy…

OCSP Server of the CA • Web server queries the certificate vendor • Vendor responds with the status of the certificate and a signed time-stamp • When a client connects to the server, the server “bundles” the status from the vendor with the SSL certificate he is sending to the client • The client browser verifies the signed timestamp and knows, he can trust the status Web Server with TLS TLS Client Hello

TLS Server Hello & Cert TLS Client & stapled OCSP resonse

DNS DNS TCP handshake TCP handshake SSL handshake SSL handshake Verify certificate chain Verify certificate chain DNS to CA Process OCSP Data TCP to CA #1 Finish SSL Handshake OCSP to CA #1 TCP to CA #2 OCSP to CA #2 Finish SSL Handshake

OCSP Must-Staple Cert includes extension “must- staple” Certificate without OCSP stapled response must be rejected Cashing time for the OCSP response can be adjusted to shorter lifespan

Not much direct impact on the decryption but:

For verification of certificate revocation, vendors should adopt the support of OCSP stapling on the decrypting device…. Ignoring the OCSP Stapled Response is lowering the security Ignoring the “must-staple” extension is against rfc7633

Log Server

CA submission Log Response (SCT)

Certificate Certificate Authority Authority

Cert issued Cert issued + SCT

Example.com Example.com

TLS Handshake TLS Handshake (w SCT)

Client Client (Browser) (Browser)

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 85 Certificate Transparency – RFC6962 • https://www.certificate-transparency.org/what-is-ct Appends-only, cryptographically Certificate Logs ensured (Merkle Tree Hash) https://www.certificate- transparency.org/log-proofs-work

Log Server Lightweight Component, Auditors usually part of the browser. Check individual certificates.

Periodically contact all Log Monitors Servers, Check if Log is behaving correctly, identify suspicious certificates, usually run by large organisations as Governments , banks or CAs. Everyone can run a monitor #CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 86 Delivery of the SCT

X509v3 Extension SCT as part of the certificate, attached through the CA No Server modification necessary TLS Extension Server receives the SCT from the CA and sends it to the client through a TLS Extensions called “signed-certificate-timestamp” Server needs to accommodate the new extension OCSP Stapling Server is receiving the SCT and adds it to the OCSP stapled response Client needs to understand OCSP Stapling

A certificate is “CT qualified” if it meets one of the following criteria: 1. An SCT from a log qualified at the time of check is presented via the TLS extension OR is embedded within a stapled OCSP response; AND there is at least one SCT from a Google Log, qualified at the time of check, presented via any method; AND there is at least one SCT from a nonGoogle Log, qualified at time of check, presented via any method.

2. An Embedded SCT from a log qualified at the time of check is presented; AND there is at least one Embedded SCT from a Google Log, once or currently qualified; AND there is at least one Embedded SCT from a nonGoogle Log, once or currently qualified; AND there are Embedded SCTs from AT LEAST the number of logs once or currently qualified shown in Table 1.

SCT Extension

Name of the log

Digital Signature

Automatic monitoring as a service: https://sslmate.com/certspotter/

• https://tools.ietf.org/html/draft-strad-trans-redaction-01

Google with Chrome REQUIRES a CT validation for all Certificates issued after October 2017, since April 2018 https://groups.google.com/a/chromium.org/forum/#!msg/ct- policy/sz_3W_xKBNY/6jq2ghJXBAAJ https://www.chromium.org/Home/chromium-security/certificate-transparency Chrome already required CT Validation for EV Certificates issued after Jan 2015 https://www.certificate-transparency.org/ev-ct-plan New Header defined: “expect-ct” Report and / or enforce CT https://scotthelme.co.uk/a-new-security-header-expect-ct/

CT is the way how browsers like Chrome are validating certificates. The security gateways need to adopt CT to be able to validate certificates. CT requirement is ignored in case the cert is signed by a trusted corporate CA https://groups.google.com/forum/#!topic/certificate- transparency/kiOJFO6_N0o

Exempt specific URLs from CT: http://www.chromium.org/administrators/policy-list- 3#CertificateTransparencyEnforcementDisabledForUrls

Hello Hello Can I have a picture of a cat? Here is a picture of a cat Thanks, bye!

Thanks, bye!

Hello Hello Can I have a picture of a cat? Here is a picture of a cat Can I have a picture of a dog? Here is a picture of a dog Thanks, bye! Thanks, bye!

HTTP/2 Specification is strongly based on input from SPDY & TLS http://daniel.haxx.se/http2/ https://www.ietf.org/blog/2015/02/http2-approved/

Header compression True multiplexing Re-Use of TCP connections Important with domain sharding (same ip, different domains) Browser limits connection per domain -> use subdomains: i.ytimg.com for icons, s.ytimg.com for stylesheets Server pushing content to the client Prioritization of streams Binary Format

Application (HTTP2) HTTP/1.1 GET /index.html HTTP/1.1 Binary Frame Host: www.example.com Session (TLS) Content-Type: text/html optional Content-Length: 42

Transport (TCP) {“msg”:”CiscoLive 2018”}

Network (IP) HEADER FRAME DATA FRAME

Pro: Easier to parse, more efficient use of data transfer Con: Server, Client & Gateways need to understand the new format

LENGTH (24 bit) TYPE (8 bit) FLAGS (8 bit)

R (1bit) Stream Identifier (31 bit) FRAME PAYLOAD

• Stream ID: Odd Numbers = initiated from client, even numbers= initiated from server • TYPE of the Header • Flags: END_STREAM, END_HEADERS, PRIORITY, …

• DATA • Transport of http body messages

• HEADERS • Transport of http header information

• PRIORITY • Signal of the priority of a stream coming from the server • RST_STREAM • Signal the termination of a stream • SETTINGS • Configuration Parameters for the connection • PUSH_PROMISE • Signal a promise to server the referenced resource • PING • Alive check and RTT messurement • GOAWAY • Stop creating new stream for the current connection • WINDOW_UPDATE • Flow stream and connection flow control • CONTINUATION • Continue a sequence of header block fragments

Connection Stream #1 Request Message DATA HEADERS

Response Message HEADERS DATA

Stream #2 Request Message DATA HEADERS

Response Message HEADERS DATA DATA

Hello Hello Can I have a picture of a house? And a car? And a dog? Here is a picture of a house Here is a picture of a car And a cat Here is a picture of a dog Here is a picture of a cat I think you need a picture of kittens Thanks, bye! Bye!

http:// https:// http:// https://

6-8 TCP connections per site Fewer TCP connections

No Change in URL Structure (“http://…”,”https://…”) Browser and server need to agree which protocol to use Non-Secure Client: send “Upgrade” Header, requesting Upgrade to “H2C” Server: respond either with HTTP/1.1 OK (=upgrade not accepted) or HTTP 101 SWITCHING PROTOCOLS (=upgrade accepted) Secure Leveraging ALPN Extension in TLS Client Hello

Client will “offer” its supported protocols and server will pick one of them TLS Extension called ALPN as part of the TLS Client Hello

First, HTTP/2

Second, SPDY Third, HTTP/1.1

Application Layer Protocol Negotiation (“ALPN) Server Hello: Server decided to choose “H2” (HTTP2)

H2 is the choosen protocol

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 111 HTTP2 and TLS Multiplex requests and responses over single TCP connection More efficient object retrieval One TCP connection to each server (avoids TCP & TLS setup delays) All browsers only attempt HTTP2 over TLS Chrome, Firefox, Safari Avoids difficult fallback code (like was necessary with HTTP 1.1 and middleboxes) Upgrades to HTTP2 using TLS extension Saves round trip of using HTTP’s “Upgrade:” header Page load time: HTTP2-over-TLS is equivalent to (plaintext) HTTP Eliminates TLS page load time penalty

Pages loading faster More usage of TLS Less TCP connections but longer lifetime HTTP/2 growing fast, websites change from SPDY to HTTP/2 SPDY has proven that a new protocol can grow fast

HTTP/2 encrypted with TLS Binary Format & Header Compressions need to be parsed (no more cleartext) Single TCP connection reuse

Single TCP connection reuse Domain must be in certificate and resolve to same IP “Same Origin” rules still apply for scripts

news.yahoo.com sports.yahoo.com

The origin can be adjusted: https://tools.ietf.org/html/rfc8336

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 116 TLS 1.3 TLS 1.3 – approved for standards track https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html • Remove of static RSA authentication mode • Using DHE / ECDHE instead for PFS

• Reducing overhead by using a 1-RTT handshake • Fallback to “legacy” handshake if client cannot handle it • 0-RTT Session resumption -> Tickets + PSK

• Remove non-AEAD Ciphers (CBC), compression, RC4, MD5, SHA224

• Encrypting more values in the handshake • Certificate Extensions such as CN & SAN

Client Server ClientHello

ServerHello

ServerCertChain & (SrvKeyExchg) Verify Server Certificate & ClientKeyExch Check Crypto Parameters ChangeCipherSpec ClientFinished ChangeCipherSpec ServerFinished Encrypted Data

Client Server ClientHello + KeyShare

ServerHello + KeyShare

EncryptedExtensions & Certificate Verify Server Certificate & Check Crypto Finished Parameters Finished + Data

Encrypted Data

TLS 1.3 was breaking some Security Gateways due to unsupported extensions and ciphers Decission of IETF: Signal TLS 1.2 in the “Version” field Signal TLS 1.3 in an additional extension Server who don’t understand extension will negotiate TLS 1.2 Server who understand TLS 1.3, will ignore the version field and negotiate TLS 1.3

• Firefox, 59+ , about:config

• Chrome 65+, chrome://flags

• iOS • https://developer.apple.com/go/?id=tls13-mobile-profile

Desired server TLS Client TLS Server

TLS ClientHello SNI=www.example.com

TLS ServerHello Certificate for www.example.net Session key (encrypted with private key)

Actual server Server certificate can avoid decrypting if entire site is blacklisted or whitelisted

Desired server TLS Client TLS Server

TLS ClientHello SNI=www.example.com Client’s Diffie-Hellman key

TLS ServerHello Server’s Diffie-Hellman key { Certificate for www.example.net } { Session key (encrypted with private key) }

{Encrypted by DH} Actual server Gateway has to decide whether to decrypt from the beginning. Can’t evaluate the certificate!

CN & SAN extensions are encrypted by DH Gateway has to decide upfront if decryption should be done or not. Can’t verify the server certificate We can only rely on SNI to know if we should decrypt or not SNI can be spoofed…

What if we send a “Fake” SNI name? Example: Request sent to Website A but indicating a request to Website B ? Reason: Browse to forbidden websites (boring…) Malware connects C&C through decrypting device (better reason...)

Usage of Firefox plugin called “Escape” http://madynes.loria.fr/Research/Software Works in UBUNTU Linux Can override certain websites with a fake SNI name

Overriding requests for “playboy.com” with “mail.google.com”

Logging shows wrong URL Category Application detection shows wrong application Selection of correct policy (decrypt/pass through) is impacted Possible Countermeasures (thoughts…) Check for incorrect hostname (WSA, Firepower) Compare detected host to real host (using logging tools) Enforce policies over DNS (reduce attack surface) Use native IPv6 without any IP address sharing 

Connection setup in TCP plus connection setup with TLS Big latency until Data is flowing Move to UDP for faster Session Setup

Google championed protocol to reduce latency UDP 80 & 443 Encryption, congestion control and some HTTP/2 things (stream handling) move to QUIC

HTTP/2 HTTP/2

TLS QUIC

TCP UDP IP IP

1-RTT connection handshake (Connection & Encryption negotiation) 0-RTT re-established connections Connections survive IP address change Connection Identified through a unique CONNECTION UUID Packets can arrive in any order Always encrypted and authenticated Mostly fixes head of line blocking FEC (Forward Error Correction) data recovery Additional Data is transferred to eventually recreate missing packets (RAID for the network) Removed from IETF Specification Work as it had minimal positive effect

• Multiplexed streams • Sharing connection across domains • HPACK header compression • Stream prioritization • Flow Control • Server initiated streams

If using TLS, the HTTP response header will be encrypted… QUIC Connetion

HTTP response header Client Server

Alternate-Protocol: 443:quic HTTP Client establishes QUIC connection in the col: te-Proto background Alterna Fully supported in Chrome browser QUIC Client’s can cache if server supports QUIC

Encrypted...

UDP/443

DATA [0] Network A DATA [1] DATA [2] Network B

N TCP Streams contributing to ONE logical flow Connections can be added and brought down dynamically

DATA [3] Network C

DATA [0] Network A DATA [1] Proxy DATA [2] Network B ?

“please contact me on IP#2”

DATA, ADD_ADDR #IP2

Network A

“Is this now incoming or outgoing?”

“please contact me on IP#2”

DATA, ADD_ADDR #IP2

Network A

Google QUIC does not yet use Multipath…. ....but IETF Working Group is discussing it: https://datatracker.ietf.org/meeting/99/materials/slides-99-quic-sessb-first- experiments-with-multipath-quic Flows can be distributed among several UDP connections Can be established or torn down dynamically Can go different paths in the network Can use IPv4 and IPv6 on different connections

5% latency reduction on average 30% reduction in rebuffers (video pauses) on YouTube 1 second faster at the 99th percentile for Google web search Helps more for higher latency networks

Working group within IETF has been created https://peering.google.com/#/learn-more/quic

Map HTTP cleanly to QUIC, make non-HTTP apps work with QUIC Use TLS 1.3 within QUIC https://www.ietf.org/proceedings/98/slides/slides-98-edu-sessf-quic- tutorial-00.pdf

HTTP/2 HTTP/2

TLS QUIC QUICTLS Crypto 1.3 TCP UDP IP IP

QUIC is always encrypted QUIC is using multiplexed streams and most likely soon also accross multiple paths Will happily use IPv4 and IPv6 concurrently If QUIC is not understood, connections look like unrelated UDP connections QUIC can be initiated from client and from server Where is now inbound and where is outbound?

Decryption of TLS is still possible in many cases… ....but technologies like certificate pinning or new protocols prevent decryption New Protocols like HTTP/2, TLS 1.3 and QUIC make it hard or even impossible for network devices to scan & detect threats in the network with deep packet inspection (DPI) We need to change our strategy away from pure DPI and think about: “What can we do if we cannot decrypt encrypted traffic?” “How can we still provide security and detect upcoming threats?”

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 147 Conclusion (2) WSA has good TLS decryption capabilities in Version 10.x+ FTD and Umbrella can do decryption but you need to know the limitations Transparent proxies & NGFW will have a big challenge in the future to be able to provide security by decrypting all traffic and not compromising on security Alternative methods need to be considered in a layered approach

CTA, Stealthwatch, AMP4E Cisco Technologies in related Sessions: TECSEC-2600 Encrypted Traffic Analytics: Detecting Malware without Decryption BRKSEC-3014 Security Monitoring with Stealthwatch BRKSEC-2047 Operationalizing Advanced Threat Solutions

#CLUS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 148 Links for further information For reading in those nights where you cannot sleep… RFC for specifying a Public Key Pinning in HTTP https://tools.ietf.org/html/rfc7469

OWASP Explanation of Certificate Pinning https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

HSTS “HTTP Strict Transport Security” https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Public Key Pinning Extension for HTTP http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20

Internet Advisory Board – Statement on Confidentiality https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality

TLS 1.3 https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

CT Explained https://scotthelme.co.uk/certificate-transparency-an-introduction/

Questions? Use Cisco Webex Teams (formerly Cisco Spark) to chat with the speaker after the session How 1 Find this session in the Cisco Events App 2 Click “Join the Discussion” 3 Install Webex Teams or go directly to the team space 4 Enter messages/questions in the team space

Webex Teams will be moderated cs.co/ciscolivebot#BRKSEC-3015 by the speaker until June 18, 2018.

Give us your feedback to be entered into a Daily Survey Drawing. Complete your session surveys through the Cisco Live mobile app or on www.CiscoLive.com/us.

Don’t forget: Cisco Live sessions will be available for viewing on demand after the event at www.CiscoLive.com/Online.

#CLUS Presentation ID © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 151 Continue Demos in Walk-in Meet the Related your the Cisco self-paced engineer sessions education campus labs 1:1 meetings

#CLUS #CLUS