Cloudflare blogs on their Cert Tech

[Rayzer]

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"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 4288 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20160325/3eabb2f9/attachment-0002.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20160325/3eabb2f9/attachment-0002.sig>