HTTPS
Cassio Goldschmidt
Jim Manico
1
Jim Manico
@manicode
OWASP Volunteer
Global OWASP Board Member
OWASP Cheat-Sheet Series
Project Manager and
Contributor
Developer Security Educator
18 years of web-based,
database-driven software
development and analysis
experience
Author "Iron Clad Java, Building
Secure Web Applications" with
Oracle Press (Sept 2014)
Kama'aina Resident of Kauai, Hawaii
-
Aloha!
Cassio Goldschmidt
http://cassiogoldschmidt.com
4
5
6
7
They use crypto. I saw the
padlock in the browser.
Oh, no!
8
What is SSL/HTTPS/TLS?
What’s another way of looking at the benefits of
SSL/TLS?
• Confidentiality: Spy cannot view your data
• Integrity: Spy cannot change your data
• Authenticity: Server your are visiting is the
right one, backed up by the Certificate
Authority System
TLS Protocol Workflow
• TLS Uses Both Symmetric and Asymmetric
Encryption
• SSL Exchanges Symmetric Keys Encrypted
With Asymmetric Keys, then falls back to
Symmetric encryption
• Why? Symmetric encryption is MUCH faster.
Assmetric is slower but stronger.
SSL/TLS Protocol Versions
SSL v1, v2 — Broken. Do not use!
SSL v3 — Almost secure. (Not secure)
• might be ok to eliminate!
TLS 1.0 - "ok"!
TLS 1.1 - No known practical attacks!
TLS 1.2 — Best available; includes new ciphers
#1 Most Important Thing on Getting SSL Right
Update your OS to latest patch level
If you are using Apache 1.3, WTF
• Just focus on getting up to date with Apache
2.2/2.4
• This will update your OpenSSL library, fixing
numerous problems
Courtesy of @ngalbreath
Relevant Attacks on TLS Protocol
• 2011 BEAST
• Upgrade to TLS 1.1
• Use RC4 for older protocols. Mitigated by browsers
• 2012 CRIME
• Stop using TLS compression
• 2013 BREACH
• Vendors disabled HTTP compression in client and server side
• Mask Sensitive tokens, randomize them per request
• 2014 Heartbleed
•
Abuse the heart beat feature in OpenSSL to retrieve chucks of memory for
the server
13
HTTPS
CA #fail
Feb
2012
HTTPS
CA #fail
December
2012
HTTPS
CA #fail
December
2013
HTTPS
Registrar
#fail
December
2012
OpenSSL
#fail:
Heartbleed
2014
How Heartbleed Works
HTTPS Developer #fail
•
•
•
•
•
•
•
•
Posting passwords or sensitive data over HTTP
Loading mixed content
Using protocol relative URLS
Using weak version of SSL (TLS 1.0+ is GOOD)
Using weak ciphers
Terminating SSL early in your infrastructure
Trusting the CA system
Using old OS's or old HTTP Servers
Bypassing TLS
• Cryptography is solid but the implementation has flaws
• Browser fail open policy
• Too much trust on certificate authorities
• Revocation capability is limited and doesn’t scaled
• Some of the most popular algorithms need to be decommissioned
Cryptography is bypassed, not attacked
21
Trust Security Decisions
to Browsers Vendors,
Users and other client
Entities
22
BROWSER/OS HTTPS SINS: Feb 2014
Apple goto #fail SSL bug
Major iOS/OSX SSL implementation bug
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1266
"...does not check the signature in a TLS Server Key Exchange
message...."
"...allows man-in-the-middle attackers to spoof SSL servers by
(1) using an arbitrary private key for the signing step or (2)
omitting the signing step."
goto fail Apple SSL bug
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
OSStatus
err;
...
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
...
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}
Browsers let users do the ultimate security decision
It worked
yesterday,
so…
The effects of a “fail open/soft fail” policy
• 30-70% of the users click through warnings*
• Completely defeats the purpose of encryption
• No good way to change browser behavior, until recently
* http://www.cs.berkeley.edu/~devdatta/papers/alice-in-warningland.pdf
26
HTTP Strict Transport Security (HSTS)
•
•
•
•
Released in November 2012
Mitigates
• Soft fail – tolerance to errors
• MitM attack using DNS trickery
• Browser default behavior of trying HTTP first
• Mixed content
Protects the user, not the website
HTTP specific and must own the domain
Strict-Transport-Security: max-age=31536000; includeSubDomains
27
HTTP Strict Transport Security (HSTS)
Tips
• Won’t work with self signed certs
• Won’t work with IP
• Won’t work with plaintext connection
• Will work in all ports
• Deploy with a short duration value first. Increase it later.
To Revoke HSTS
Strict-Transport-Security: max-age=0
28
HTTP Strict Transport Security (HSTS)
Security Considerations
• Include in all subdomains, even when using includeSubDomains
• Lack of includeSubDomains is a privacy violation for users
•
•
•
Activated during the first use
• Browsers can preload HSTS… for now.
Back to first use scenario once retention period expires
• Can be forced to first use scenario by spoofing NTP
Does not necessarily secure cookies
• Redirect to a made-up subdomain may reveal cookies (assuming no https)
• Continue to use secure cookies
29
HTTP Strict Transport Security (HSTS)
Supported Browsers*
Minimum Browser Support
Internet Explorer 12
Firefox 29
Opera 12
Safari 7
Android Browser 4.4 (KitKat)
Chrome
* http://caniuse.com/#feat=stricttransportsecurity
HSTS
30
HSTS – Preload List
If you own a site that you would like to see included in the preloaded
Chromium HSTS list, start sending the HSTS header and then contact:
agl@chromium.org
Current HSTS Chrome preload list
http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport
_security_state_static.json
More info at: http://dev.chromium.org/sts
A site is included in the Firefox preload list if the following hold:
• It is in the Chromium list (with force-https).
• It sends an HSTS header.
• The max-age sent is at least 10886400 (18 weeks).
Too much trust in
Certificate Authorities
32
In God Certificate Authorities We Trust
Cert Auth
Cert Auth
Cert Auth
Cert Auth
33
In God Certificate Authorities We Trust
Cert Auth
Cert Auth
Cert Auth
Cert Auth
Cert Store
34
Certificate Pinning
What is Pinning?
• Pinning is a key continuity scheme
• Detect when an imposter with a fake but CA validated certificate attempts to
act like the real server
2 Types of pinning
• Carry around a copy of the server’s public key;
• Great if you are distributing a dedicated client-server application since you
know the server’s certificate or public key in advance
Note of the server’s public key on first use
• Trust-on-First-Use, TOFU pinning
• Useful when no a priori knowledge exists, such as SSH or a Browser
https://www.owasp.org/index.php/Pinning_Cheat_Sheet
Browser-Based TOFU Pinning
Browser-Based TOFU Pinning
• Trust on First Use
HTTP Public Key Pinning IETF Draft
• http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11
• Freezes the certificate by pushing a fingerprint of (parts of) the certificate chain
to the browser
Example:
Public-Key-Pins: pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
pin-sha1="qvTGHdzF6KLavt4PO0gs2a6pQ00=";
pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
max-age=10000; includeSubDomains
In God Certificate Authorities We Trust
Cert Auth
Cert Store
Cert Auth
Cert Auth
Cert Auth
Can Certificate
authorities be breached?
• Comodo
• VeriSign
• DigiNotar
37
In God We Trust
And Maybe Some Certificate Authorities…
Cert Auth
Cert Auth
Evil
Cert Auth
Cert Auth
Cert Store
38
Pinning - Trust on First Use (TOFU) Example
Cert Auth
Cert Store
39
Pinning – Reduces the attack surface for cert forgery
Cert Auth
Evil
Cert Auth
40
Pinning – Options
What to Pin
• Certificate Pinning
• Intermediate cert
• Root cert
• Public Key Pinning (may cover more certs)
• subjectPublicKeyInfo
• RSAPublicKey
• DSAPublicKey
• Hash of the options above
41
Pinning – Considerations
•
•
•
Always have a backup pin and a spare certificate from a different CA
• Avoids a self inflicted DoS
• Consider setting the pin in days if trust on first use (TOFU, aka key
continuity)
• Certificates should have overlapping validity periods
For Mobile Apps, consider adding the pinning during install instead of TOFU
• Out of band pinning decreases chances of attacker tainting pin
Pinning makes it harder to Pen Test
• May need to use iOS SSL Kill Switch and Android SSL Bypass Tool
• May need to disable it altogether
42
HTTP Public Key Pinning extension (HPKP)
•
•
•
•
•
HTTP Public Key Pinning IETF Draft
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11
Freezes the certificate by pushing a fingerprint
of (parts of) the certificate chain to the browser
Upcoming standard proposed by Google
Similar to HSTS (max-age, includeSubDomains)
Pin-sha256: base64 encoded SPKI.
Include two.
Public-Key-Pins: max-age=12000; pin-sha256="ABC..."; pinsha256="DEF...";includeSubDomains
Deployment tips
• Use Public-Key-Pin-Report-Only instead.
• User directive report-uri="http://site.com/pkp-fail-report”
• Sends JSON using HTTP post with status in case of failure.
Certificate revocation
doesn’t always work
44
Revocation does not work
•
•
•
•
It takes at least 10 days for the revocation Information to fully propagate
Browser soft fail policy makes revocation ineffective
OCSP request can be intercepted (more on this than later)
Most browsers ignore revocation for all certificates but EV certificates
• List includes Chrome, Firefox, Chrome on Android, iOS on Safari…IE and
Opera do the right think checking OCSP and CRL when appropriate
• Revocation checks can be enable in some browsers. In Firefox, set
security.ocsp.required to true
•
Important certificates (e.g., intermediate CAs), rely on a proprietary revocation
channel (CRISets) that feeds off of Cert Revocation Lists (CRL) information
45
Certificate Revocation Lists (CRLs) do not scale
GoDaddy CRL Size
41Mb
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
158Kb
2007
2013
* Does not include data after heartbleed.
46
Online Certificate Status Protocol (OCSP)
An alternative to certificate revocation lists (CRL)
Port 80 to
OCSP: Request
status for
webserver
No
Privacy
Port 80 to
Client: Status
OK. Signed by
OCSP
Responder
OCSP
Responder
Cert Auth
Does the usual… Not
shown here for
simplicity sake.
Web Server
47
Attacks against OCSP
Port 80 to
Client: Status
OK. Signed by
OCSP
Responder
Port 80 to
OCSP: Request
status for
webserver
MitM
OCSP
Responder
Cert Auth
Does the usual…
Not shown here
for simplicity sake.
Web Server
48
Attacks against OCSP
Port 80 to
OCSP: Request
status for
webserver
MitM
OCSP
Responder
Cert Auth
Does the usual…
Not shown here
for simplicity sake.
Web Server
49
OCSP Stapling
Faster, Safer and more Private
OCSP
Responder
Cert Auth
Does the usual…
Not shown here
for simplicity sake.
Web Server
50
TLS and Cipher Suites
51
Problems with OLD SSL ciphers
• If you use older SSL ciphers ....
• ... every time anyone makes a SSL connection to your server, that
message is encrypted with (basically) the same private server key
Perfect forward secrecy: Peers in a conversation instead negotiate
secrets through an ephemeral (temporary) key exchange. With
Perfect Forward Secrecy, recording ciphertext traffic doesn’t help an
attacker even if the private server key is stolen!
From https://whispersystems.org/blog/asynchronous-security/
Perfect Forward Secrecy (PFS)
• Mitigates passive attacks by dynamically negotiating different keys each time
• Capturing private key no longer becomes an issue
• Protect against unforseeable threats to private keys, such as Heartbleed
• Diffie Hellman is the most popular algorithm
Steps
1. Publicly agree on two numbers with specific mathematical
properties…
2. Each side choose a secret number and never send it over the
network
3. A third number is calculated by each side independently.
4. The calculated result is the same number, which was never sent over
the network
SSL/TLS Example Ciphers
Forward Secrecy:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
NOT Forward Secrecy
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
Symmetric
Cipher Suite Explained
Asymmetric
Cipher
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Key Exchange AuthN
Encryption Len
Mode
PRF
TLS_RSA_WITH_AES_128_CBC_SHA
Key Exchange + AuthN
Encryption Len
Mode
MAC
Common Options:
KX
AuthN
Encryption
MAC
PRF
Legend
RSA
RSA
AES
SHA256
SHA256
Popular
ECDHE
ECDSA
RC4
SHA1
SHA384
Phase out
DHE
DSS
3DES
MD5
Protocol*
NIST std.
55
SHA-1and the urgency to move on
•
•
•
90% of websites use SHA-1 to protect themselves from being impersonated
In 2005, cryptographers proved that SHA-1 could be cracked 2,000 times faster than
predicted
As long as browsers need to support SHA-1 for someone, anyone's certificate
can be forged because browsers will not know there is a good cert that uses SHA-2
SHA1 collision cost
Year
Cost (in US$)
Cost within reach for
2012
2,770,000 Governments, large corps
2015
700,000 Medium size institutions
2018
173,000 Organized crimes
2021
Source: Bruce Scheneier’s blog
43,000 University research
56
The Death of SHA-1 according to Google
Chrome
Version
Date
UI changes
Behavior
39
Sept 2014
Certs that expire in Jan 2017 using SHA-1
or mixed content
40
Nov 2014
Certs that expire between 1 Jun 2016 to
31 Dec 2016 using SHA-1 in the chain
41
Q1 2015
Certs that expire on or after 1 January
2017
Source: http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
57
Symmetric
Cipher Suite Explained
Asymmetric
Cipher
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Key Exchange AuthN
Encryption Len
Mode
PRF
TLS_RSA_WITH_AES_128_CBC_SHA
Key Exchange + AuthN
Encryption Len
Mode
MAC
Common Options:
KX
AuthN
Encryption
MAC
PRF
Legend
RSA
RSA
AES
SHA256
SHA256
Popular
ECDHE
ECDSA
RC4
SHA1
SHA384
Phase out
DHE
DSS
3DES
MD5
Protocol*
NIST std.
58
Time to Retire RSA?
•
•
•
•
Doesn't support forward secrecy
Uses server key to encrypt the pre-master key created by the customer
• Weakness: Server key (part of the cert) is typically very long lived
RSA (RC4, and DH) are not listed in Suite B, NSA and NIST approved list
Keys grow significantly larger
NIST Recommended Key Sizes
Protection Target
Symmetric
DH or RSA
ECC
05 years protection against agencies
80
1024
160
20 years protection against agencies
112
2048
224
30 years protection against agencies
128
3072
256
Increased defense from quantum computers
256
15360
512
59
The strange state of RC4
•
•
•
•
Widely supported. The cipher that is guaranteed to “always be there”
• Google allows it for clients that support TLS 1.0 and below
• No trivial way to configure servers like this
Recently recommended by experts to mitigate BEAST in the server side
New attacks against RC4 made the security community change recommendation
• The attack requires a huge amount of network traffic.
RC4 was never a FIPS approved algorithm (e.g. not part of Suite B)
• Microsoft removed it from Windows 8.1
• Russia refused to sign the “.ru” domain with RC4. Instead they used
GOST
• Things that make you go hmmm?
60
A Call To Action
1. Implement
1. HSTS: Make your browser fail close if things are not okay
2. Pinning: because you cannot trust all CAs in the world!
1. Chose your Certificate Authority wisely
3. OCSP Stamping: better privacy, more efficient and safer
4. Forward Secrecy: mitigate passive attacks
2. Plan to move away from RC4 and RSA: listen to the madman…
61
Thank You!
62