Custom Query (196 matches)

This is complicated by the requirement to keep SSLSessionTicketKeyFile out of persistent storage, rotate it frequently, and synchronize it across servers. It would also be nice to remember the last N old keys so that each rotation doesn’t force every user to establish a new SSL session. We’ll probably need to do some Apache development.

​https://www.imperialviolet.org/2013/06/27/botchingpfs.html ​https://blog.twitter.com/2013/forward-secrecy-at-twitter-0

See ​http://b-m.mit.edu/__scripts/icons/ vs. ​http://b-b.mit.edu/__scripts/icons/ (for Apache directory indexes).

davidben points out that ​Chrome will be degrading SHA-1 certificates valid past 2016-01-01:

The following changes to Chromium's handling of SHA-1 are proposed:

• All SHA-1-using certificates that are valid AFTER 2017/1/1 are treated insecure, but without an interstitial. That is, they will receive a degraded UI indicator, but users will NOT be directed to click through an error page.
• Additionally, the mixed content blocker will be taught to treat these as mixed content, which WILL require a user action to interact with.
• All SHA-1-using certificates that are valid AFTER 2016/1/1 are treated as insecure, but without an interstitial. They will receive a degraded UI indicator, but will NOT be treated as mixed content.

This seems to include all certificates that mitcert/InCommon has issued (and continues to issue!) since 2013-01-01, since they have a three year expiration date.

So we’re going to need to replace all these certificates soon. This might also be a good excuse to move to a 2048-bit private key (because a 4096-bit certificate signed by 2048-bit CAs provides no security benefit and is noticeably slower).