Making Pinterest HTTPS | Hacker News Reader

Making Pinterest HTTPS

engineering.pinterest.com

95 pointscpeterso35 comments

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!

    $ ./cipherscan pinterest.com
    ................
    Target: pinterest.com:443
    
    prio  ciphersuite                  protocols              pfs_keysize
    1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-256,256bits
    2     ECDHE-RSA-AES128-SHA256      TLSv1.2                ECDH,P-256,256bits
    3     ECDHE-RSA-AES128-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
    4     DHE-RSA-AES128-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,1024bits
    5     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                ECDH,P-256,256bits
    6     ECDHE-RSA-AES256-SHA384      TLSv1.2                ECDH,P-256,256bits
    7     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
    8     AES128-GCM-SHA256            TLSv1.2
    9     AES128-SHA256                TLSv1.2
    10    AES128-SHA                   TLSv1,TLSv1.1,TLSv1.2
    11    AES256-GCM-SHA384            TLSv1.2
    12    AES256-SHA256                TLSv1.2
    13    AES256-SHA                   TLSv1,TLSv1.1,TLSv1.2
    14    ECDHE-RSA-RC4-SHA            TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
    15    RC4-SHA                      TLSv1,TLSv1.1,TLSv1.2
    
    Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature
    TLS ticket lifetime hint: 300
    OCSP stapling: not supported
    Server side cipher ordering

The use of RC4 is odd as it's fairly broken[1]. Misconfiguration?

[1] http://blog.cryptographyengineering.com/2013/03/attack-of-we...

Misconfiguration. All RC4 ciphersuites are explicitly forbidden by RFC, and considered a severe vuln by CVE. https://tools.ietf.org/html/rfc7465

75% of alexa's top 1 million have RC4 enabled [1]. It will take a lot of evangelizing to finally get rid of it.

[1] https://securitypitfalls.wordpress.com/2015/03/13/february-2...

…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.

https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-a...

If you're managing a system, do what the RFC said: turn off RC4 on all the servers and clients. You were warned!

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…

That's a very sudden change. A lot of sites started using RC4 recently because it's immune to BEAST and Lucky13.

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.

Which this site does. They put RC4 at the bottom probably because it is faster than 3DES.

So's NULL, but that doesn't mean you should use it.

> safety is top priority

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.

[1] http://blog.erratasec.com/2007/08/sidejacking-with-hamster_0...

> 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.

I'm not saying it's easy, but if "safety is top priority", it shouldn't take this long.

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".

Pinner safety is a top priority for us, and so earlier this year we joined the growing list of websites that are fully HTTPS.

You had one job.

https://i.imgur.com/7RCusOi.png

(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.)

Their blog is a tumblr, tumblr doesn't do https on their subdomains.

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.

Don't you have to use Tumblr's DNS settings to link a custom domain with their service? And to use Cloudflare don't you have to use their DNS servers?

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.

Tumblr blocks requests from Cloudflare

Edit: Sorry should source my claim.

Primary source: It reverted back to my .tumblr.com domain when I tried it

Also https://support.cloudflare.com/hc/en-us/articles/200168566-H...

Or at least, on other peoples' subdomains.

Too bad they didn't include any info on the "unknown Safari issue"

>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.

Sounds like they don't really know much

That's fantastic, but please don't ban tor users!

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.

They can get their referral info back by implementing https themselves.

FTA:

"We used a meta referrer header to support HTTPS tracking to HTTP sites."

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.

You can still move the login pages out of the CDN?

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.

If the CDN is malicious and can MITM, then this won't help — the CDN could rewrite all links and redirects to the login page.

> 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.

Looks like images are served out of pinimg.com, which uses a different cert.

Reply on news.ycombinator.com