Cloudflare blogs on their Cert Tech

[Travis Biehn]

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 <Rayzer at 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:
> 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 5790 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20160325/b2322e86/attachment-0002.txt>