TLS Decryption on Cisco Security Devices

Home , Certificate Transparency, IPv4, OCSP stapling, QUIC, Server Name Indication

BRKSEC-3015

Tobias Mayer, Technical Solutions Architect Cisco Spark

Questions? Use Cisco Spark to communicate with the speaker after the session

How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space

cs.co/ciscolivebot#BRKSEC-3015

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 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”

• 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 For Your Reference

• 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, currently Internet Draft

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

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 AEAD – Authenticated Encryption (2) https://www.imperialviolet.org/2015/05/16/aeads.html • AE (key, plaintext) -> Ciphertext • Same plaintext letter results in same ciphertext letter (“hello” -> “&%$$”)

• AE (key, plaintext, nonce) -> Ciphertext • Nonce needs to be distinct! • Need to send it along with the ciphertext • Problem: order of the messages!

• AEAD (key, plaintext, nonce, ad) -> Ciphertext • “ad” is the associated data, can be a counter. • RULE: The combination of “nonce” and “ad” shall never be the same for all time!

TLS_RSA_WITH_RC4_128_MD5 TLS RSA RSA RC4_128 128 MD5

TLS_DH_RSA_WITH_DES_CBC_SHA TLS DH RSA DES_CBC 56 SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS DHE RSA AES_128_CBC 128 SHA

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS ECDH ECDSA AES_256_CBC 256 SHA

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS ECDHE RSA AES_256_GCM 256 SHA384

• TLS_EMPTY_RENEGOTIATION_INFO_SCSV Cipher is sent to indicate that if the server wishes to renegotiate any parameters, this is only supported over the secure connection. Renegotiation over plaintext will not be accepted

• TLS_FALLBACK_SCSV Cipher is sent by the client when a previous connection with a higher protocol was not successful for whatever reason (TLS 1.2 -> TLS 1.0) Server who supports this cipher can now see that the session was “downgraded”

Client Server

Client Server ClientHello

ServerHello

Client Server ClientHello

ServerHello

ServerCertChain & (SrvKeyExchg)

Client Server ClientHello

ServerHello

ServerCertChain & (SrvKeyExchg) Verify Server Certificate & Check Crypto Parameters

Client Server ClientHello

ServerHello

ServerCertChain & (SrvKeyExchg) Verify Server Certificate & ClientKeyExch Check Crypto Parameters

Client Server ClientHello

ServerHello

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

Client Server ClientHello

ServerHello

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

Client Server ClientHello

ServerHello

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

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

Tobias Mayer, CSE

Upload an existing certificate with private key…

…or generate a local certificate… …and upload signed certificate …download CSR…

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 37 Explicit Proxy • Client requests a website • Browser connects first to WSA TCP_MISS_SSL/200 39 CONNECT tunnel://www.google.de:443 • WSA does DNS lookup - A record returned and/or AAAA record returned • Depending on WSA setting, WSA builts outgoing connection either on IPv4 or IPv6 Internet Web Web Security Appliance server IPv6

IPv4

Internet ASA NGFW

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 38 Transparent Proxy via WCCP • Client requests a website using IPv4 or IPv6 • DNS Resolution is done by the Client • Browser tries to connect to Website TCP_MISS_SSL/200 0 TCP_CONNECT 85.17.181.244:443 • Network Device redirects traffic to WSA using WCCP • WSA proxies the request

Web Security Appliance Internet Web server IPv6

IPv4 Internet ASA NGFW

Access Policy Decryption Policy

Block Monitor Warn Pass Decrypt Drop Monitor Cont. Evaluation of Encrypted Decryption Policies Block Cont Warn Goto Page Page Evaluation Page Access If “Decrypt for EUN” displayed displayed of Access displayed Policy Selected (in 7.7+) Policies Page Page Block Page displayed blocked allowed

Access Policy Decryption Policy

Monitor Monitor

Applications WBRS Check : has Score

