The Trip to TLS Land using the WSA Tobias Mayer, Consulting Systems Engineer BRKSEC-3006 Me…
CCIE Security #14390, CISSP & Motorboat driving license… Working in Content Security & IPv6 Security tmayer{at}cisco.com Writing stuff at “blogs.cisco.com” Agenda
• Introduction
• Understanding TLS
• Configuring Decryption on the WSA
• Troubleshooting TLS
• Thoughts about the Future
• Conclusion 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 and Google pushing encryption
• Microsoft pushing TLS with PFS
• Google, FB, Twitter encrypting all traffic • HTTPS usage influencing page ranking on google • Deprecate SHA1, only SHA2+
• Browser Vendors aggressively pushing https
• Problems with older TLS versions leading to upgrade of servers to newer protocols and ciphers • Poodle, Freak, Beast, …. Google Search Engine
• 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/ Understanding TLS TLS Versions
• 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 Attacks…
• 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 TLS Versions
• SSLv3, 1996, broken by Poodle
• TLS 1.0, 1999, RFC2246, weakend by BEAST and 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 How is the encryption of the target website? TLS Handshake Version Number
Client Hello Version: Highest Version that the client Support
Server Hello Version: This is the Version that we will use for the TLS Connection. Server SHOULD select the highest Version possible.
Usually indicating lowest version supported
Highest Version the client supports Ciphers explained Name Prot Kx Au Enc Bits Mac
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 PFS – Perfect Forward Secrecy
• 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 PFS - Example
• DHE Ciphers use PFS • But are heavy to compute…
• ECDHE Ciphers use Ecliptic Curves and provide PFS • Much better performance • Especially in Software AEAD – Authenticated Encryption https://en.wikipedia.org/wiki/Authenticated_encryption
• 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
• Get more info about encryption in BRKSEC-3005! Breaking HTTPS 1. Generate public/private key and root certificate 2. install that root certificate on client devices Web Browser TLS proxy HTTPS Server 4. TLS Hello 3. Visit 5. TLS Hello website 6. Server Certificate
7. Validate certificate 8. Generate (spoofed) certificate, signed by our private key from (1)
9. (Spoofed) Server Certificate Did we forget someone?
• 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 Configuring Decryption on the WSA 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 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 • Network85.17.181.244:443 Device redirects traffic to WSA using WCCP • WSA proxies the request
Web Security Appliance Internet Web IPv6 server IPv4
Internet ASA NGFW Certificate installation and usage - recap
• 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 certificate with (nearly) all the fields and sign this with her own certificate • CRL 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 Certificate installation and usage BASIC CONTRAINTS : Critical • https://tools.ietf.org/html/rfc5280#section-4.2
“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 Certificate installation and usage
• Browser Companies & CA phasing 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
• 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 General SSL Settings
• Settings for the HTTPS Proxy Service • Protocol to use • Cipher String to use • Disable compression General SSL Settings (2) - Cipher strings openssl ciphers ‘ALL’ Use all ciphers openssl ciphers ‘HIGH:MEDIUM’ Use only ciphers classified as HIGH and MEDIUM openssl ciphers ‘HIGH:MEDIUM:-RC4’ Use only HIGH &MEDIUM and no RC4
…. ‘HIGH:MEDIUM:-RC4:-eNULL:-aNULL’ HIGH & MEDIUM, no RC4,, no NULL authentication & NULL encryption
‘HIGH:MEDIUM:-RC4:@strength’ @strength : sort based on strength Recommended (by Toby…) Cipher String – v9.0.1
• Default string, moving ephemeral DH to the front, disabling EXPORT Ciphers, Ciphers with less than 128 bit symmetric key and RC4
• Before disabling TLS 1.0 , a personal risk assessment is recommended! General SSL Settings (3)
• 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 General SSL Settings (2)
• 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…. Decryption Policy
• Policy can be based on • Identification Profile (Identity) • URL Category • Web Reputation
• Additional Options Decryption Policy (2)
• Categories • “Pass Through” will still check for certificate errors! • Invalid certificate or expired certificate on the server will fail the “Pass through” Decryption Policy (3)
• 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! Decryption Policy (4)
• 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 Decryption Policy (5)
• 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 Decryption Policy (6)
• 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 Decryption Policy (7) – good to remember….
• 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 better performance Validating the Certificate Chain
Root CA
Intermediate CA
Server Certificate Validating the Certificate Chain (2)
• To validate the chain, the client needs to have the complete chain • Some servers send the intermediate and the server cert (that’s appreciated!) • Some servers send the server cert only (suboptimal and not RFC compliant) • Some servers send all certs, including the root (unnecessary…) Validating the Certificate Chain (4)
• Some servers send the server cert only …
• Browser checks the extension “Authority Information Access” • This tells him where to find the next certificate • Browser downloads it and can now check if it is valid WSA: Missing Intermediate Certificate
• Some websites use an intermediate CA that is not in the trusted store
• Workaround: Manually import the certificate into the trusted root store Validating the Certificate Chain (6)
• 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) Validating the Certificate Chain (7)
• 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) Validating the Certificate Chain (9)
• 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 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… Certificate Error Handling
• 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? Certificate Revocation “Drop” requires • Certificates can be revoked “Decrypt for EUN” • OCSP is the standard protocol to check if a certificate is revoked (OCSP largely replacing CRL) Certificate Revocation
• OCSP Information is found in the “Authority Information Access” extension Certificate Revocation
• EUN for a revoked Certificate ACL Decision Tag Decoded Access or ACL Decision Tag Identity Decryption Policy
DECRYPT_WEBCAT_7-DefaultGroup-ID.MUNSEC-NONE-NONE-NONE-DefaultGroup
Outbound Malware Data Scanning Security External Routing Policy Policy DLP Policy Policy ACL Tag Decoded Using Splunk for Cisco WSA (!= Cisco Advanced Reporting) sourcetype=cisco:wsa:squid acltag="*" status!=000| eval acl_new=split(acltag,"-") | eval acl_decission=mvindex(acl_new,0) |eval acl_policy=mvindex(acl_new,1)|eval acl_identity=mvindex(acl_new,2)| eval acl_routing=mvindex(acl_new,6) | stats count by host,status,acl_decission,acl_policy,acl_identity,acl_routing |sort host,-count ACL Tag Decoded Using Splunk for Cisco WSA (!= Cisco Advanced Reporting) ACL Tag Decoded Using Splunk for Cisco WSA (!= Cisco Advanced Reporting)
Certificate Errors Identity Policy Trace & Certificate error
• Certificate error handling set to “Monitor” Policy Trace & Certificate error
• Certificate error handling set to “Drop” WSA and TLS
• 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 Decrypting Web Category “Search Engines” Explicit mode
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
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
• 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 “Server Hello” and server certificate Decrypting Web Category “Search Engines” Transparent mode
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
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
• 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. WSA and TLS • Should we decrypt? Very often based on URL Category...(think of finance websites...) WSA and TLS • Should we decrypt? Very often based on URL Category...(think of finance websites...) WSA and TLS
• 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: Server Name Indication - Test
Connection without SNI…
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 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 Server Name Indication
• Recommendation: SNI should always be enabled • Especially in transparent deployments!
• When upgrading from 7.5 release, check if it is enabled!
• Done via CLI, “advancedproxyconfig” Troubleshooting TLS HTTPS Logs on WSA – Level “Trace”
Trying TLS 1.0, Server refuses
Trying SSLv3, Server refuses Usage of OPENSSL
Cannot verify the certificate? Update your certs Usage of OPENSSL (2)
All Good! Point to the storage for the root CAs Testing the Server for a specific Protocol
Openssl can test TLS Connection Check if the Server Supports TLS 1.2 simulating the client side Testing the Server for a specific Protocol (2) Yes, it Does! Testing specific Ciphers Check if the server supports ECDH Ciphers and TLS 1.2
Cipher that was selected Wireshark
• Display all packets for finding the TLS handshake “ssl.record.version==0x303 or ssl.record.version==0x301” Easier to check a Website https://www.ssllabs.com/ssltest/
• Check a Website for all things around TLS • Ciphers • Certificates • Handshake Simulations • … • Powered by Qualys WSA settings for TLS
• Use AsyncOS 9.0.1+
• 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 WSA settings for TLS (2)
• Make sure that OCSP checking is enabled (Drop Revoked)
• Check your Cipher String, disable RC4, Export & Keys lower than 128bit • Recommendation: “DEFAULT:kEDH:-EXP:-LOW:-RC4”
• 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 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
• Alternative: SSLYZE from https://github.com/nabla-c0d3/sslyze/releases • OPENSSL CLI commands
• 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
• Check the https_logs -> put at least into “DEBUG” mode, better: “TRACE”
• Check the PCAPS Common SSL Issues
• 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
• 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 9.0.1+ 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 Thoughts about the future… HTTP “Pipelining”
• HTTP 1.0 • One Request -> One Response • “Head of Line” Blocking Problem (like a Supermarket with only one register)
• HTTP 1.1 “Pipelining” • Multiple Requests sent at once • Opening more Registers in the Supermarket… • Still, Responses have to arrive in the order the Requests were sent….Does not solve the “Head of Line” Blocking Problem • Most Browsers might limit the amount of connections you can send at once. SPDY (“Speedy”)
• Three main enhancements over HTTP 1.1
• Header Compression
• True Connection Multiplexing (on the server),
Request as many connections as you want and receive responses in any order by using only one SPDY Connection
Prioritization of the responses is left to the client
• PUSH Content to the client
Using a existing SPDY connection without the client need to send a request first. A lighter Version would just send a “Hint” SPDY & HTTP2 • SPDY Protocol might be a problem for intermediate Gateways, proxies, … as they might not be able to understand it.
• To overcome this problem: • SPDY is using TLS for tunneling its data between client and server
• Limitations of SPDY • SPDY uses TLS, no visibility of Gateway, Malware scanners, etc!! • Multiplexing will only occur on a per host basis
A website that has content from 16 other servers will require the client to open 16 connections
• HTTP/2 Specification is strongly based on input from SPDY & TLS http://daniel.haxx.se/http2/http2-v1.8.pdf https://www.ietf.org/blog/2015/02/http2-approved/ HTTP, HTTPS, and HTTP2 Layering
http:// https:// http:// https://
6-8 TCP connections per site Fewer TCP connections HTTP2 (SPDY) 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=spdy TLS 1.3 – draft https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-1.2
• Reducing overhead by using a 1-RTT handshake • Fallback to normal handshake if client cannot handle it • Working on a 0-RTT Session resumption
• Remove non-AEAD Ciphers (CBC), compression, RC4, MD5, SHA224
• Remove of RSA authentication mode • Using DHE / ECDHE instead for PFS
• Encrypting more values in the handshake Partial TLS Handshake (TLS 1.0 – 1.2) 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 Partial TLS Handshake (TLS 1.3) 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 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! Certificate Pinning – RFC 7469 • 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 Demo: Certificate Pinning 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-rfc5246-bis-00 Summary WSA has good TLS decryption capabilities in Version 9.0.1+ • Granular policies when to decrypt can be made • However: Big Trend to have much more encrypted connections on the Internet and everyone that wants to decrypt connections needs to adopt. Transparent proxies & NGFW will have a bigger challenge in the future to be able to provide security by decrypting all traffic Alternative methods need to be considered in a layered approach Cisco Technologies in related Sessions: • Cognitive Threat Analytics – BRKSEC-3011 • OpenDNS – BRKSEC-2049 • Netflow – BRKSEC-2026 • Endpoint Security (AMP) – BRKSEC-2139, BRKSEC-2051 Call to Action
• Visit the World of Solutions for • Cisco Campus – WSA, CTA, OpenDNS • Technical Solution Clinics
• Meet the Engineer • Book me via CiscoLive MTE or drop me an email for further questions
• Lunch and Learn Topics
• Check out www.ciscolive365.com for recorded past Sessions Complete Your Online Session Evaluation
• Please complete your online session evaluations after each session. 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 Thank you