ssl: limitations, bad practices and how to do it right

SSL: limitations, bad practices and how to do it right

Versão 2.0 - 02/07/2011

Tiago Mendo [email protected]

mailto:[email protected]


SAPO Websecurity Team

Summary

2

• History

– SSL

– TLS

– SSL vs TLS

• Protocol

– Objec9ves

– Applica9ons

• How it works -‐ the 2 minutes version

• How it works -‐ the 30 minutes version

– Cer9ficate valida9on

– Cer9ficate revoca9on check

– Cer9ficate chain of trust check

– Fetching content

– Redirec9ng from HTTP to HTTPS

– Full HTTPS browsing

– Mixed content browsing

• Recommenda9ons

• Conclusions

• Ques9ons


History > SSL

3

• SSL -‐ Secure Sockets Layer

• 1994 -‐ SSL 1.0 created by Netscape, never released

• 1995 -‐ SSL 2.0 released in Netscape Navigator 1.1. Mul9ple security flaws found

• 1996 -‐ SSL 3.0 released


History > TLS

4

• TLS -‐ Transport Layer Security

• 1999 -‐ TLS 1.0 defined in RFC 2246, using SSL 3.0 as basis

• 2006 -‐ TLS 1.1 defined in RFC 4346• 2008 -‐ TLS 1.2 defined in RFC 5246


History > SSL vs TLS

5

• SSL 3.0 and TLS 1.0 are equivalent in security, but incompa9ble• “Everybody knows SSL. TLS is more technically accurate but sounds like a cable TV network or a disease"

SSL TLS

1.0

2.0

3.0

(3.1) 1.0

(3.2) 1.1

(3.3) 1.2


Protocol > Objectives

6

• Why SSL?



6

• Why SSL?

• To protect the communica9ons between two hosts:– content confiden9ality– integrity– authen9city



6

• Why SSL?

• To protect the communica9ons between two hosts:– content confiden9ality– integrity– authen9city

• Host iden9ty is not protected (requires IPSEC)• Normally only the server is authen9cated


Protocol > Applications

7

Applica+on

Transport

Network

Data link

Physical

HTTP

TCP

IP

802.11 -‐ WLAN

Air



7

Applica+on

Transport

Network

Data link

Physical

HTTP

TCP

IP

802.11 -‐ WLAN

Air

HTTP / SSL

TCP

IP

802.11 -‐ WLAN

Air



7

Applica+on

Transport

Network

Data link

Physical

HTTP

TCP

IP

802.11 -‐ WLAN

Air

HTTP / SSL

TCP

IP

802.11 -‐ WLAN

Air

HTTP

SSL

TCP

IP

802.11 -‐ WLAN

Air



7

• On top of any Transport layer (including UDP)• Used with any Applica9on layer protocol• HTTP, SMTP, XMPP, SIP, etc.• Used in OpenVPN

Applica+on

Transport

Network

Data link

Physical

HTTP

TCP

IP

802.11 -‐ WLAN

Air

HTTP / SSL

TCP

IP

802.11 -‐ WLAN

Air

HTTP

SSL

TCP

IP

802.11 -‐ WLAN

Air


How it works - the 2 minutes version

8

• Type hdps://www.facebook.com and hit enter

https://www.paypal.com



How it works > Traffic without SSL

9


How it works > Traffic with SSL

10


How it works - the 30 minutes version

11

• Type hdps://www.facebook.com and hit enter

• Browser connects to www.facebook.com:443• SSL handshake is ini9ated• Server sends its X.509 cer9ficate to the client• The client starts the valida9on process



http://www.facebook.com



How it works > Certificate validation

12

• CN matches URL• For each cert. in the chain– Has not expired–Was not revoked–Was emided by a trusted CA



13




14




15



How it works > Certificate revocation check

16

• CRL -‐ Cer9ficate Revoca9on List

• The CRL is a list of revoked serial numbers• The cer9ficate specifies a CRL URL• CRL managed by the issuing CA• Answer can be cached for a few months

• The CRL can be very large: enter OCSP– expired certs. are removed from the CRL



17

• OCSP -‐ Online Cer9ficate Status Protocol

• The cer9ficate specifies a OCSP server• Browser asks the server if a specific cert. is s9ll valid

• OSCP server managed by the issuing CA• Answer can be cached for a few days

• A cert. can specify both the CRL and OCSP



18

• What can go wrong?



18

• CRL and OCSP servers can be unreachable– Browsers will allow user to con9nue– You may or may not be warned about this

–Moxie Marlinspike found that OCSP “try again” message (error code 3) is not signed

– Adack: MiTM with a revoked cert. and reply 3 to the OCSP requests.




19

• How to mi9gate this problem?



19