Granular Block Monitor Passthrough Decrypt Block Control (if availible) Block Continue page Eval of displayed Access WBRS Check : has No Score Policies Default Action

• The WSA needs a CA Certificate to be installed for TLS decryption • Not a WEB SERVER CERTIFICATE!!! TAC will say thank you for this! 

• After receiving the HTTPS Request, the WSA will grab the server certificate from the destination

• It will create a new (spoofed) certificate with (nearly) all the fields and sign this with her own certificate • CRL / OCSP is not replicated because it would not match the “new” certificate

• Client needs to trust the certificate from the WSA • Use a trusted Enterprise subordinate CA certificate or roll out your self-signed cert to the clients via GPO • Certificates on the WSA use PEM format

“Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.” • Basic Constraints defines if the Certificate is a CA, recommended to set to CRITICAL

• 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

• Firefox v43+ introduced a switch to block SHA-1 signed leaf certificates

• Set it to “1” to block and to “0” to allow

• Fallback • Client sends “Client Hello” and suggests a version to use • If Server responds with a “fatal error”, client will fallback to another version • Example: TLS 1.2 “yes” but there is no common cipher offered… • Not a “fatal error” : Client asks for TLS 1.2 but Server offers 1.0

• Fallback • WSA has a feature that enables or disables “Fallback” • WSA will fallback to the “lowest” Version supported • Enabled / Disabled via CLI under “sslsettings” • Recommendation: Enable, definitely enable….

• 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 Application Detection

• Will try to decrypt all categories that are put on “monitor” , incl. “no categories” • AVC Engine checks the request header and decides if it needs decryption

• Will supersede the “Pass Through” Option in “Decryption for WBRS” • AVC Engine will check if decryption is necessary

• Might dramatically increase the traffic that is being decrypted

• 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

• Decrypt for Authentication (=transparent requests with IP Surrogates)

• Authentication less of a problem in explicit deployments with IP Surrogates

• Authentication is a bigger problem in transparent deployments, especially with Cookie surrogates • Cookie is inside the encrypted request • Decryption based on User/Group is not possible

• If you need to “DROP” a category in the access policies, good to also drop it in the decryption Policies • HTTPS request is otherwise decrypted first and then matched against access policies

• This will give a small performance gain

• Certificate is very often in “DER” format • Convert it to “PEM” to import to the WSA openssl x509 –inform der –in -out • Display the content of the “PEM” Certificate in readable format openssl x509 –in -text -noout

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:

• AIA Chasing is using the OCSP daemon for verification 02 Jun 2016 08:21:22 (GMT +0200) Info: 5154 : OCSP Result for the server : www.hypovereinsbank.de - (0, 2, 3600)

02 Jun 2016 08:21:22 (GMT +0200) Info: 5154 : OCSP Result for the server : www.hypovereinsbank.de - (0, 2, 3600)

OCSP Status

OCSP daemon result code TTL of OCSP verdict

• OCSP Request Type • 'inter cert chase_max_depth' : 512, • 0 - OCSP request only • 'inter cert chase_parent_miss' : 1024, • 1 - Intermediate Certificates request only • 'inter cert chase_parent_blacklisted' : with ocsp disabled 2048 • 2 - Both Intermediate Certificates and ocsp request

• OCSP daemon result code with only intermediate cert request • 'inter cert chase_success' : 32, • 'inter cert chase_cached': 64, • 'inter cert chase_self_signed' : 128, • 'inter cert chase_url_missing': 256,

• OCSP daemon result code (OCSP only) • “no good info” : 0 • “good cert”: 2 • “revoked cert: 4 • “unknown cert”: 8 • “other error”: 16

• In case OCSP Request type = 2, the daemon result values of OCSP only and intermediate certificate chase are combined: 28 May 2016 18:12:45 (GMT +0200) Info: 4399 : OCSP Result for the server : library.netapp.com - (2, 34, 3600)

• Example: www.bluehost.com • The link for certificates in is the SKID and the AKID (see hidden slide) instead of just using the CN (Name Chained Certificates)

