network impacts of https transport...

Network Impacts of HTTPS Transport Encryption

BRKSEC-2525

Dan Wing, Distinguished Engineer

GSSO

© 2015 Cisco and/or its affiliates. All rights reserved.BRKSEC-2525 Cisco Public

Agenda

• Introduction to Proxies

• HTTP Inspection Background

• HTTPS Inspection

• Future

3


Abstract, in bullet points

• Background on how network security is performed on plain-text traffic

• Why network traffic is moving towards more encryption

• Decryption using TLS proxies

• Future protocols and solutions

• This presentation contains no product-specific information

• This is not a "how to" presentation

4


Objectives

• Review network security is performed on un-encrypted traffic

• Review TLS proxy interception

• Protocol futures

5


Introduction: Encryption Impacts Network Security

• Security features need access to plain text

• IPsec, SSL, TLS

• Breaking TLS

• Encrypted HTTPS is 30-40% of cellular wireless traffic, and rising

• Decryption is not always possible

• Where decryption is possible, decryption adds cost

25-35%, “SSL Performance Problems: Significant SSL Performance Loss Leaves Much Room for Improvement,” NSS Labs, June 2013


TLS versus IPsec

• TLS – Transport Layer Security

– Runs over TCP – easy firewall and NAT traversal

– very widely deployed

– Typically, only server is validated (client is not validated with TLS)

• IPsec

– Designed for computer-to-computer and network-to-network (VPN)

– Lots of modes = lots of confusion• IPsec tunnel mode, transport mode

• IPsec AH, ESP

– IP protocol 50 (ESP), 51 (AH)• Requires NAT&firewall IPsec passthrough support

• IPsec-over-UDP, IPsec-over-TCP (non-standard)

– IKE-over-UDP exchange separate from IPsec

7


SSL and TLS Versions

• SSL 1, SSL 2, 1995, designed by Netscape

– Contained security flaws

• SSL 3, 1996

– RC4 vulnerable, and SSLv3 block ciphers vulnerable to POODLE attack

• TLS 1.0, 1999, RFC2246

• TLS 1.1, 2006, RFC4346

– Improved security

• TLS 1.2, 2008, RFC5246

– Improved security (key derivation, SHA256)

– Improved negotiation of hashes and signatures

– Supports authenticated encryption ciphers (AES-GCM, CCM mode)

• TLS 1.3, currently Internet Draft

9


Breaking Encryption

• Transport encryption

– TLS: HTTPS, mail (SMTP, IMAP), others

– TLS: certain applications (e.g., Dropbox client)

– DTLS: WebRTC, DTLS-SRTP, Cisco AnyConnect

– IPSec: VPN

• Email Object encryption

– Impacts content security

– PGP (Gmail, Yahoo), S/MIME (Apple iOS, Outlook)

Proxy with TLS client

cooperation

Generally un-breakable,

due to mutual

authentication and/or

certificate pinning

HTTPS – HTTP over SSL (TLS)

TLS – Transport Layer Security (TCP)

DTLS – Datagram Transport Layer Security (UDP)

PGP – Pretty Good Privacy

S/MIME – Secure/Multipurpose Internet Mail Extensions


Breaking Encryption: HTTPS Instant Messaging

• Transport encryption

– TLS: HTTPS, mail (SMTP, IMAP), others

– Applications using HTTPS-style authentication can be also be proxied

– Facebook Messenger

– Snapchat

– What’app

– Threema

Proxy with TLS client

cooperation


When can HTTPS be proxied (decrypted)?

Cannot Decrypt

• Endpoint does not cooperate

– Internet Service Provider

– Guest WiFi

• Certain applications

– (Dropbox, iTunes, …)

Can Decrypt

• Endpoint cooperates

• Install additional root certificate on client (operationally complex)

• Decrypt TLS, examine or modify, re-encrypt TLS

• Expensive to decrypt TLS everywhere

– Hardware and Operational / debugging complexity

Client TLS Proxy ServerInternet


Reasons Sites Use HTTPS Encryption

Subscriber Benefit

• Subscriber privacy

– Health research

• Avoid passive surveillance

• Lock icon (🔒)

• Avoid malware injection

Site Benefit

• Account information

– credit card, bank information, passwords

• Prevent ISP from:

– Selling subscriber web history

– Injecting advertising

– Breaking page operation

• Better Google ranking

Benefits both

• Avoid broken caches/proxies

• HTTP2

• Prevent ISP from degrading user experience

– Video quality degradation

• Avoid Chrome HTTP warning (future)


Reasons Sites Avoid HTTPS Encryption

• Loss of caching

• Certificate cost ($50-$1500/year)

• Slower page load times

• Equipment cost