• OCSP Stapling -‐ Kerberos style 9cket– Cert. owner frequently asks the OCSP for a 9cket– Ticket says “I, CA guarantee with my signature that this cer9ficate is valid for a few hours”

– Site presents this 9cket to reques9ng browser

• Fallback to OCSP• Support: Chrome on Windows Vista or higher




20




20

• CRL and OCSP cache• How to mi9gate this problem?



20

• CRL and OCSP cache• How to mi9gate this problem?

• Which introduces another problem– If a cert. is compromised, there may a significant window of vulnerability (months for a CRL)

– Remember the Comodo RA compromise?– 9 certs. were issued to 7 domains– certs. were revoked in 15 minutes– Browser vendors immediately issued browser updates



21




21

• Browsers have vulnerabili9es– OS X v10.6.8 June 2011 update changelog– “An error handling issue existed in the Cer?ficate Trust Policy. If an Extended Valida?on (EV) cer?ficate has no OCSP URL, and CRL checking is enabled, the CRL will not be checked and a revoked cer?ficate may be accepted as valid. This issue is mi?gated as most EV cer?ficates specify an OCSP URL.”

– Update, update, update.




22

• CN matches URL• For each cert. in the chain– Has not expired–Was not revoked–Was emi?ed by a trusted CA


How it works > Certificate chain of trust check

23

• The server sends the whole cer9ficate chain

• For each cert. in the chain verify– is properly signed by the CA cer9ficate immediately higher in the hierarchy

– last cer9ficate is explicitly trusted by the browser, so no signature verifica9on is done



24




25



26



27

• The browser does not know the root CA– can happen if you are using an old browser/device




27

• The browser does not know the root CA– can happen if you are using an old browser/device


• How to mi9gate this problem? • Mul9-‐roo9ng CAs– Server sends a longer chain with more CA cer9ficates higher in the hierarchy

– Both CAs trusted by Firefox



28




28

• The server did not sent the whole chain– sending the domain cer9ficate is not enough




28

• The server did not sent the whole chain– sending the domain cer9ficate is not enough


• How to mi9gate this problem? • Send the whole chain– Using Apache:

SSLEngine on

SSLCertificateFile <path_to_your_cert>

SSLCertificateKeyFile <path_to_your_private_key>

SSLCACertificateFile <path_to_the_CA_chain>



29




29

• The cer9ficate is self signed– you are being cheap




29

• The cer9ficate is self signed– you are being cheap


• How to mi9gate this problem? • Get a cer9ficate signed by a trusted CA!– StartSSL: free– GoDaddy: €36.99/year



30




30

• The cer9ficate is self signed




30

• The cer9ficate is self signed


• How to mi9gate this problem? • DNSSEC– CERT / TLSCERT / TXT RR holds cert. (or its hash)– trust the DNSSEC chain, trust the cer9ficate– DNS clients need to be DNSSEC aware

– stapling: DNSSEC chain in a cer9ficate extension



31




31

• You do not trust what your browser trusts– Firefox ships with 162 CAs• Chunghwa Telecom Co., Ltd• Türkiye Bilimsel ve Teknolojik AraşSrma Kurumu -‐ TÜBİTAK

– Are all of them secure and properly managed?




31

• You do not trust what your browser trusts– Firefox ships with 162 CAs• Chunghwa Telecom Co., Ltd• Türkiye Bilimsel ve Teknolojik AraşSrma Kurumu -‐ TÜBİTAK

– Are all of them secure and properly managed?


– “I have not been able to find the current owner of this root. Both RSA and VeriSign have stated in email that they do not own this root.” said one of the maintainers of Mozilla CA list (early 2010)



32

• You do not trust what your browser trusts– Recent request to add a CA to Firefox• “This is a request to add the CA root cer?ficate for Honest Achmed's Used Cars and Cer?ficates.”• “Achmed's uncles all vouch for the fact that he's honest.”• “The purpose of this cer?ficate is to allow Honest Achmed to sell bucketloads of other cer?ficates and make a lot of money.”

– It was not granted. This 9me.




33




33

• You do not trust what your browser trusts– PKI is adacked from all sides• VeriSign issued 2 “MicrosoZ Corpora+on” cer+ficates to an unknown person (January 2001)• MD5 collision: rogue CA created (December 2008)• COMODO: 9 cer+ficates issued (March 2011)• StartSSL: cer+ficate issuance suspended (June 2011)




34

• How to mi9gate this problem? • Remove trust or delete CAs– they might come back aper sopware updates– how do you evaluate if a CA can be trusted?• by country? name? company?• by security audit? Reports are available, but they all say the same: “approved”.

– can you do this in your smartphone?


How it works > Fetching content

35

• At this point the browser trusts the site cer9ficate

• No HTTP request was made yet!

• First HTTP request is made only now

GET / HTTP/1.1Host: www.facebook.com




How it works > Fetching content