• SKID : SUBJECT KEY IDENTIFIER • Hash of the public key • AKID: AUTHORITY KEY IDENTIFIER • Hash of the issuer’s public key (building the cert chain) And / or • The issuer and serial number of the CA (only used for identifying the right certificate)

Root CA1 DN Self Issuer CA1 DN Signed Cert DN Root CA Public Key CA3 Cert Public Key Root CA1DN Root CA Signature Issuer CA DN Issuer CA3 DN SKID = 2f 7c aa.. Issuer Signature Root CA Public Key SKID = 3d ff cb .. Root CA Signature AKID = 2f 7c aa.. SKID = 2f 7c aa.. AKID = 12 3f bb..

• WSA will always check the complete chain until the last certificate possible! • So if you find two trusted paths, make sure you have all certificates in your trusted store

• 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…

• Should certificate Errors be handled by the browser or by the WSA showing a EUN to the user?

• In both ways the user is getting an error message…

• Maybe better to have a customized error message to limit the famous DoS attack on the IT support department?

• 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

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 72 Certificate Revocation “Drop” requires • Certificates can be revoked “Decrypt for • OCSP is the standard protocol to check if a certificate is EUN” revoked (OCSP largely replacing CRL)

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 73 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

• EUN for a revoked Certificate

• In Explicit mode, a „CONNECT“ request is made, giving the host URL to the WSA together with the „CONNECT“ request

• WSA replies with „407 Proxy auth required“

• At this time, WSA has the following information: - Destination host - User agent - User credentials verified

• WSA can decide whether to decrypt based on: - Destination Host (URL Category) - User Agent - Proxy Port - Subnets & Time Range

1414066212.006 552 10.61.70.30 TCP_MISS_SSL/200 39 CONNECT tunnel://www.google.de:443/ "hsimpson@MUNSEC" DIRECT/www.google.de - DECRYPT_WEBCAT_7-DefaultGroup-ID.MUNSEC-NONE-NONE-NONE-DefaultGroup - BASIC DestIP: 2a00:1450:4013:c00::5e AUTH: 0 DNS: 19 REP: 24 SFBR: 0 CFBWR: 49 AMP: ------

1414066212.218 204 10.61.70.30 TCP_MISS_SSL/200 29694 GET https://www.google.de:443/?gws_rd=ssl "hsimpson@MUNSEC" DIRECT/www.google.de text/html DEFAULT_CASE_12-PO.MUNSEC-ID.MUNSEC-NONE-NONE-NONE- DefaultGroup - BASIC DestIP: 2a00:1450:4013:c00::5e AUTH: 0 DNS: 0 REP: 0 SFBR: 143 CFBWR: 51 AMP: 1 - - - - -

• In Transparent mode, there is no “CONNECT” but a “TCP_CONNECT” with the destination IP

• Since Client is not aware of WSA it will start a TCP connection to remote server

• Connection is redirected to WSA, client start an HTTPS/SSL connection directly • IP Surrogates: Check Client IP and authenticate • Cookie surrogates: Bypass Authentication

• At this point WSA only knows destination IP and port

• WSA sends HTTPS “probe” (it‘s own Client Hello) to get the “Server Hello” and server certificate

1417171197.329 66 172.16.10.30 TCP_MISS_SSL/200 0 TCP_CONNECT 85.17.181.244:443 "MUNSEC\administrator@munsec" DIRECT/www.startpage.com - DECRYPT_WEBCAT_7- DefaultGroup-ID.MUNSEC-NONE-NONE-NONE-DefaultGroup - NEGOTIATE DestIP: 85.17.181.244 AUTH: 0 DNS: 0 REP: 0 SFBR: 0 CFBWR: 0 AMP: ------

