HTTPS Hsu-Chun Hsiao CSIE Department National Taiwan University

Agenda • Warming up • SSL/TLS • Overview • Known attacks • Case study of banking apps

2

Mobile Apps

3

Malicious Apps • Can’t download “Pokemon Go!” from the official app market • Get a copy from a 3rd party site?

https://www.proofpoint.com/us/threat-insight/post/droidjack-uses-side-load-backdoored-pokemon-go-android-app

4

Weak Passwords

5

Weak Passwords

6

http://wpengine.com/unmasked/ 7

Ransomware

8

Ransomware • Anti-virus testing results • More popular != more secure

By Chung Po Wei, Choi Oi Si, Lou Chon Fai

9

Clickjacking

https://adwords.googleblog.com/2016/04/more-defenses-roll-out-to-thwart-clickjacking.html

10

Clickjacking

https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009) 11

Clickjacking Demo

https://www.youtube.com/watch?v=gxyLbpldmuU

12

SSL/TLS Overview

13

14

https://www.ssllabs.com/ssltest

15

SSL/TLS overview • Goal: building a secure end-to-end channel • SSL = Secure Sockets Layer (predecessor) • TLS = Transport Layer Security (standard) • HTTPS = HTTP over SSL/TLS

• Security requirements • Confidentiality • Integrity • Authentication (mostly server authentication, client authentication in TLS is rare)

16

SSL/TLS history • • • • • • •

SSL 1.0: Designed by Netscape, never deployed SSL 2.0: 1995, deployed in Netscape Navigator 1.1 SSL 3.0: 1996, substantial overhaul, fixing security flaws, publicly reviewed TLS 1.0: 1999, IETF standard improving on SSL 3.0 TLS 1.1: 2006 TLS 1.2: 2008, not backward compatible with SSL 2.0 TLS 1.3: IETF draft

• SSL 2.0 and 3.0 are disabled by default or not supported anymore for Chrome after v40, Firefox after v34, IE 11, Android 5.1, OSX 10.11 17

Why we should use TLS • HTTPS (HTTP over SSL/TLS) is a dominant protocol for securing HTTP communication • HTTPS prevents a man-in-the-middle attacker from eavesdropping and impersonation

18

HTTPS are actively promoted • Google uses HTTPS as a ranking signal • White House memorandum requires all publicly accessible federal sites to support HTTPS-only access with HSTS (HTTP Strict Transport Security) by the end of 2016 • https://https.cio.gov/everything/

• EFF’s HTTPS Everywhere Browser Plugin automatically replaces HTTP with HTTPS if exists • https://www.eff.org/https-everywhere/

• Let’s Encrypt: a free, automated, and open certificate authority • https://letsencrypt.org/ 19

TLS overview

HTTPS

http://www.ibm.com/developerworks/library/ws-ssl-security/

20

TLS overview • TLS handshake protocol • Negotiate protocol version and cryptographic parameters • Use digital certificates to authenticate server and client • Use public-key cryptography to establish a shared secret key (a session key) between client and server

• TLS record protocol • Use the secret key established in handshake to protect communication between client and server

21

TLS Handshake Protocol (Simplified) Hello

Entity Authentication & Key Exchange

Finish

22

TLS Handshake Protocol 1. ClientHello 2. ServerHello 3. ServerCertificate 4. ServerKeyExchange 5. CertificateRequest (if client auth enabled) 6. ServerHelloDone 7. ClientCertificate (if client auth enabled) 8. ClientKeyExchange 9. CertificateVerify (if client auth enabled) 10. ChangeCipherSpec 11. Finish 12. ChangeCipherSpec 13. Finish

23

TLS Handshake: Client Hello & Server Hello • Client announces the highest supported protocol version and supported cryptographic algorithms (a.k.a. cipher suite) in decreasing order of preference • Server responses with strongest protocol version and algorithm supported by both client and server • The exchange is in plaintext • Need to check integrity at the end 1. ClientHello: I can support these 2. ServerHello: ok let’s pick this one 24

