Cloudflare blogs on their Cert Tech

Travis Biehn tbiehn at gmail.com
Fri Mar 25 10:04:53 PDT 2016


+ 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 <tbiehn at 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 <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>
>



-- 
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: 6842 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20160325/f77cd2d5/attachment-0002.txt>


More information about the cypherpunks mailing list