OSDC 2012 | CA failures and the future of Web authentication by Dr. Christopher Kunz

Christopher Kunz | Filoo GmbH | 07.06.2010
CA failures and the future of Web AuthN
Dr. Christopher Kunz

About me and my company
Dr. Christopher Kunz
• PhD in Security in distributed systems
• Author, „PHP-Sicherheit“
filoo GmbH
• Hosting and Cloud services
• High-security data center in Frankfurt
• Oh, and we sell certificates 
• http://www.filoo.de/
Filoo GmbH | we make your net work | OSDC 2012

What‘s in store here
We will talk about CAs...
• And how you trust the Chinese government
• Why they are a point of failure for the Web
• If we can still trust them
We will talk about alternatives...
• To make CA failure less catastrophic
• To end the unhealthy reliance on CAs
• To combine secure protocols & increase security

What is an SSL certificate?
„SSL certificates“ don‘t really exist
• SSL is a network protocol
• The certificates are actually X.509 PKI certificates
A certificate ties a keypair to an identity
• Keypair is used for the SSL handshake
Certificate = Sign(Pubkey + identity + meta info)
• After signing, it cannot be modified

Important certificate lingo
Certificates have a lifespan
• Typically 1-2 years
Certificates can be revoked by the CA
• If the owner information becomes incorrect
• If the private key was lost
Two revocation methods
• CRL – List of revoked Cert IDs, periodically fetched
• OSCP – Near real-time status updates
• Part of the certificate, mnt-by CA

Proof of identity
The identity is the tricky bit
• It has to be verified before signature
• Otherwise, the signer is not trustworthy
• The signer must verify & assert the identity
information
• The key owner must supply background info
The signer acts as a Trusted Third Party
• Comparable to a notary in real life
• That is what CAs do.

Hey, let me verify that for you!
What CAs do:
Assert binding between keypair
and identity
The only reason for a CA‘s existence is trust.

How certificates are validated
Certificate market is splitting up
Low-cost, low-assertion certificates
• Typically validated by whois + confirmation e-
mail („DV Certificates“)
• Can be forged by a resourceful adversary
High-cost, high-assertion certificates
• Validated by company registration documents
• „Extended Validation“ Certificates

Commercial certificate market
Certificate issuance is lucrative
• Cost between 10 (DV) and 800 € (EV) / year
• Recurring revenue for the CA
• Relatively little effort
There are numerous CAs:
• Thawte
• Verisign / Symantec
• Comodo
• Governments, universities, corporations

Why do you trust?
Nobody explicitly trusts a CA!
• You trust your browser vendor
• „Look for the lock“ – the lock has to be reliable
Browser truststores maintained by vendors
• CA / Browser Forum, http://www.cabforum.org/
• Members include CAs, Apple, Google, MS, KDE,
Mozilla, Opera, RIM
To be included, your CA must meet specific rules

CA vetting process
Trusted CAs operate by either of these:
• WebTrust program for CAs
• ETSI 102042
• ETSI 101456
Compliance must be audited
• Expensive
• Time-consuming
• Not always a business case

All the effort just to avoid this:

Bah. Audits. No, thanks
Let‘s say we don‘t want a WebTrust audit
• It‘s expensive
• It expires (= recurring revenue for the auditor!)
• We are not sure we are in compliance
We need to issue valid & trusted certificates
• For our customer web servers
• For internal machines without FQDNs
• For spying on our employees

Sub-CA delegation
The solution: Buy yourself a Sub-CA certificate
• A CA-signed certificate that can issue certificates
• In the PKi tree, you are now a node, not a leaf
• You can issue valid certificates for all domains
• No technical limitations, just contractual ones
• This causes issues

Map of CAs and Sub-CAs
Over 600 distinct players
• This is only about 1/4th of
the map...
• And the data is from 2010
All nodes are trusted by your
browser!

CA Map: German Sub-CA spidernet

The SSL Observatory
Ran by the EFF
• Crawled the entire IPv4 space, port 443/TCP
• Saved all the certificates
• Voilá, a database of the SSL market
Observatory database is free
• You can build exciting things with it
• And find wackiness
• The colour map was built by EFF

Who do you trust?
CA map shows 600 organizations
• Many are Sub-CAs
• Still, there is a lot of real CAs
160 CAs in current Firefox trust
store
• Settings  Advanced  Show
certificates  Certificate
Authorities
• „Builtin Object Token“

All CAs are equal
Every CA on the map is
treated equally!

Who do you trust?
Directly, you trust...
• The CNNIC
• Dhimyotis
• Hongkong Post Office
Indirectly, you trust...
• Ford Motors
• Walt Disney
• Adidas
...with your SSL traffic.

Why so serious?
The more Sub-CAs, the more possiblities for MITM

MITM how-to
Certificates cannot be forged or manipulated
• Unless you‘ve broken RSA2048...
• And/or know that P=NP or P!=NP
If an attacker wants to secretly sniff SSL traffic
1.They have to control the network
2.They have to control the encryption keys
With these two, they can launch MITM attacks

The special roles of governments
Governments...
• Want to know what their citizens read and write
• Want to listen in on encrypted communication
On the other hand, they might have...
• Full control over Internet routes
• A government-controlled CA
• Ability to compel CAs and ISPs under their
jurisdiction

Avenues of attack
To start issuing Man-in-the-Middle certificates...
• You can become a CA and pass WebTrust/ETSI
audits
• You can compel a CA to issue a certificate
• You can buy a Sub-CA certificate from a trusted
CA
• You can just crack a CA and issue away

CA breach timeline
Numerous CA breaches last year
• About 600 certificates issued maliciously
• One CA deceased within weeks
March, 2011:
Comodo
July, 2011:
DigiNotar
Feb, 2012:
TrustWave
Feb, 2012:
Symantec
breach

Incident 1: ComodoGate
March 23, 2011: Comodo announces 9 rogue
certificates were issued
•{www,mail}.google.com
•login.{live,yahoo,skype}.com
•addons.mozilla.org
•"Global Trustee“
Attacker gained entry via a subsidiary in Italy
•Found unsecured API call for CSR signing
•Able to automatically sign certs
•Claims to be from Iran

Aftermath of ComodoGate
Much ado...
• Discussion about Comodo removal from
truststore
• Discussion about CA security as a whole
• Discussion about upcoming Iran cyberwar
...about nothing
• Comodo was not removed from browsers
• No review of compliance regulations
• No additional cyberwar

Incident 2: DigiNotar

DigiNotar breach
July 19, 2011: DigiNotar notice a security breach
They revoke some malicious certificates
They neglect to revoke some more
They forget to notify the public
They forget to notify the Dutch government

DigiNotar breach – user perspective
In August, 2011, Iranian users see certificate
warnings for Google mail
They make the issue public
DigiNotar is forced to admit intrusion
Attack source was (again) in Iran
This time, lives were actually in danger

Certificates issued during the breach
• *.google.com – revoked during the first analysis
• Several Extended Validation certificates
• Certificates for more Google services
• TOR project
• WordPress
• Mozilla Add-Ons
Over 530 fraudulent certificates
issued!

So much fail...
DigiNotar had been hacked before...
• ...and didn‘t notice or care
They didn‘t have logs for certificate signing
• Or they were cleared by the attacker
Most of their certificates had neither OSCP nor CRL
information
• How to revoke, then?

Consequences of DigiNotar breach
DigiNotar co-ran the Dutch state PKIoverheid
• This PKI was also affected
• Dutch government took over operations at
DigiNotar
Emergency browser updates removed DigiNotar
• Within weeks, DigiNotar goes dark
• No consequences for mother corporation VASCO
Other CAs are questioned and asked to re-audit

Side note: Mozilla add-ons
addons.mozilla.org was affected by both attacks
Why is that?
• Addons not from that domain cause warnings
• Attacker might want to install malware/spyware
• Attacker might also want to block privacy addons
Mitigation?
• Use own CA and hardcode it in your app
• Works well in a walled garden

Third incident: The perils of Sub-CAs
Trustwave sells Sub-CA certificates to companies
• One of these MITMed their own employees
• „Data Leakage Prevention“ a.k.a. „we read your
mail“
• Widespread criticism, initiative to remove
TrustWave from browser root
• TrustWave revokes Sub-CA certificate in
question, claims no abuse was possible
• CAB people issue „a stern warning“ to the CA
community
• Effectively no consequences

Between a rock and a hard place
Some CAs are incompetent
Some CAs are greedy
Some CAs might be malicious

Why are we trusting these guys?
Because nobody has a better idea.

