Thread:User talk:Ryan lane/TLS on Wikipedia/reply (2)

Yes, and yes. Apparently you however haven't: https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fen.wikipedia.org Please pay special attention to handshake simulation. I also ran my own tests, which are, well, a bit more extreme.

If you could point me to where those configuration fles are in the repository, that would be splendid. I've been searching for a while yesterday, without luck. The larger the key size, the better. Expiry of PKI will compromise all past communication, expiry of digest compromise authentication. And SHA-1 is bad juju. --
 * 1) TLS works in wonderful ways. The client sends an ordered list of supported cipher suites to the server, and the server matches it to its own list and negotiates one (it also sends this list to the client, but that's not really important, client renegotiation should be disabled). If you enforce the cipher suite order (that's   in nginx.conf) it iterates through the server specified list looking for a match in the client specified list, if you don't, it works the other way round. The first match is used.
 * 1) Actually, this is rather black and white. And a color you can't see. Security first (the right way), performance first, or completely misguided in either approach.
 * 2) Without forward secrecy (and that currently has its own flaws)? 24 hours, or until the current session ends, whichever is sooner. Now, this is of course not very practical by any stretch of the imagination. I have a solution for this, but it's not easy to implement, so I'm not going to burden you with it. For authentication alone, it should be valid only until it becomes feasible to solve either a for a collision of the digest or factoring the public key and derive the private key.
 * No, I did not. What's the point? What you are doing further requires 1. search engine support and 2. the crawler to revisit the page. The first one only Google does, and the second one, well, takes too long without a nudge. You can use search engine webmaster tools to tell those search engines your site is available elsewhere (even if it isn't) and use HTTP 301 to make it work with the ordinary crawlers.
 * 1) Prioritizing RC4 does not protect against a BEAST type attack, if anything, it makes all non-vulnerable clients vulnerable, because RC4 in TLS is broken just the same.
 * 2) Not always. I have been served three different ones during my tests. Equifax/GeoTrust 1024-bit sha1RSA (expiry: Sunday, ‎August ‎23, ‎2015 12:23:10 AM), RapidSSL/GeoTrust 2048-bit sha1RSA (expiry: ???/can't find it anymore), and DigiCert 2048-bit sha1RSA (expiry: Wednesday, ‎January ‎20, ‎2016 2:00:00 PM)
 * 3) You can add multiple certificates to a server configuration, even for the same domain. The server will automatically pick one to serve a client during the handshake, depending on what it says it supports. You can add ECDSA and RSA keys, the one first in the order listed that is compatible will be used.
 * 4) Sure you can.

Since it requires the use of a compatible client with a working connection before being active, it will ensure all future visits will be secure. It won't block plain text access.
 * 1) I have explained this above. (also, you forgot a new line before that #, that's confusing)
 * 2) Not entirely true. It may allow the server to lie or provide revocation information the client would otherwise not know about.

I also wasn't done yet. Like it said there. I'm saving the terrifying stuff for later. Those were just the basics. The obvious, not so time consuming things.