There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to op
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