TLS Handshake: Client Hello & Server Hello • pvmax: highest supported protocol version • CR: client’s random number • pv: selected protocol version • SR: server’s random number • sid: session ID 1. ClientHello: pvmax, CR, CipherSuiteList 2. ServerHello: pv, SR, sid, CipherSuite

25

Cipher Suite • Cipher suite = key exchange + signature + encryption + hash algorithm TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA Key exchange

Signature

Encryption

Hash function

26

Cipher Suite • Key exchange algorithms TLS_RSA

RSA, encrypt key with receiver’s RSA public key

TLS_DH TLS_ECDH

Fixed Diffie-Hellman, public-key certificate contains public DH key

TLS_DHE TLS_ECDHE

Ephemeral Diffie-Hellman, public key is used to sign temporary DH key

TLS_DH_anon TLS_ECDH_anon

Anonymous Diffie-Hellman, DH without authentication Strongly discouraged, Susceptible to MitM

Recommended: Provide forward secrecy

27

Cipher Suite • Signature algorithms: RSA, DSA, ECDSA • Encryption algorithm: RC4, RC2, DES, 3DES, DES40, IDEA, AES • Message authentication algorithm: HMAC-MD5, HMAC-SHA1, HMACSHA256/384

28

TLS Handshake: Server authentication and key exchange 3. ServerCertificate: digital certificate certs, pks 4. ServerKeyExchange: message depending on the chosen key exchange algorithm 5. CertificateRequest: list of acceptable certificate authorities (if client auth enabled) 6. ServerHelloDone

29

TLS Handshake: Client authentication and key exchange 7. ClientCertificate: certc, pkc (if client auth enabled) 8. ClientKeyExchange • RSA: client generates 48-byte pre-master secret, encrypts it with server’s public key • Eph or anon DH: client’s public DH value • Fixed DH: none (certificate contained DH key)

Compute or select a premaster secret (PS) 9. CertificateVerify: sign(handshake_log1) (if client auth enabled) Compute or receive the pre-master secret (PS) 30

Establishing shared keys • Compute master secret (MS) from pre-master secret (PS), client random (CR) and server random (SR) • From the shared master secret, derive • • • • • •

Client MAC key Server MAC key Client encryption key Server encryption key Client IV Server IV

31

TLS Handshake: Change cipher spec and finish 10. ChangeCipherSpec: alerts server to start using the negotiated ciphers and key 11. Finish: Verify_data(MS, handshake_log2) 12. ChangeCipherSpec 13. Finish: Verify_data(MS, handshake_log3)

32

Known issues in SSL/TLS

33

Current status: Far from universal adoption

https://www.trustworthyinternet.org/ssl-pulse/ https://www.ssllabs.com

34

Current status: Far from universal adoption • ~40% of login pages are unprotected • Inconsistent implementation • E.g., delta.com will redirect to HTTPS automatically but www.delta.com won’t

Known issues in SSL/TLS • Weakness in crypto primitives • Weak encryption & signature key lengths (40, 56, 64 bit encryptions subject to brute force attack) • Weak hash functions (MD5)

• Oracle attacks • Compression • CBC Initialization (e.g., predictable IVs) • CBC padding

Jeremy Clark and Paul C. van Oorschot. SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. In Proceedings of IEEE Symposium on Security and Privacy, 2013. 36

Known issues in SSL/TLS • Protocol-level attack • Ciphersuite downgrade attack • Version downgrade attack • Renegotiation attack

• Implementation flaws • Remote timing attacks • PRNG seeding

Jeremy Clark and Paul C. van Oorschot. SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. In Proceedings of IEEE Symposium on Security and Privacy, 2013. 37

Known issues in SSL/TLS • Trust model issues • • • • •

Certification: hostname validation, parsing attacks, EV downgrading Anchoring trust: CA compromise, compelled certificates Transitivity of trust: basic constraints Maintenance of trust: blocking revocation, ownership transfer Indication and interpretation of trust: stripping TLS, spoofing browser, ignoring warnings, low-risk warnings

Jeremy Clark and Paul C. van Oorschot. SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. In Proceedings of IEEE Symposium on Security and Privacy, 2013. 38

Examples Example

type

Low-risk warnings mask high-risk warnings

Trust model issues