• Client CPU and battery consumption


Reasons Sites Avoid HTTPS Encryption

• Loss of cachingfuture: Sub-Resource Integrity

• Certificate cost ($50-$1500/year)www.LetsEncrypt.org

• Slower page load timesHTTP2 and TLS 1.3 improve page load times

• Equipment cost

• Client CPU and battery consumption (minor)


Reasons ISPs / Enterprises Dislike HTTPS Encryption

ISPs

• Optimize network with caching

– Streaming or live video

– Static images

• Inject advertising

• Sell customer traffic data

• “bad proxies”

Enterprises

• Increased cost and complexity of content security

• Content and priority policies

– Deep Packet Inspection (DPI), legal requirements (stock broker, bank)

• “good proxies”


Good Proxies / Bad Proxies

• Good proxy: provide value to end user or the network owner

– Block malware

– Block spam

– Cache content

• Bad proxy: harm the end user

– Intercept user’s traffic• banking transaction, credit card number, health-related searches

• Creates legal liability (risk)

– Interfere with protocol features• HTTP 1.1 pipelining, HTTP2, HTTP DELETE method

– Inject malware

– Break web page functionality • advertising injection, video quality degradation

• A proxy can be both good and bad, depending on perspective!

18


The Trouble with Proxies

• Proxies harm protocol evolution

– Measured 20% failure rate trying to use “Upgrade: HTTP2” over un-encrypted TCP

– Mis-handling HTTP 1.1 features (especially pipelining)

• “Erosion of the moral authority of transparent middleboxes”

– Joe Hildebrand (Internet Architecture Board, Cisco), Patrick McManus (Mozilla)

– Discusses how middleboxes (proxies) harm protocol evolution

19

http://tools.ietf.org/html/draft-hildebrand-middlebox-erosion


Industry Encryption Efforts

• Encryption by default: Google, Gmail, Facebook, Twitter, …

– Started over a year before Snowden

• IETF IAB

– Statement of Internet Confidentiality

– Stack Evolution in a Middlebox Internet (SEMI) workshop this week in Zürich

• W3C TAG, Securing the Web

• TLS 1.3 improvements

– Fewer messages for faster set up

– Encrypts TLS handshake, including server’s (and client’s) certificate

• Let’s Encrypt

20

https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentialityhttps://w3ctag.github.io/web-httpshttp://www.iab.org/activities/workshops/semi/


Let’s Encrypt

• Free certificates for servers

• Non-profit organization

• Sponsored by Cisco, Mozilla, Akamai, EFF, and IdenTrust

• Software will:

– Automatically prove to the Let’s Encrypt CA that you control the website

– Obtain a browser-trusted certificate and set it up on your web server

– Keep track of when your certificate is going to expire, and automatically renew it

– Help you revoke the certificate

• https://letsencrypt.org

21

$ sudo apt-get install lets-encrypt

$ lets-encrypt example.com


Email Encryption (Object Encryption)

• Content security needs access to plaintext

• End-to-end encryption prevents access to plaintext

– PGP

– S/MIME

• Today, most users simply delete encrypted email

– So encrypted spam/malware is not a threat

• Tomorrow, if encrypted email is easier, it becomes easy vector for malware and phishing

• Ongoing research

22

HTTP Inspection


Overview of Network Inspection

• Packets cross packet boundaries

– Overlapping TCP segments

• JavaScript Obfuscation

• IPv4/IPv6

24


Client

Application Inspection

• Inspect request URL against blacklist and reputation database

• Inspect response data for malicious payloads

25

Inspect

Server

Inspect

TCP stream re-assembly



Payloads across Packet Boundaries

• Happens naturally at packet boundaries

– 1500 bytes

• Can happen maliciously

• Solution: re-assemble TCP

26

GET INDEX.HTML HTTP/1.1

GET IN DEX.HTM L HTTP/1.1

TCP

IP

TCP

IP

TCP

IP


Obfuscation to break pattern matching

• Request http:://example.com///index.htm

• Response:

27

