On Fri, Nov 20, 2015 at 05:50:51PM -0600, Tom Ritter wrote:
On 18 November 2015 at 16:32, David Fifield david@bamsoftware.com wrote:
There was an unfortunate outage of meek-amazon (not the result of censorship, just operations failure). Between 30 September and 9 October the bridge had an expired HTTPS certificate. [tor-talk] Outage of meek-amazon https://lists.torproject.org/pipermail/tor-talk/2015-October/039231.html https://lists.torproject.org/pipermail/tor-talk/2015-October/039234.html And then, as a side effect of installing a new certificate, the bridge's fingerprint changed, which caused Tor Browser to refuse to connect. It used to be that we didn't include fingerprints for the meek bridges, but now we do, so we didn't anticipate this error and didn't notice it quickly. Update the meek-amazon fingerprint to B9E7141C594AF25699E0079C1F0146F409495296 https://trac.torproject.org/projects/tor/ticket/17473 [tor-talk] Changed fingerprint for meek-amazon bridge (attn support) https://lists.torproject.org/pipermail/tor-talk/2015-November/039397.html Interestingly, the meek-amazon bridge still had about 400 simultaneous users (not as much as normal) during the time when the fingerprint didn't match. I would have expected it to go almost to zero. Maybe it's people using an old version of Tor Browser (from before March 2015) or some non–Tor Browser installation.
It seems like it would be better to use the SPKI rather than the cert fingerprint, this would allow you to reissue the same key and keep things working for older clients.
The fingerprint I'm talking about is the relay fingerprint, not the HTTPS/X.509 one. The HTTPS certificate and the relay identity fingerprint are completely independent. It just happened that in this case, the relay was so configured, that when it rebooted to start using the new HTTPS cert, it also generated a new identity key.
We're not pinning the HTTPS cert and in fact we can't; it's just used for confidentiality on the CDN↔meek-server link.