Incorrect certificate validation

Trust model issues Implementation flaws

Rollback attack

Protocol-level attack

SSL stripping attack

Protocol-level attack

FREAK attack

Implementation flaws

Logjam attack

Weak crypto Protocol-level attack

RC4 NOMORE attack

Weak crypto

39

Examples Example

type

Low-risk warnings mask high-risk warnings

Trust model issues

Incorrect certificate validation

Trust model issues Implementation flaws

Rollback attack

Protocol-level attack

SSL stripping attack

Protocol-level attack

FREAK attack

Implementation flaws

Logjam attack

Weak crypto Protocol-level attack

RC4 NOMORE attack

Weak crypto TLS 40

Rollback attack in SSL 2.0 • What if Eve manipulate the hello messages? • Protocol version and cipher suite preferences were not authenticated in SSL 2.0 ClientHello: TLS 1.2, AES, SHA256, …

ClientHello: SSL 2.0, RC4, MD5, …

ServerHello: ok, let’s use SSL 2.0, RC4, MD5…

41

Rollback attack fixed in SSL 3.0 • Finished message contains a MAC on all the handshake protocol messages keyed by the master secret • Server can detect tampering at the end of the handshake and terminate the session if necessary

42

SSL Stripping attack • Users are not used to type https://url directly

http://www.google.com

Redirect to https://www.google.com

http://www.thoughtcrime.org/software/sslstrip/ https://github.com/moxie0/sslstrip

43

SSL Stripping attack • Users are not used to type https://url directly • A MitM attacker ‘strips’ HTTPS into HTTP

http://www.google.com

https://www.google.com

http://www.thoughtcrime.org/software/sslstrip/ https://github.com/moxie0/sslstrip

44

SSL Stripping attack • Root cause: HTTPS is not used since beginning • Countermeasures • HTTP Strict Transport Security (HSTS) • “allows a web server to declare that web browsers should only interact with it using secure HTTPS connections” • HTTPS Everywhere https://www.eff.org/https-everywhere/ • E.g. EFF’s HTTPS Everywhere Browser Plugin automatically replaces HTTP with HTTPS if exists

Kranch, Michael, and Joseph Bonneau. "Upgrading HTTPS in mid-air: An empirical study of strict transport security and key pinning." NDSS, 2015.

45

The FREAK attack https://freakattack.com/ • FREAK = Factoring Attack on RSA-EXPORT Keys • Problem with “export-grade” encryption • Export controls in 90s by the US government • Deliberately weakened crypto techniques

46

The FREAK attack • FREAK exploits a bug in TLS client implementation • Several implementations incorrectly allow the message sequence of export ciphersuites to be used even if a non-export ciphersuite was negotiated

• “It allows an attacker to intercept HTTPS connections between vulnerable clients and servers and force them to use weakened encryption, which the attacker can break to steal or manipulate sensitive data.” • Cost per site: 7 hours and $100 USD

47

https://mitls.org/downloads/SmackTLS-Oakland15.pdf

48

https://mitls.org/downloads/SmackTLS-Oakland15.pdf

49

https://mitls.org/downloads/SmackTLS-Oakland15.pdf

50

Logjam attack https://weakdh.org/ • David Adrian et al. "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice.” ACM Computer and Communications Security, 2015. • A man-in-the-middle downgrades connections to “export-grade” Diffie-Hellman DHE_EXPORT • Downgraded TLS to legacy 512-bit security • A week-long precomputation for a 512-bit prime, and then can compute individual discrete logs in a median of 70s • Can practically break TLS

51

Logjam attack • Exploit two weaknesses in many DH implementation: • Support weak, obsolete export-grade crypto • 8.4% of top one million HTTPS sites

• Use hard-coded, widely shared Diffie-Hellman parameters • Two 512-bit DH groups used by > 92% of the vulnerable servers

52

53

DHE_EXPORT • DHE_EXPORT is exactly the same as DHE except using a 512-bit group • Many libraries and servers support DHE_EXPORT for backward compatibility • This was considered safe because Modern TLS clients don’t accept DH_EXPORT

54

