1

I went to Bittrex today and noticed the SSL certificate is issued to CloudFlare, not Bittrex, as seen in the screenshot below.

I'm used to seeing information on this screen which can be recognized as corresponding to the expected owner of the website. But in this case the identity information I expect seems to obfuscated behind CloudFlare's identity.

What's a safe and convenient way to verify the domain I landed at is indeed operated by Bittrex?

I don't want to rely solely on the domain name shown in the browser URL box, as my DNS (or more) might have been hijacked. I don't want to install (or trust) any third-party plugins like Cryptonite. I don't want to run any command-line tools simply to confirm I'm on an authentic website.

enter image description here

I did notice Bittrex mentioned when I dug into the Subject Alternative Name (SAN) details on the cert:

DNS Name=ssl763792.cloudflaressl.com
DNS Name=*.bittrex.com
DNS Name=bittrex.com

Is that sufficient? And how confident should I be that Bittrex's CloudFlare account hasn't been hacked e.g. by someone tricking CloudFlare into issuing a SAN for a domain they don't really own?

  • Also as a side question and out of curiosity, what do those numbered purposes represent? (e.g. 1.3.6...) – rkagerer Feb 9 '19 at 14:48
  • 1
    The "numbers" as you put it are Object Identifiers (OIDs) of certificate extensions. They are interpreted by the client software to determine if the certificate is valid for the purpose that they are using it for. I'm not sure what extensions those in your screenshot refer to. As an example though, here's the reference I use for x509v3 standard extensions, which includes things like basicConstraints and Subject Alternative Names. – nbering Feb 9 '19 at 17:37
  • 2.23.140.1.2.1 means this is a "domain-validated" certificate, ie the Issuer COMODO only attests that they validated that the domain controller made the certificate signing request. 1.3.6.1.4.1.6449.1.2.2.7 is under Comodo's private OID, and I think means this cert supports OCSP I used this to look most of that up: http://oid-info.com – Alex Wright Jul 10 '19 at 19:56
3

In this case, you'll have to rely solely on the Browser trust model. Here's a couple reasons why.

CloudFlare as Proxy

CloudFlare operates by acting as a TLS-terminating proxy. That is - you connect to CloudFlare, and they connect to whatever server their customer has configured to fetch the page. Your TLS session is with CloudFlare, and they may or may not have a separate session with the origin server.

Since CloudFlare is the termination for your TLS connection, whether you like it or not you'll need to trust CloudFlare to use this service. The connection maintains no trace of what was on the back-end connection of the proxy except for the page contents of the result.

Here's the part I don't like about CloudFlare personally: since CloudFlare provides an option for customers to operate without TLS on the backend, you effectively have no assurances when connecting to CloudFlare that this connection was encrypted between CloudFlare and the origin server.

On the flip side - one could argue that it's not CloudFlare's responsibility to secure the connection to the origin if the customer has chosen to use insecure settings.

CloudFlare as Certificate Authority

The certificate is issued to CloudFlare, and they manage the Private Key for their proxy servers. So if you want to use this website, you'll need to trust that CloudFlare is not going to allow the compromise of one of their customers' websites by issuing certificates for a domain they have not validated to be controlled by their customer/user.

The protections against them issuing false certificates are partly technical - as there are watchdog organizations that run crawlers looking for rogue CAs, and we also have Certificate Transparency Logs which can be monitored by domain owners to see if a CA they don't work with has issued a certificate on their domain.

But the main protection against this misbehaviour from CloudFlare is human. The CA/Browser Forum is a collaboration between Certificate Authorities and Browser vendors to set some baseline rules for who is allowed to have a Root Certificate included in the Browser's trust store. If CA's are found to be issuing rogue certificates - or are otherwise in breach of industry best practices - the Browsers may punish them by revoking their status as a trusted CA.

| improve this answer | |
  • Great answer! Thanks for doing such a thorough job. – rkagerer Feb 11 '19 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.