Certificate Patrol (https://addons.mozilla.org/en-US/firefox/addon/6415) watches for changes in SSL certificates and alerts you to those changes, so you can decide if someone is pulling an SSL MITM attack on you. If the Chinese routers are running SSL interceptors (e.g., Cisco's IronPort or Bluecoat's ProxySG), then you will see alerts that the SSL certs you last got from within the US are different in China.

SSH's -D option activates the built-in SOCKS proxy in the SSH client, so all you have to do is:

ssh -D 8080 -N trustedhost

then configure your browser to use a SOCKS5 proxy on localhost:8080 (and also to use the proxy for DNS lookups, otherwise you leak the DNS names of the sites you browse to).

See "How to Break Out from Inside a Draconian Firewall": http://technotes-fran.blogspot.com/2009/11/how-to-break-out-from-inside-draconian.html

Knowing the site doesn't help if a MITM is watching all the sensitive traffic flowing in both directions. And will your users really know the cert? Do your users have cert hashes memorized, or are they using the excellent "Certificate Patrol" Firefox add-on (https://addons.mozilla.org/en-US/firefox/addon/6415) that alerts users to changes in certs over time?

It depends on what "invalid" means. A lot of people consider an SSL/TLS cert to be valid if the signature chain contains only trusted CAs. If joeblow.com uses a self-signed cert (and joeblow.com is not itself a trusted CA), that cert is useless for validating the identity of the server. Yes, you get encryption, but that's only half of what SSL/TLS is for.

The world's shortest explaination of Godel's Incompleteness Theorem by Raymond Smullyan.

We have some sort of machine that prints out statements in some sort of language. It need not be a statement-printing machine exactly; it could be some sort of technique for taking statements and deciding if they are true. But lets think of it as a machine that prints out statements. In particular, some of the statements that the machine might (or might not) print look like these:

P*x (which means that the machine will print x)
NP*x (which means that the machine will never print x)
PR*x (which means that the machine will print xx)
NPR*x (which means that the machine will never print xx)

For example, NPR*FOO means that the machine will never print FOOFOO. NP*FOOFOO means the same thing. So far, so good.

Now, lets consider the statement NPR*NPR*. This statement asserts that the machine will never print NPR*NPR*.

Either the machine prints NPR*NPR*, or it never prints NPR*NPR*. If the machine prints NPR*NPR*, it has printed a false statement. But if the machine never prints NPR*NPR*, then NPR*NPR* is a true statement that the machine never prints.

So either the machine sometimes prints false statements, or there are true statements that it never prints. So any machine that prints only true statements must fail to print some true statements. Or conversely, any machine that prints every possible true statement must print some false statements too.

Oh, wait. That was the Flux Capacitor not the Oscillation Overthruster. I always get those two confused.

That works for you and me, but this was a system invented to create secure Web browsing for everyone (including non-technical people). It can be argued that it doesn't do that.

Matt Blaze blogged recently about the sad state of SSL/TLS certs at http://www.crypto.com/blog/spycerts/. He writes:

For instance, Firefox 3.6 comes with a CA cert built-in from TÜRKTRUST Elektronik Sertifika Hizmet Salaycs, whoever they are. It's self-signed and doesn't expire until 2015. There are well over 100 CA certs in Firefox 3.6. We basically have to trust every one of those organizations not to snoop our SSL traffic. There has to be a better way.

Such a script would do something equivalent to these manually entered commands:

$ echo | openssl s_client -connect mail.google.com:443 |
sed -ne '/^-----BEGIN CERTIFICATE-----$/,/^-----END CERTIFICATE-----$/p' > gmailcert.txt
$ diff gmailcert.txt knowngood-gmailcert.txt

Of course, file knowngood-gmailcert.txt should be under your physical control at all times (i.e, on CD/DVD or mounted read-only via TrueCrypt). If the certs fail to match, it's either because your SSL traffic is being intercepted by a MITM attack or the old cert expired and a new one was issued (this will happen periodically). If it's the latter, you can fetch the updated cert via a trusted channel (i.e., not from work) and repeat.

The certs obtained this way will be base64-encoded. To dump one in human-readable form, do this:

$ openssl x509 -text -noout < cert.txt