I'm aware of simple brute-force attacks on short key IDs [0], which are just the last 32 bits of the fingerprint (e.g. 438CF0E2). With significant effort, one might be able to extend that to 64 bits.

I'd be much more surprised by a full fingerprint match. Wouldn't that imply a SHA-1 collision?

[0] http://www.asheesh.org/note/debian/short-key-ids-are-bad-new...

Yes I was referring to the 64bit long key ID. The full fingerprint is a SHA-1 and not vulnerable.

See https://www.debian-administration.org/users/dkg/weblog/105

The 64-bit has been done: I've seen it. 0000000000000001, I think?

I believe it's Certificate Transparency, a Google project for globally monitoring SSL certificates.

http://www.certificate-transparency.org/

Is there any protection from trolls sending mail to this address? Yes, one can roll back the change, but an automated attack would win.

Perhaps the address should be an unguessable <GUID>@ngrok.org instead? Or do you validate SPF and only accept mail from your ISP?

(Maybe you already have solutions; I just found it interesting to consider abuse of the system.)

Yeah, the way the rules work magnesium is a dead-end. You have to double-oxygen to get to silicon, and then it's smooth sailing. (Note that all implemented reactions are listed if you scroll down)

> For instance try finding out what stocks and weights make up the Russell 2000 index

This actually sounds like a fun little linear algebra problem.

You might be able to do something with the correlations of the index returns and stock returns, but I doubt their would be enough information there to depend on results.

Seems to work for me. I opened the Flash Player preference pane and discovered that it had already updated to 12.0.0.70.

So, I'm not sure about that one. Apparently s_client ignores the error and completes the connection because it's intended to be used for debugging.

> Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure.

https://www.openssl.org/docs/apps/s_client.html

https://www.mail-archive.com/openssl-users@openssl.org/msg71...

The s_client connection continues but should still report a verify error. On Linux:

http://pastebin.com/QWpSrR5p

Yeah, I'm not sure. The linked diagram [1] shows them influencing routing, rather than some timing issue.

[1] https://www.documentcloud.org/documents/785152-166819124-mit...

Bufferbloat on the upstream pipe, if somebody is using your shared connection.

AMA: http://www.reddit.com/r/MMA/comments/13govr/hi_rmma_im_one_o...

You can find plenty of wikidrama at https://en.wikipedia.org/wiki/User_talk:Agent00f and https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment...