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>
