<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
<blockquote>TLS Certificate Optimization: The Technical Details
behind "No Browser Left Behind"<br>
<br>
Overview<br>
<br>
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.)<br>
<br>
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.<br>
<br>
Certificate Optimization Logic<br>
<br>
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".<br>
TLS Handshake<br>
<br>
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 <a class="moz-txt-link-rfc2396E" href="https://">"https://"</a> 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.)<br>
<br>
</blockquote>
<br>
More:
<a class="moz-txt-link-freetext" href="https://blog.cloudflare.com/tls-certificate-optimization-technical-details/">https://blog.cloudflare.com/tls-certificate-optimization-technical-details/</a><br>
<pre class="moz-signature" cols="72">--
RR
"Through counter-intelligence it should be possible to pinpoint potential trouble-makers ... And neutralize them, neutralize them, neutralize them"</pre>
</body>
</html>