1417171197.338 23 172.16.10.30 TCP_MISS_SSL/200 518 GET https://www.startpage.com:443/js/abp.js?adType=1&advertiser=1&advertising=1 "MUNSEC\administrator@munsec" DIRECT/www.startpage.com application/javascript DEFAULT_CASE_12-PO.MUNSEC-ID.MUNSEC-NONE-NONE-NONE-DefaultGroup - NEGOTIATE DestIP: 85.17.181.244 AUTH: 0 DNS: 0 REP: 0 SFBR: 20 CFBWR: 1 AMP: 1 - - - - - BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 79 Detecting the hostname in transparent mode

• With the server certificate, WSA has knowledge of: - Client IP - Destination IP - Server Certificate - Common Name (CN) from server certificate is used as the hostname

• Based on this information WSA can match Identity and Decryption Policy and determine whether to DECRYPT or PASS THROUGH the request

• All information normally send in the HTTP Header (Cookies, User Agent, Mime- Type etc) are encrypted in the tunnel and thus not available to the WSA at this point.

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 80 Decryption Policy 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

TMAYER-M-T2AF:iitp tmayer$ openssl s_client -connect midmarketcioforum.pathable.com:443 CONNECTED(00000003) 62663:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.1/src/ssl/s23_clnt.c:585:

…but required by the server

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 85 Server Name Indication – Test (2) TMAYER-M-T2AF:iitp tmayer$ openssl s_client -servername midmarketciofourm.pathable.com -connect midmarketcioforum.pathable.com:443 CONNECTED(00000003) depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA Connection with SNI verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/serialNumber=YVv3G4-n4KOXYXCLfIddFS92BN4-LPum/OU=GT66017752/OU=See www.rapidssl.com/resources/cps (c)12/OU=Domain Control Validated - RapidSSL(R)/CN=*.pathable.com i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

• Recommendation: SNI should always be enabled • Especially in transparent deployments!

• When upgrading from very old releases (7.5) , check if it is enabled!

• Done via CLI, “advancedproxyconfig”

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 87 Detecting the requested Host 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)

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 88 WSA settings for TLS • 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:!CA MELLIA:!SRP:!IDEA:!ECDHE-ECDSA-AES256-SHA:!ECDHE-RSA-AES256- SHA:!DHE-DSS-AES256-SHA:!AES256-SHA:DHE-RSA-AES128-SHA

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 91 Checking certificates: https://www.ssllabs.com/ssltest/ BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 93 Common SSL Troubleshooting Steps

• Check your Access Logs • Look at ACL Decision tags regularly

• Check the destination url on https://www.ssllabs.com/ssltest/index.html

• Try to access the page directly without the WSA in the Path • Using curl or OPENSSL

• Try to access the page with the WSA in the Path

• For certificate errors, set error handling to anything else but “MONITOR”

• Check the https_logs -> put at least into “DEBUG” mode, better: “TRACE”

• Check the PCAPS

• Server is sending all certificates but WSA does not recognize the intermediate cert • Check with OPENSSL or http://www.ssllabs.com what is sent, compare to the existing certificates • Import the missing certificate if needed or upgrade to WSA 10.x for AIA Chasing

• Server and WSA cannot agree on common protocol or cipher • Check with OPENSSL for support of TLS Version and cipher • https logs should indicate a “Fatal Error” and “Protocol Error” • Use AsyncOS 10.x + for better TLS Support

• Server is sending a expired/ screwed up/ wrong certificate • Check with OPENSSL or website http://www.ssllabs.com • Can bypass decryption with CUSTOM URL

• Object -> Object Management -> PKI

• Generate an “Internal CA” • Self-signed or a CSR to be sent to a PKI for signing

• Import an external CA with Key

• Format is PKCS12, use openssl to convert

• Object -> Object Management -> Cipher Suite List

• Cipher selection • Default: all ciphers…. • Cipher string need to be selected separately to be more secure • Select • - Ciphers with TLS as protocol • - Ciphers with *DHE for PFS • - Ciphers with AES • - Ciphers with HASH = SHA256 or higher • - no ciphers with *anon*, sha, rc4, md5

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…

