+ 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 <[1]tbiehn@gmail.com>
   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 <[2]Rayzer@riseup.net> 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:
   [3]https://blog.cloudflare.com/tls-certificate-optimization-technical-d
   etails/
--
RR
"Through counter-intelligence it should be possible to pinpoint potential troubl
e-makers ... And neutralize them, neutralize them, neutralize them"

   --
   [4]Twitter | [5]LinkedIn | [6]GitHub | [7]TravisBiehn.com | [8]Google
   Plus

   --
   [9]Twitter | [10]LinkedIn | [11]GitHub | [12]TravisBiehn.com |
   [13]Google Plus

References

   1. mailto:tbiehn@gmail.com
   2. mailto:Rayzer@riseup.net
   3. https://blog.cloudflare.com/tls-certificate-optimization-technical-details/
   4. https://twitter.com/tbiehn
   5. http://www.linkedin.com/in/travisbiehn
   6. http://github.com/tbiehn
   7. http://www.travisbiehn.com/
   8. https://plus.google.com/+TravisBiehn
   9. https://twitter.com/tbiehn
  10. http://www.linkedin.com/in/travisbiehn
  11. http://github.com/tbiehn
  12. http://www.travisbiehn.com/
  13. https://plus.google.com/+TravisBiehn