(It's not preloaded HSTS so it would have to be learnt from a previous, unattacked connection.)
I know that the unbypassable errors for some sites upset the more technically minded people, but I think that incidents like this show its value.
The CloudShark trace shows what appears to be Firefox connecting to the GitHub IP address, but the server clearly isn't GitHub from the config. The server appears to be configured to accept the client's ciphersuite preference, but doesn't support DHE nor ECDHE.
The server is also only 9ms from the client - that's clearly not crossing any oceans. I'd also guess that the server is overloaded at the time because the ServerHello (which doesn't take significant processing to generate in this case) takes 900ms to come back.
Sadly, it appears to show the user overriding the certificate error and talking to the server anyway :( Hopefully that was a fresh FF install just to see what would happen (which would explain why HSTS didn't prevent the override).
Lastly, the certificate appears to be self-signed, but the Authority Key Id doesn't match. One assumes, based on "OpenSSL Generated Certificate" that OpenSSL was used, but the person may have had some trouble. I'd guess that they generated a CA certificate first (with the same Subject) and then signed the certificate in question as a leaf. Many of the tutorials that you'll find online are for that sort of setup so perhaps they weren't very familiar with X.509 certificates.
where would one keep up with stuff like that other than keeping up with new rfc's?
SSL/TLS Deployment Best Practices
It seems even github is susceptible to this. That is, for people who type www.github.com into their browser rather than github.com. They both did the redirect wrong, as well as left off HSTS of https://www.github.com.