We cannot stop using encrypted communication
We cannot switch to using only self-signed certs
• Lack of trust root makes them MITM-susceptible
• No identity verification whatsoever
We need to fix the CA system
Or find a viable alternative

HSTS / Pubkey pinning
HTTP Strict Transport Security
• Browser-supplied list of HTTPS-only URLs
• Prevents SSL-stripping MITM attacks
Public Key Pinning
• Expect a specific CA public key in SSL handshake
• Does not scale well into millions of sites
Both approaches aim to fix Google‘s problems
• Are they universally usable?

DANE
DNS-based Authentication of Named Entities
• IETF working group
Tie certificate public keys to DNS entries
• example.com IN CAA MIIFEzCCBHygA....
Only useful in connection with DNSSEC
• Attacker could spoof plain DNS CAA replies
More reliance on decent DNS administration
• When will we see DNSSEC coverage?

Convergence
Thesis: „The CA system is broken. Let‘s not fix it.“
Approach: Check each self-signed certificate from
multiple angles
Goal: Make MITM for self-signed certificates
impossible
Currently a beta Firefox plug-in

The Convergence principle

Convergence features
Notary servers in multiple jurisdictions
• You can rely on it even while in China or the T-
Mobile wi-fi network
Encrypted requests to the notaries
• Man in the Middle cannot build a surf history
•
Randomly forward requests to 1-out-of-n notaries
• Privacy towards the notary – they can‘t build a
surf history

Convergence Notaries
Default behavior:
1. Open an SSL connection to the site in question
2. Obtain the certificate hash (fingerprint)
3. Return the hash to the client
Hash differences  MITM; abort connection!
Notary servers are OSS; you can use them to...
• check the SSL Observatory
• work in RFC 1918 address space
• check RIPE / DNSSEC / any other source

Convergence attack scenarios
Antagonists could perform DoS on notaries
• Mitigated by crowdsourcing a large number
They could reroute/block requests
• No security loss for client, SSL handshake fails
They could run several corrupted notaries
• Community would quickly single those out

Convergence issues
Increased SSL handshake overhead
• No support for client certificates
Border cases for open wi-fi with „captive portals“
• Often perform SSL stripping MITM to reroute
HTTP traffic
No verifiable identity information
False positives for load-balanced sites
• Some sites have different certificates on their
nodes

Sovereign Keys
Keep track of the full history for a DN
• All keypairs associated with it
• Append-only data structure
• Additions only with a special key
Route around certificate failures
• Each sovereign key hash is a .onion address
• If you can`t connect via SSL, connect via TOR

Sovereign Keys caveats
If you lose the Sovereign key, your DN is lost
• You can never renew or reissue a certificate
• You cannot retrieve the key
• You cannot purge the DN from the history
Attacks are difficult
• Attacker cannot issue a Sovereign-protected
certificate
• They need the Sovereign Key
• They cannot initiate a DoS

Further reading
EFF and SSL Observatory:
• https://www.eff.org/observatory/
• https://www.eff.org/files/colour_map_of_CAs.pdf
ComodoGate:
• http://pastebin.com/74KXCaEZ
• http://www.f-
secure.com/weblog/archives/00002128.html
DigiNotar hack:
• http://blog.gerv.net/2011/09/diginotar-
compromise/

Further further reading
Convergence
• http://convergence.io/
Sovereign Keys
• https://www.eff.org/sovereign-keys
CA/Browser Forum
• http://www.cabforum.org/
WebTrust
• http://www.webtrust.org/homepage-
documents/item27839.aspx

Summary
CAs can and do fail, they will fail again
• ComodoGate, DigiNotar et al.
We currently don‘t have a universal replacement
Some ideas can fix the worst issues
• Convergence
• Sovereign Keys
Some projects need to be developed more
• DANE
• Key Pinning / HSTS

Thank you
I‘m looking forward to your questions
and comments!
Contact me:
<chris@filoo.de>

OSDC 2012 | CA failures and the future of Web authentication by Dr. Christopher Kunz

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie OSDC 2012 | CA failures and the future of Web authentication by Dr. Christopher Kunz

Ähnlich wie OSDC 2012 | CA failures and the future of Web authentication by Dr. Christopher Kunz (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

OSDC 2012 | CA failures and the future of Web authentication by Dr. Christopher Kunz