36


How it works > Redirecting from HTTP to HTTPS

37

• Lets go back a lidle• Imagine you type hdp://www.facebook.com instead of hdps...

• Hit enter!





37

• Lets go back a lidle• Imagine you type hdp://www.facebook.com instead of hdps...

• Hit enter!

• Browser connects to www.facebook.com:80







38



39



40



41




41

• Moxie Marlinspike and his sslstrip tool




42

• sslstrip func9oning–MiTM tool– maps HTTPS links to HTTP– maps redirects to HTTPS back to HTTP– maps HTTPS links to homograph-‐similar HTTPS links

– can supply a lock favicon– logging!



43

• sslstrip func9oning



44



45

• You type hdp://www.facebook.com and get redirected to hdps://www.facebook.com

GET / HTTP/1.1

Host: www.facebook.com

HTTP/1.1 302 Found

Location: https://www.facebook.com/

• These requests are not protected with SSL!





https://www.facebook.com




46




46

• Make site available only in HTTPS– Does not work: most users type HTTP and redirects are dangerous




46

• Make site available only in HTTPS– Does not work: most users type HTTP and redirects are dangerous


• Use HSTS: HTTP Strict Transport Security– Formerly STS– Server defined policy that browsers must honor– Server sends HTTP header with policy



47

Strict-Transport-Security: max-age=15768000;includeSubdomains

• This header says two things:– “Browser, convert all requests to my domain to HTTPS”

– “Browser, if there is any security issue with the connec9on do not allow progress”

• Consequences:– the user types hdp://www.facebook.com and the browser requests hdps://www.facebook.com

– any HTTP link in the response turns to HTTPS







48

• S9ll, there is a problem:



48

• We have never visited the site or policy expired– browser does not know the site HSTS policy– if the user types hdp://www.facebook.com the request is done using HTTP

– TOFU: Trust On First Use• Recommenda9ons– first visit using a safe wired network– manually instruct the browser to use HSTS

• S9ll, there is a problem:





49

• Server support: all, just send the header• Browser support– Chrome 4.0.211.0 (with preloaded domain list)– Firefox 4

• Plugins– Safari SSL Everywhere– Firefox EFF HTTPS Everywhere– Firefox ForceTLS (simple list edi9ng)



50



51


How it works > Full HTTPS browsing

52

• At this point we have all the contents of the site served over HTTPS.

• How can we be sure?

• No9ce the green hdps text


How it works > Mixed content browsing

53

• How about this situa9on?

• No9ce the red strikethrough hdps text



54

• Chrome console output:



55

• What is the problem?



55

• Sensi9ve informa9on can be captured– images: your last night weird photos– javascript: can be replaced with malicious code– cookies: sent in every request!– full browsing informa9on

• Browser warnings– can affect site reputa9on– most users ignore this

• What is the problem?



56



57




57

• HSTS– you have to specify all domains used by the site– some links might not work over HTTPS– not a solu9on for all sites




57

• HSTS– you have to specify all domains used by the site– some links might not work over HTTPS– not a solu9on for all sites


• Use only HTTPS links :)– use a proxy: make your server fetch the HTTP content and serve it over HTTPS

– do not forget the favicon



58

• How to minimize this problem?



58

• Secure Cookies– the server can set the secure flag for the cookie– a secure cookie is only sent over HTTPS– beware: this does not prevent the mixed content warning, it ONLY prevents cookies from being sent over HTTP

• How to minimize this problem?


How it works > Data in transit vs at rest

59

• Using SSL we protected the data in transit• What happens aper it reaches the browser?



59

• It gets cached.• What is the problem?– sensi9ve data is stored in clear– computers are shared, sold, lost or stolen




59

• It gets cached.• What is the problem?– sensi9ve data is stored in clear– computers are shared, sold, lost or stolen


• How to mi9gate this problem? Cache-Control: no-cache, no store

Pragma: no-cache


Recommendations

60

• A few more recommenda9ons


Recommendations

60

• Make a bookmark with the HTTPS link for the site (specially homebanking sites)– avoids requests using HTTP– avoids adacks caused by typos

• Use a plugin that warns you if the cer9ficate has changed– Perspec9ves (www.networknotary.org)– Cer9ficate Patrol

• A few more recommenda9ons

http://www.networknotary.org

http://www.networknotary.org


Conclusions

61

• Conclusions– SSL 3.0 and TLS 1.0+ are the way to go– Use HSTS and manually add your important sites– Update your browser open or automa9cally– Do not visit sites which the first page is HTTP using public wireless networks

– Do not allow HTTP access to sensi9ve pages– Do not create sites with mixed HTTP(S) content– If your site is HTTPS only, use secure cookies


Questions

62

Any ques9ons?

[email protected]



ssl: limitations, bad practices and how to do it right

Technology