document.write('<'+'ifr'+'ame '+'

sr'+'c'+'='+'"http://etetyum.ZZZ/...

Document.write(‘<iframe

src=“http://etetyum.ZZZ/...


Dual Stack Complications

• Malware might be split between IPv6 / IPv4

– Get part “A” of malware via IPv4, part “B” over IPv6

• Requires identifying hosts, rather than assuming host has one IP address

• Ongoing research

28

HTTPS Inspection


HTTPS Inspection

• Operation of TLS Proxy

• Performance

• How TLS proxy performs its job

• Certificate Pinning, Lawful Intercept

30


Client

Reminder: Application Inspection without TLS

31

Inspect

Server

Inspect




Client

TLS inspection

• TLS session start up: public key calculations (RSA, EC, DH)

• TLS session ongoing: authenticate (SHA1) and encrypt/decrypt (AES)

32

authenticate & decrypt

Inspectauthenticate

& encryptServer

Authenticate & encrypt

InspectAuthenticate

& decrypt

TLS Proxy


TLS Performance Impact: 20-30% of rated speed

0

2

4

6

8

10

Cisco-1 Cisco-2

HTTP

50% HTTPS

100% HTTPS

33


HTTPS through TLS proxy

• Browser and operating system trust 100’s of certificate authorities

• Method 1: add another CA to the client’s trust list

– Most common

• Method 2: purchase an intermediate root certificate

– Violates terms and conditions

• With either method, TLS proxy authenticates using your certificate’s private key


Breaking HTTPS: method 1, install additional root on client

Web Browser TLS proxy HTTPS Server

4. TLS Hello5. TLS Hello

6. Server Certificate

1. Generate public/private key and root certificate

2. install that root certificate on client devices

8. Generate (spoofed) certificate,

signed by our private key from (1)

9. (Spoofed) Server

Certificate

7. Validate certificate

3. Visit

website


Certificate Stores: OS or Application

Browsers using OS cert store

• Mobile Safari (iOS), Safari (Mac)

• Chrome, Chrome for Mobile

• Internet Explorer

Browsers using their own cert store

• Firefox: Preferences, Advanced, Certs

• Opera: Settings > Preferences > Advanced > Security > Manage Certs

36

• Android: Settings > Personal > Security > Credential storage > Install

• iOS: Configuration Profile (email or iPhone Configuration Utility)

• Windows: Management Console (MMC) or Group Policy Manager

• OS X: Keychain Access


“User-Installed Certificate” has Scoping Problem

• “User-installed certificate” is intended for enterprise Certificate Authorities

– Intent is abused by TLS proxies

– TLS proxy can assert itself as any website

– In the future, this abuse might be closed

• TLS proxy’s private key could be stolen, and examine/modify traffic

– Don’t lose the private key!

– Long certificate lifetime is riskier; changing certificates on client is $$

– Forward secrecy reduces risk (discussed later)


Breaking HTTPS: method 2, Intermediate root

• Clients already trust. Easy! No client configuration!

• Costs USD $120,000

• Contract states the certificate is “not for intercepting TLS”

• A significant risk to the Internet

• Browser vendors working to detect and disallow these certificates


User Detection of TLS Proxy

• Certificate warning error

– Unfortunately, users are accustomed to seeing errors (“OK to Continue”)

• Check certificate manually

– Awkward

• Browser plugin to “ask friends” about expected certificate

– Network notary / Perspectives

• Certificate pinning

How users notice TLS interception proxy

39


Certificate Pinning

• Shipping in Firefox and Chrome

• Solves two problems: rogue CAs, and $100,000 subordinate root certificates

• Specifies which CAs can authenticate a site

– Instead of ~300 CAs, now only 2 can authenticate a site

– Reduces man-in-the-middle attacks due to compromised CAs

• User-installed root certificates (“enterprise certificates”) ignore key pinning

– Firefox and Chrome

– TLS proxying works in conjunction with key pinning

– This means enterprises key pinning generates no error with enterprise certificates

• Applications enforcing pinning

– Dropbox client, iTunes, others

HTTP Public Key Pinning (HPKP), http://tools.ietf.org/html/draft-ietf-websec-key-pinning


Lawful Intercept

• Lawful Intercept

– Concept based on wiretapping

– Basic idea: duplicate packets

– Law enforcement can utilize metadata, even if data is encrypted

• Intercept target should not notice intercept

– Assuming average technical sophistication

– Certificate pinning makes TLS proxy more obvious

41

Future


Future

• Encryption Tussle

• New model: opt-in

• Caching with HTTPS

• Optimizing TLS proxy encryption and decryption

• HTTP2 (“SPDY”) and brief note on Google QUIC

• TLS 1.3

• Netflow for security

• Forward secrecy


Encryption Tussle

44

http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/privacy-and-data-protection-by-design

Government Companies

Citizens / Users

Encryption


Future: Browser opts-in to network value add

• Recall the good/bad proxies

– Good proxy: provide value to end user or the network owner• Block malware, spam

– Bad proxy: harm the end user

• Instead of an all-powerful implicit proxy, provide specific features to browser

– Cache objects

– Content security service

– Data loss prevention service

– Network bandwidth information (to optimize audio/video quality versus bandwidth)

45


Explicit Content Cache

• New model: explicit content cache

• Fetch integrity-protected object from somewhere nearby

– Another nearby device (Bluetooth, WiFi, cellular, optical)

– Nearby network storage (ISP cache, home router)

• A step towards Named Data Networking

• SubResource Integrity (SRI)

– Standardized by W3C, http://www.w3.org/TR/SRI

– Uses “ni” URI scheme (RFC6920)

– Available in Chrome

<script src="https://code.jquery.com/jquery-1.10.2.min.js"

integrity="ni:///sha-256;C6CB9UI...TQmYg?ct=application/javascript">


Optimize Decryption: Do TLS and DPI once

TLS, inspection, and action on each device

DPI and action on each device

TLS and inspection once, and do action on each device

today

Tomorrow:

Do TLS

once

Naïve and

expensive TLSTLS TLSTLS TLSTLS

TLSTLS


Optimizing TLS

• Each new TLS connection is an expensive public key operation (RSA)

• Each byte of encrypted data is expensive (AES, SHA-1)

• Make them easier!

• RSA -> Elliptic Curve Cryptography (ECC)

– ECC is faster to compute

– ECC keys are shorter (for same strength), fewer bytes on the wire

– Widely available

• AES-SHA1 -> ChaCha20-Poly1305

– 300% faster than AES-GCM

– Available in Chrome and Google servers

48


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

49

http://caniuse.com/#feat=spdyDaniel Stenberg’s HTTP2 tutorial paper, http://daniel.haxx.se/http2


HTTP, HTTPS, and HTTP2 Layering

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

Fewer TCP connections6-8 TCP connections per site

https://


HTTP, HTTPS, HTTP2, and Google QUIC

• QUIC provides its own security, congestion control, and interacts with HTTP2’s prioritization and multiplexing

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

www.wikipedia.org/QUIC


Partial TLS Handshake (TLS 1.0 – 1.2)

52

TLS Client TLS Server

TLS ClientHelloSNI=www.example.com

TLS ServerHelloCertificate for www.example.netSession key (encrypted with private key)

Desired server

Actual server

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


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

Partial TLS Handshake (TLS 1.3)

53

TLS Client TLS Server

TLS ClientHelloSNI=www.example.comClient’s Diffie-Hellman key

Desired server

Actual server{Encrypted by DH}

Can only blacklist using SNI; need to decrypt to whitelist

TLS 1.3: draft-ietf-tls-tls13


Netflow for Security

• Historically, Netflow was sampled

– Reduced performance impact

– Reduced traffic visibility

• Unsampled Netflow summarizes all traffic to/from a host

• Network is the sensor

• Analysis of Netflow traffic finds compromised hosts by their traffic patterns

– Host communicates to neighbors

– Host communicates to command and control servers

• Lancope useful

• Ongoing research within Cisco

54


(Perfect) Forward Secrecy

• With normal RSA, the server’s public key allows decrypting all previous traffic

– Don’t lose the private key!

• With Forward Secrecy, the server’s public key doesn’t allow decrypting previous traffic

• Forward secrecy often performed with a separate Diffie-Hellman exchange

– DH exchange is computationally expensive

– DH exchange is additional round-trip (optimized in TLS 1.3)

• TLS connection re-use means DH exchange is valid for days

– Days is not perfect, but days is better than years! Security is a trade-off

55

Summary


Conclusion

• HTTPS encrypted traffic is 30% of most networks, and will continue to grow

• Cisco Web Security Appliance and Cloud Web Security can inspect HTTPS

• Installing root certificate on clients will remain an operational headache

• Future will provide mechanisms to cache content

57


Related Sessions

• BRKSEC-3772, Advanced Web Security Deployment with WSA, Tobias Mayer

• BRKSEC-3127, Dive into Cisco’s Email Encryption Capabillities, Hrvoje Dogan

• BRKSEC-2909, In Search of the Silver Bullet for Protection, Jonny Noble

• BRKSEC-2053, Practical PKI for Remote Access VPN, Ned Zaldivar

• BRKSEC-3128, Secure your network with distributed behavioral analytics, JP Vasseur

• BRKSEC-2136, Preventing Armageddon: Finding the threat with Netflow, Matt Robertson

58


Call to Action

• Visit the World of Solutions for

– Cisco Campus – Security Booth

– Technical Solution Clinics

• Meet the Engineer

– I am available this afternoon, see me after this session

• Lunch time Table Topics

• DevNet zone related labs and sessions

• Recommended Reading: for reading material and further resources for this session, please visit www.pearson-books.com/CLMilan2015

59

http://www.pearson-books.com/CLMilan 2015


Complete Your Online Session Evaluation

• Please complete your online sessionevaluations 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 viathe Cisco Live Mobile App or theCommunication Stations

60

network impacts of https transport...

Documents