There's not much you can do to detect MITM by someone who has subpoenaed the private SSL certificates, is there?

I mean, there's no way to tell apart the certificate from the intermediary from the cert from the endpoint as they're the same.

No, if the private keys are compromised (such as via a subpoena) then a man-in-the-middle attack is trivial.

Worse, if a trusted certificate authority's private key is compromised, then the TLS public-key infrastructure as a whole is broken. An attacker who can also intercept traffic (e.g. by routing traffic through a data centre they control) can execute a MITM attack by issuing their own TLS certificate for any domain.

The only way to detect such an attack would be to notice that one time you connect to a site you see the legitimate key, and another time you see the attacker's key. That's what certificate pinning detects.

At this point it's probably safe to assume that the NSA has compromised at least one certificate authority's private keys via a subpoena and gag order and can therefore do MITM attacks on TLS traffic.

With SSLv3 you can prevent MITM attacks as well as replay attacks where the cert is compromised in the future. The SSL cert is used to verify the identity of the server. Once the handshake is completed a symmetric key is chosen for the session using Diffie-Hellman key exchange (http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...) to compromise the session the NSA would have to subpoena the data from the servers memory (a real possibility) but would be unable to attack any sessions that had been previously recorded. This is called Perfect Forward Secrecy (http://en.wikipedia.org/wiki/Perfect_forward_secrecy). It is supported by OpenSSL using elliptic curve Diffie-Hellman. If this was adopted universally it would make conventional attacks on SSL impossible without compromising the servers memory. However there is still a risk that any government may compel a company to preserve the session keys under a gag order.

If a CA is compromised then we have much larger problems since it is impossible to verify the identity of the participants in the session. Since an attack was used to create valid certificates as part of the attack on Iran's nuclear program it is likely that other attacks exist and are in the hands of the same actors. We can't move to ECC based SSL fast enough.

I've been using the Certificate Patrol add-on for a couple of year and I've noticed that there are periods of time during which Google's certs change very frequently (at least as seen by my browser). The last week or two has been one such period. It seems to be switching between certs from Equifax and GeoTrust multiple times per day.

http://patrol.psyced.org/

I've been thinking about installing the EFF's SSL Observatory - a sort of distributed cert pinning and comparison plugin.

https://www.eff.org/observatory

We could not have a central signing authority (ie. use ssh-style approach). This would still mean that Facebook could hand over their key, but would not leave the whole thing wide open as it is now since the NSA likely has already captured the private keys of major certificate authorities.

This happens way too often... The page is served over http and asks you to install it's addon. The addon is not verified. The addon is downloaded from "http://convergence.io/releases/firefox/convergence-current.x....

What's the point of providing such service if anyone capturing your internet traffic can change it in flight to a "return True" equivalent?

Edit: tried https... come on, they're not even trying: "The certificate is only valid for the following names: whispersystems.org , www.whispersystems.org"

The github project has also been stale for 1-2 years. I'm interested but you've got to maintain a project for it to be a "solution".