Looks pretty good. Their configuration could use a larger DHE parameters (2048), replace RC4 with 3DES and enable OCSP Stapling. But it's already in the top 1% for TLS quality!
Really: no. There is nothing "very sudden" about RC4 exhibiting biases indicating it is weaker than it should be: ask any cryptographer. The break that's about to be disclosed in March is simply a new practical twist on a weakness published more than 10 years ago!
A lot of sites got bad advice. (One might wonder about whether all that advice was truly given in good faith. Maybe.) The real fix for BEAST and Lucky13 is, and always was, to use TLSv1.2 with AEADs like AES_GCM, or CHACHA20_POLY1305. So do that.
…how about a new twist on an old partial plaintext recovery attack that can actually steal passwords in the wild, given a cute name and a logo, being demonstrated in 11 days at Black Hat Asia 2015? I think that might help speed things along a bit.
I wonder if this is/was the amazing crypto breakthrough known as BULLRUN, or at least very similar. It seems likely that if academic researchers are now able to extract partial plaintexts from RC4 with nothing more than passive eavesdropping, it's possible that GCHQ/NSA has gone all the way.
It's kind of confusing. BULLRUN/EDGEHILL projects are umbrella cover terms: Secure Communities of Interest regarding general access to NSA/GCHQ (respectively) efforts to defeat network communication technologies such as TLS and IPsec, not particular individual cryptanalytic attacks, vulnerabilities, backdoors or techniques.
I think you want the PICARESQUE ECI compartment, specifically (TS//SI-PIQ). NSA are said to have had a "cryptanalytic breakthrough" which "surprised" GCHQ some years ago. Specific operational details are currently undisclosed, but there have been references to PIQ (PICARESQUE) blades at locations of some TEMPORA full-take feeds processing the (72-hour) network intercept ring buffers in nearline and providing passive decrypts on-site to the backend via crypt attacks. They have only one-way access, and aren't active/QUANTUM (MoTS/MiTM) attacks, or PAWLEYS (key-stealing) attacks. The prevalence of RC4 within TLS (and other protocols) at the time, that it apparently directly provides plaintext decrypts, and RC4's relative weakness, suggest it as the most likely candidate for attack.
So, no, don't use RC4! …not that I've had the opportunity to reverse any of these blades recently, you understand…
yet they didn't go full https till early 2015 - when do we get to start pointing this shit out? Sidejacking attacks have been around for years (Hamster [1] is from 2007), and the millions of other reasons to do it just keep growing. I feel like at some point you can't say "safety is top priority" just for implementing HTTPS sitewide.
It's just a saying; a platitude like "get well soon", "just be yourself", or "employees must wash hands". Safety (really security in general) is top priority only after you've already knocked out user acquisition, basic short term financial stability, and product stability. As such, by "safety is a top priority", they really mean "safety is a top priority now".
> We identified and mitigated many technical challenges in the discovery process of the migration.
Turning on HTTPS is not a one-step migration.
Turning on CSP has also proven to be very difficult for nearly every site who wishes to turn it on.
Where I work I am dealing with production issue with one of the security features, which by enabling it we observed redirection loop. I am not saying this is an excuse but there are challenges.
(MTNL is an ISP in Delhi that I'm currently using to access the net. They are pretty shameless about running MITM attacks on virtually every webpage which is not fully HTTPS, such as engineering.pinterest.com.)
If they use either a proxy or a service like Cloudflare, they can get some of the benefits of SSL/TLS (like preventing MITM attacks at the last-mile such as this one), while still using Tumblr to host their blog.
You don't have to strictly speaking, you can use your own and just resolve in the same manner. You'd just need to monitor the results of a lookup on CF's servers and send back the same response with your own DNS.
>Our UK experiment provided data that showed a small percentage of users had problems logging in after the migration. We pinpointed this to Safari users, which allowed us to start investigating the root cause.
Will this mean that website will lose the referral info from inbound links to their website from Pinterest? If so, that will really aggravate a lot of people.
It's security theater to encrypt everything. If you have to let some content delivery network decrypt your HTTPS sessions, you've created a central wiretapping point at the CDN. If you only encrypt login pages and such, and have a server with higher security handling them, you're at least protecting passwords and user identification. If decryption has to be moved out into the CDN to support encryption of cat pictures, security has been reduced.
> If decryption has to be moved out into the CDN to support encryption of cat pictures, security has been reduced.
That doesn't logically follow. The CDN doesn't have to start handling logins just because the "cat pictures" are now being served over HTTPS.
> If you only encrypt login pages and such, and have a server with higher security handling them, you're at least protecting passwords and user identification
It's impossible to provide meaningful security this way - if the pages linking to the login page aren't HTTPS, it's trivial to sslstrip them. Only a very small fraction of users will notice when this happens.
You can do that. You need a separate login domain, with its own server and SSL cert. The cat videos can go through the main domain and CDN.
HTTPS security seems to be going downhill where it matters. "wellsfargo.com" not only has just a cheezy "domain validated only" SSL cert, but their "sign up for online access" link redirects to "https://adfarm.mediaplex.com". Bank of America used to run the secure pages through "secure.bankofamerica.com" from their own servers. Now everything comes from one domain, and it's front-ended by an Akamai service.
Is it really new? People have always outsourced hosting. Complaining that CloudFlare or Akamai have access to an SSL cert makes as much sense to me as complaining that RackSpace has access to it, when someone was hosting their stuff in their datacenters.