Action: Decrypt and resign It replaces the key ONLY in the Self-Signed Certificate, instead of the whole certificate. It causes the client browser does Certificate to be used warn that the certificate is self- signed.

• Multiple criteria for matching the rule

Some predefined sites DN of the destination that are undecryptable certificate

• 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.

Action to be taken

• 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...

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”

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 117 Thoughts about the future… Problem Statement How can we reliably detect if the certificate for the domain we are trying to access is the correct one?

• 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_security_sta te_static.json

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

1. Define a exemption from encryption based on well-known destination IP Addresses

2. 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

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 128 Certificate Pinning… 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…

• 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 time-stamp and knows, he can trust the status

Web Server with TLS TLS Client Hello

TLS Server Hello & Cert TLS Client & stapled OCSP response

• 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

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

Example.com Example.com

TLS Handshake TLS Handshake

Client Client (Browser) (Browser)

Certificate Logs Appends-only, cryptographically ensured

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

Periodically contact all Log Servers, Monitors Check if Log is behaving correctly, identify suspicious certificates, usually run by large organisations as Governments , banks or CAs. Everyone can run a monitor

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 139 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.

Name of the log

Digital Signature

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

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 145 Changes coming Google with Chrome plans to REQUIRE a CT validation for all Certificates issued after October 2017, starting 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 requires 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/

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 146 CT challenges on proxy/ngfw/ Header and SCT not copied over, but certificate is EV or issued after October 2017 -> Client will loose the green bar as an indicator in Chrome Browser for EV Certificates or display warning.

Workaround for specific URLs: http://www.chromium.org/administrators/policy-list- 3#CertificateTransparencyEnforcementDisabledForUrls Very likely: Same exception being made as for HPKP, ignore the CT requirement in case the cert is signed by a trusted corporate CA https://groups.google.com/forum/#!topic/certificate-transparency/kiOJFO6_N0o

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!

• 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 2016”}

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

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 156 HTTP 2.0 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

• Server Hello: Server decided to choose “H2” (HTTP2)

H2 is the choosen protocol

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 161 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 http://caniuse.com/#feat=http2

• 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

news.yahoo.com

sports.yahoo.com

• 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

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 170 Modification in TLS 1.3 Client Hello 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

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

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

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 173 Detecting the requested Host (recap) 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

• CN & SAN extensions are encrypted by DH

• 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 QUIC Connetion be encrypted… Client Server • HTTP response header HTTP • Alternate-Protocol: 443:quic

col: • Client establishes QUIC connection in the te-Proto Alterna background

• 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

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

• 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

TCP UDP

IP IP

• 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 QUIC Crypto

TCP UDP

IP IP

• 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

TCP UDP

IP IP

• 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 TLS 1.3

TCP UDP

IP IP

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 196 QUIC challenges on proxy/ngfw/ 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?”

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 199 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: BRKSEC-2809 Applied Advanced Network Telemetry: ETA and Beyond BRKSEC_3014 Security Monitoring with Stealthwatch BRKSEC-2047 Behind the Perimeter: Fighting Advanced Attackers

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 200 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 draft https://tools.ietf.org/html/draft-ietf-tls-tls13-22 CT Explained https://scotthelme.co.uk/certificate-transparency-an-introduction/

Questions? Use Cisco Spark to communicate with the speaker after the session

How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space

cs.co/ciscolivebot#BRKSEC-3015

BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 203 • Please complete your Online Complete Your Online Session Evaluations after each session Session Evaluation • Complete 4 Session Evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Live T-shirt • All surveys can be completed via the Cisco Live Mobile App or the Communication Stations

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at www.ciscolive.com/global/on-demand-library/.

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Tech Circle

• Meet the Engineer 1:1 meetings

• Related sessions BRKSEC-2809 Applied Advanced Network Telemetry: ETA and Beyond BRKSEC_3014 Security Monitoring with Stealthwatch BRKSEC-2047 Behind the Perimeter: Fighting Advanced Attackers