| It bears repeating because this argument comes up in every PRISM thread... The basics:
HTTPS is TLS/SSL transport level encryption of HTTP traffic (including HTTP headers). The way it works is that client and server go through a handshake process where the server (and optionally client) present a public key and proof of ownership of a private key. The server public key is also normally signed by a certificate authority (e.g. Verisign), this is what is normally meant by a certificate. Threat Models:
There are a number of different threat models that crop up when talking about TLS. I'll talk briefly about each below. 1. Compromised Certificate Authority (CA) If the CA is compromised then the rogue CA can be used to create new certificates that claim to be for the intended target server (e.g. Google or Facebook)[1]. The fake certificate can then be used to launch a Man-in-the-Middle (MITM) attack where the attacker convinces a victim to connect to them, and creates two separate TLS connections VICTIM<-TLS1->MITM<-TLS2->SERVER. The MITM can see the unencrypted messages since the victim is encrypting to the key in the fake certificate.
Chrome's certificate pinning can be used to prevent this type of attack since the browser will check to see if the server has presented the _correct_ certificate for the intended server (by comparing public key fingerprints AFAIK). This attack can also be prevented if the connection is mutually authenticated by either a client certificate or an ephemeral ChannelID as discusses here[2]. 2. Attacker has _correct_ private key for server This threat model assumes the attacker has obtained the server's private key either via coercion / collusion. Certificate pinning doesn't prevent this type of attack. 2a. If the attacker is a passive attacker, meaning that they can only observe and record encrypted messages, then they can decrypt any messages that are sent over a cipher spec that doesn't have perfect forward secrecy (PFS). If the connection is setup using the Ephemeral Diffie-Hellman key exchange then the communication channel should be safe from a passive attacker. If the connection is mutually authenticated and the client certificate has not been compromised by the attacker, then the connection should also be safe from this attacker. 2b. If the attacker acts as a MITM then even PFS cipher specs can be compromised. 3. Attacker can break TLS encrypted channels and extract data without needing the keys All bets are off if this can be done in a general way. There have been several attacks (BEAST, CRIME, Lucky13) that can extract small repeated bits of data (user authentication cookies), but no known attacks that can get at all of the data sent over a TLS encrypted channel. [1] http://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulen... [2] http://tools.ietf.org/html/draft-balfanz-tls-channelid-00 |