+ I'll re-iterate the need for non-dynamic/safe JavaScript (e.g. Caja) & a form of 'web asset versioning and integrity'.
-Travis On Fri, Mar 25, 2016 at 1:02 PM, Travis Biehn <[email protected]> wrote: > This particular feature has no bearing on that specific attack. > > In general, it looks like Cloudflare will 'handle cert generation for you' > - if that extends to a relationship with CAs - who will sign those, then > yes regardless. > > The real question here is whether the feature detection is done in a way > that is susceptible to downgrade attack. > > If your threat model involves Cloudflare behaving maliciously - then you > shouldn't use Cloudflare. > > If your threat model involves attacker controlled PKI - as it should - > then you should 'cert-pin the leaf.' > > -Travis > > On Fri, Mar 25, 2016 at 12:47 PM, Rayzer <[email protected]> wrote: > >> Wondering if their cert tech can spoof a cert to look like it belongs to >> a site they DNS when it really belongs to them and you've never really >> visited the site at all. >> >> TLS Certificate Optimization: The Technical Details behind "No Browser >> Left Behind" >> >> Overview >> >> Back in early December we announced our "no browser left behind" >> initiative to the world. Since then, we have served well over 500 billion >> SHA-1 certificates to visitors that otherwise would not have been able to >> communicate securely with our customers’ sites using HTTPS. All the while, >> we’ve continued to present newer SHA-2 certificates to modern browsers >> using the latest in elliptic curve cryptography, demonstrating that one >> does not have to sacrifice security to accommodate all the world’s Internet >> users. (If you weren’t able to acquire a SHA-1 certificate before CAs >> ceased issuing them on 2015/12/31, you can still sign up for a paid plan >> and we will immediately generate one to serve to your legacy visitors.) >> >> Shortly after we announced these new benefits for our paid Universal SSL >> customers, we started hearing from other technology leaders who were >> implementing (or already had implemented) similar functionality. At first >> glance, the logic to identify incoming connections that only support SHA-1 >> seems straightforward, but as we spoke with our friends at Facebook, >> Twitter, and Mozilla, I realized that everyone was taking a slightly >> different approach. Complicating the matter even further was the fact that >> at CloudFlare we not only wanted to optimize between SHA-1 and SHA-2, but >> also between RSA and the newer, but less universally supported ECDSA >> certificates. Solve the "optimal certificate" question incorrectly, and the >> TLS handshake will fail — or get explicitly aborted by browsers that have >> deprecated SHA-1 entirely; solve it correctly, and the client and server >> will establish the most performant, secure connection available between the >> two endpoints. >> >> Certificate Optimization Logic >> >> After several trillion requests, we’re confident that our approach works >> quite well for CloudFlare’s customers and their visitors. If you have taken >> an alternative approach to implementation, or have found any >> exceptions/potential refinements to our logic, please chime in below. We >> remain committed to withdrawing SHA-1 support if, as our CEO said, "a >> vulnerability is discovered [in our certificate optimization logic] which >> allows some form of downgrade attack—where a modern browser can be tricked >> into receiving a certificate signed with an insecure protocol—and the >> vulnerability cannot be patched". >> TLS Handshake >> >> Before your web browser can securely exchange "application data" such as >> HTTP GET or POST requests and responses with a web server, it must first >> establish the cryptographic parameters of the secure session. This >> well-choreographed dance, known as the SSL/TLS handshake, commences as soon >> as you click, type, or get redirected to a URL containing the "https://"; >> scheme. (The process described below also applies to connections from any >> user agent — not just browsers—so substitute "mobile app", "command-line >> utility", or anything else that can communicate via HTTPS.) >> >> >> More: >> https://blog.cloudflare.com/tls-certificate-optimization-technical-details/ >> >> -- >> RR >> "Through counter-intelligence it should be possible to pinpoint potential >> trouble-makers ... And neutralize them, neutralize them, neutralize them" >> >> > > > -- > Twitter <https://twitter.com/tbiehn> | LinkedIn > <http://www.linkedin.com/in/travisbiehn> | GitHub > <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com> | > Google Plus <https://plus.google.com/+TravisBiehn> > -- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus <https://plus.google.com/+TravisBiehn>
