Certificates, SSL and ...
Slideshow. Slides are fun. Slides are good.
SSL and TLS for activist privacy
- SSL version 1
- still exists
- SSL version 2 (Netscape 1994)
- Totally sucks.
- SSL version 3.0 (Netscape 1995)
- Drastic change of protocol to fix various security problems and technical shortcomings of SSLv2
- TLS version 1.0 (IETF 1999)
- Basically, SSL version 3.1
- Superficial improvement of SSL 3.0 protocol
Why was SSL created?
Because you can't create a certificate industry without it.
- Netscape hysterical e-commerce dystopian fntasy about hackers mass stealing credit cards with packet sniffers. It wasn't so much the case in 1994. But they managed to sell the certificates.
- You can't sell expensive Netscape Commerce Servers either without inventing SSL. A NCS was a big propriatary package designed to make a become a "presence package".
Although SSL is most often described as a general purpose transparent network security protocol, SSL was primarily designed to secure web traffic.
It's become a ubiquitous security 'black box' that everybody assumes will provide their security needs.
There is a problem as people don't understand at all how it works, so it means people don't know when they are insecure.
SSL comes with it's own set of assumptions...
- Standard Threat Model for Analyzing Cryptographic Network Protocols
- Attacker has complete control of the network:
- Can obtain any message passing through network
- Can pretend to be any server or client
- Can send arbitrary network messages
- Can make intercept and dispose of any message
What's our threat model?
Our threat model looks different
- Seizure of servers by hostile opponents - there is a history of server seizures
- Certificate authority cooperation with opponents - commercial ssl certificates are signed by big companies which assign these "official" root certificates found in everyones browser are under suspicion of co-orporation with others who may be interested in your communications
- Infiltration of tech working groups
- Legal or extra-legal threats to secure cooperation of hosting providers
- Supeonas, Warrants, Grand Juries
- Dolev-Yao attacker, previously mentioned, with state resources!
Isn't that all a little bit ...Paranoid?
The italian postal police became interested in discovering the identity of one of the users of Inventati mail service.
On June 15, 2004 the police with the cooperation of the Aruba web hosting facility were able to make a copy of the hard drive of the Inventati servers. In particular they were interested in recovering the SSL private key.
When the italian kids inquired about the service disruption they were told that there had been some technical problems at the facility.
One year later it came to light that the police had been capturing email traffic of all 6000 inventati email users for the last 12 months.
Wait a minute!! The cops did WHAT??
This came to light in court proceedings, the police bragged and explained about it in court.
The SSL Protocol has four main cryptographic components.
Confidentiality >>>>>>>>>> Bulk Encryption
- (lots of data, so you want to use symmetric encryption)
Integrity >>>>>>>>>> MAC Digest
- (a checksum? that what was sent was recieved)
Endpoint Authentication >>>>>>>>>> Certificates
- (from certificate authorities)
Key Exchange >>>>>>>>>> RSA or Diffie-Hellman
- (the shared secret)
The specific algorithms are negotiated from many different possibilities
Bulk Encryption Algorithms
Symmetric Ciphers, both block and stream are supported.
Keys used are session keys derived from key exchange.
- DES (and triple DES)
- RC4 (stream cipher)
Same keys used for brute speed, you can do big blocks at a time.
A checksum that is also encrypted to help ensure data recieved was that which was sent.
Messages protected from tampering by appending a keyed hash. MACs based on two hash algorithms are supported
- Endpoints authenticate themselves to each other with certificates
- A certificate is a signed binding between a name and a public key
- For example the name www.indymedia.org and a public key are signed together by a certificate authority
- When you create a certificate signing request (CSR) this puts out data that goes to the certificate authority. They give you Public Key to send to users.
- Generally only the server authenticates to the client but the protocol supports client certificate authentication as well
The root certificate from CA on the machine is usually trusted by the user.
Used to derive the keys for the session. Both sides need to use the same keys for encryption.
SSL supports two main key exchange algorithms:
RSA is most often used.
- Used to negotiate a set of cryptographic algorithms between client and server.
Must use defined sets. Cannot mix & match algorithms arbitrarily.
- Client announces ciphersuites that it supports and Server chooses one.
An example of the detail you would see from the communication with a server RSA_WITH_RC4_128_MD5:
- key exchange
- Also authentication algorithm
- bulk encryption
- key size
- MAC Hash
How the inventati had their certificate taken should be learned from. They used RSA based SSL which doesn't use forward security. Diffe-Hellman does have forward security.
What is to be done?
- We should prefer DH key exchange configurations over RSA.
- It is still an open problem to research the support for DH in various browsers and other software.
- DH is not foolproof. It is still vulnerable to active attacks with forged certificates (Man in the Middle).
If we have lots of RSA keys on a server, then when someone gets the private key, there is a problem. But DH is not so well supported by clients.
Can we detect forged certificates?
- Let's build a database with fingerprints of all certificates used across our networks. Before you install a certificate in your client, you should check the fingerprint is the one that is in the database.
- Then we can use that to periodically scan from various places on the internet and make sure that we see the certificates that we expect to see. A regular check will highlight changes on servers we are interested in
- Maybe we can even integrate this Nagios (server checking software) so it happens automatically (occam?
Even encrypted transfer leaks info by the length of the packet, the observation of two possible end points and ...
- You can learn a lot by just watching encrypted traffic.
- Sizes and times of messages can be very useful information.
- In the case of Inventati this is probably all the information the police really needed.
- Using SSL for open publishing should be avoided so that users do not get a false sense of security. (discuss)
Points for Discussion
- We are stuck with SSL if we want users to be able to use services securly
- Best cipher? DH allows more protection from seizures, but less compatible
- Private key secure handling: do we use the keyphrase on the private key? the "iventati crackdown" doesn't work if the private key is password protected?
Refuse commercial CA for the procotol - do we trust the commercial providers?