An important part of keeping Coinbase and our customers safe is keeping up with the rapid evolution of web security standards. One of the areas we focus on is the addition and deprecation of HTTP security headers. Our goal is always to ensure that we provide industry-leading protection to our customers using up-to-date browsers, while degrading gracefully for customers using older browsers. We have recently started sending the Expect-CT (ECT) header on coinbase.com. What follows is a short, technical overview of how we see the ECT header fitting into the overall suite of protections available with current HTTP security headers.

As of 3 November, coinbase.com is sending an ECT header in enforcing mode. ECT is a bleeding-edge security header (present in Chrome 61, Opera 48 and coming to Firefox) that tells browsers to expect the certificate presented by a website to exist in a Certificate Transparency (CT) log. In the same vein as HTTP Strict Transport Security (HSTS) and HTTP Public Key Pins (HPKP), ECT is a cache-on-first-use header with the cache period set in the header.

Coinbase has used the HPKP header nearly since its inception. HPKP is very hard to use safely. It’s so hard to use that only 375 sites of the Alexa top 1,000,000 have been willing to use it. Coinbase pins the root certs of our current CA as well as a backup CA. In this way we essentially prevent compliant browsers from honoring certificates from any other CA for our domain. With the coming removal of HPKP from Chrome, we were interested in finding a way to mitigate the same risks.

Let’s back up for a second. Why, given the dangers of using HPKP, would Coinbase take the risk? What risk are we mitigating such that we feel, on balance, that HPKP is the better option? The basic answer is that we just don’t trust the modern Certificate Authority (CA) system. We want to mitigate the risk of a rogue or hacked CA issuing certificates for our domains and using those certificates to steal our customers’ funds. HPKP is a great solution to this problem because we can pin CA root certificates, effectively telling browsers that any certificate issued from any other CA is invalid. Now that this mechanism is going away, what can we do to maintain our existing security posture? We believe a combination of Certification Authority Authorization (CAA) DNS records, ECT and CT log monitoring is the current best solution to this problem.

CAA is a fairly new DNS record type which allows us to tell CAs that they are or are not authorized to issue a certificate for a domain. This provides limited protection in our view. Implementation is voluntary for CAs and explicitly advised against for browsers. It does not prevent either a malicious or a hacked CA from issuing certificates for our domain, but it does mean that responsible CAs are unlikely to allow an attacker to issue a certificate for our domains using their normal certificate issuance systems. We use CAA records because they have the benefit of not being dependent on the browser versions our customers are using.

ECT is actually a much more effective control than CAA. In effect, ECT means that even if an attacker is able to cause a CA to issue a certificate for one of our domains, that certificate must be present in a CT log to be valid. This is important because it gives us a chance to detect that certificate issuance before it can do harm to our users. It still leaves a gap versus the control offered by HPKP, where that fraudulent certificate would be actively rejected by browsers, but it gives us a fighting chance to protect our users.

In order to detect that a certificate has been issued for one of our domains, we need to monitor CT logs. There are a number of options, ranging from the commercial to several open source choices. Using these projects, you can monitor, in real time, certificate issuance across the CT log. If you see certificates that overlap with your domain you can engage the CA that issued the certificate. For what it’s worth, this feed is also a really interesting source of potential phishing sites.

Today, we’re sending both HPKP and ECT headers. We’ll continue to do so until HPKP is officially deprecated. We believe that HPKP is a more effective and proactive mitigation to the threat of today’s CA infrastructure. We also recognize that HPKP is a dangerous and little-used header as it exists today. Our hope is that the suite of protections available to sites like ours will continue to evolve, and include both proactive and reactive controls. As they evolve we will continue to remain on the cutting edge.

Protecting Coinbase, our customers and their assets, is our mission on the security team. If you’re looking for a place to work where security REALLY MATTERS, you’ll be hard pressed to find anything better than Coinbase. Take a look at one of our open security positions, and let us know if you find something interesting!

Moving to Expect-CT was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Similar to Notcoin - Blum - Airdrops In 2024

origin »

184 +