Logjam vs. FREAK • Both downgrade to export-grade crypto • Logjam leverages a TLS protocol flaw • FREAK relies on an implementation vulnerability

55

Breaking Diffie-Hellman • The best known cryptoanalytic attack against Diffie-Hellman is computing discrete logs • Baby-step giant-step • Pollard rho • Pohlig-Hellman

• However, it’s less known that with a large pre-computation for a prime p, one can efficiently compute any discrete logs modulus p

56

How Logjam attack works • Goal: downgrade DHE -> legacy 512-bit DHE_EXPORT • Challenges: • Modern browsers don’t negotiate export-grade ciphersuites • SSL 3.0 and above checks the integrity of the handshake message to prevent downgrade

57

How Logjam attack works • Logjam exploits a flaws in TLS handshake: • The message structures for DHE and DHE_EXPORT are the same • Also, the signed message doesn’t include any indication of the specific ciphersuite that the server has chosen

• A man-in-the-middle who can compute 512-bit discrete log in real time can downgrade a regular DHE connection to use a DHE_EXPORT group • The client thinks it’s using DHE • The server thinks it’s using DHE_EXPORT 58

MitM pretends to be server and passes the integrity check

59

Suggestions • Disable export-grade cryptography • Enforce strict policy on size and use of known DH groups • Transit to elliptic curves

60

Examples Example

type

Low-risk warnings mask high-risk warnings

Trust model issues

Incorrect certificate validation

Trust model issues Implementation flaws

Rollback attack

Protocol-level attack

SSL stripping attack

Protocol-level attack

FREAK attack

Implementation flaws

Logjam attack

Weak crypto Protocol-level attack

RC4 NOMORE attack

Weak crypto

61

How it is done today: X.509 Public Key Infrastructure (PKI) • A hierarchy of Certification Authorities Root CA

…

62

How it is done today: X.509 Public Key Infrastructure (PKI)

A. Delignat-lavaud, C. Fournet, M. Kohlweiss, and B. Parno, “Cinderella: Turning Shabby X.509 Certificates into Elegant 63 Anonymous Credentials with the Magic of Verifiable Computation,” in S&P, 2016.

Root certificates • All your trust relationships online are reduced to trusting this list of root certificates

OS X Keychain

64

65

Certificate warnings

This server could not prove that it is www.cnn.com; its security certificate is from a.ssl.fastly.net. This may be caused by a misconfiguration or an attacker intercepting your connection. 66

Websites certified by unknown root CAs

67

Example of trust model issues: Low-risk warnings mask high-risk warnings • Some browser implementation shows only one error • Users may just click through if the one being shown looks relatively low risk • Safari 7 or Chrome 30 (on Linux): for a self-signed recently-expired certificate, the only error warning is ‘Expired certificate’ • Opera: for an invalid certificate containing a 512-bit RSA key, Opera only warns ‘Weak Key’ Brubaker, Chad, et al. "Using frankencerts for automated adversarial testing of certificate validation in SSL/TLS implementations." In Proceedings of IEEE Symposium on Security and Privacy, 2014.

68

Real-world issues with PKIs/CAs • Too many CAs • Rouge CAs or stolen certificates • “Two code-signing certificates, stolen from two separate chip manufacturers (JMicron and Realtek) in Taiwan…” • March 2011: “in an attack on a Comodo reseller, fake certificates were issued for mail.google.com, www.google.com, login.yahoo.com, login.skype.com, login.live.com, and addons.mozilla.org”

• Certificate revocation

69

Too many CAs & root certificates • Pre-loaded into browser and/or OS • ~150 root certificates from ~50 organizations • Roots certificates can authorize intermediate CAs • EFF’s SSL Observatory reports that Microsoft IE and Mozilla Firefox trust 1482 different CA public keys held by 651 organizations located throughout the world • Any CA can issue an acceptable certificate for any site 70

Rouge CAs & stolen certificates • Attacker uses a fake certificate that passes browser check • Who wants to do this? • • • •

Organizations monitoring traffic Governments doing censorship Cloud providers …

• How? • • • •

Compromised CAs Compelled certificates Browser not checking correctly (perhaps on purpose) … 71

72