Timeline for Now that CloudFlare offers potentially-insecure free SSL to all users, would a new HTTP header be useful?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2015 at 16:08 | comment | added | Rushyo | Cloudflare have the capacity to completely automatically generate certs against a Comodo intermediary. That intermediary is not Cloudflare exclusive, it's one of Comodo's larger intermediates. You can see this by looking at the cert chain on almost any Cloudflare site. | |
| Apr 11, 2015 at 0:51 | comment | added | AJ Henderson | @Rushyo - are you saying that Comodo actually gave cloudflare access to their root pki keys? That would be very bad and would be worth stopping trusting them. (Other CAs have been delisted for compromise of the private keys.) Much more likely would be that they signed a code signing key for Cloudflare and you could simply decert the specific delegated key to break chain of trust. IT wouldn't block 90% of the internet, it would only break the certs that Cloudflare generates. | |
| Apr 10, 2015 at 9:52 | comment | added | Rushyo | I feel this is a good case demonstrating why the theory of the current PKI trust mode doesn't function in the real world (wide web), and should therefore be replaced with superior alternatives insofar as is practical. Which is exactly what this question is querying, how practical is this alternative? I suspect the answer is 'not very', but it's still a legitimate enquiry. | |
| Apr 10, 2015 at 9:45 | comment | added | Rushyo | But hey, one of the few nice things about a certificate-based model is, if you really want, you can just stop trusting the root. Feel free to delete Comodo's roots (who supply Cloudflare's certificates) from all your systems if that's your assessment. Maybe losing a good chunk of the WWW works for you and your use cases. But I heartily disagree that such a control would be the outcome of an measured assessment of the associated risks/benefits for the majority of end-users. | |
| Apr 10, 2015 at 9:38 | comment | added | Rushyo | By the definition you are working to, you cannot trust Cloudflare sites (objectively, because of this). You cannot trust most CDNs. You cannot trust most government sites. You cannot trust most enterprises. That is not a working, practical, engineering definition to apply to working, practical, engineering trust/risk decisions. | |
| Apr 10, 2015 at 9:33 | comment | added | Rushyo | That is not what often happens in the wild. Most enterprises and CDNs simply do not provide full trust across their WANs. For a public example, look at Google, who only addressed this because of the NSA leaks. The theoretical definition on what you would prefer to trust is not the actual choice you, as a user making trust decisions, has to make. You also have to deal with incomplete information and the need to make practical risk decisions. Practicality and theory are not in sync in this context. | |
| Apr 10, 2015 at 1:53 | comment | added | AJ Henderson | @Rushyo - in the case of a load balancer, it should be load balancing across either a physically secure network or should be re-encrypting to the end point. The problem is only when you label something as a secure connection that is not. Providing an SSL gateway to a non-encrypted site across the open internet is a very different thing from providing a load balancer in a secure data center that acts as the SSL head. | |
| Apr 9, 2015 at 14:55 | comment | added | Rushyo | "then people can simply reject" I invite you to 'simply' reject GeoTrust (who Cloudflare use) and Google's CA (since Google do this with their load-balancing) and almost every government CA (who also do this with their load-balancing) and then continue using the web. People need to accept that public CAs are not an optimal model and, in practice, you can't just ignore alternatives on the grounds of "works as designed" unless you accept you will end up distrusting basically the entire WWW for one reason or another. | |
| Oct 17, 2014 at 14:55 | comment | added | AJ Henderson | @Riking - I was more indicating that Cloudflair should be de-trusted for behaving in an insecure manner. Using SSL only to their servers is insecure and I'd argue an abuse of the system. We could consider an extension to SSL to say something is a proxy cert, but honestly, I don't see enough value in such a service. It doesn't protect from anything other than ISP spying or a spying device installed on the user's local routing path. It is something, but still leaves a lot open. | |
| Oct 17, 2014 at 10:07 | comment | added | Riking | But doing anything on the certificate level would be too inflexible to indicate whether the backend connection is plain, SSL Self-signed, or full proper SSL. (Those are the three options they give you.) | |
| Sep 30, 2014 at 14:13 | vote | accept | Dr. McKay | ||
| Sep 29, 2014 at 18:18 | comment | added | Dr. McKay | I see your point now. While a header would be able to convey information about the security of the connection, by then it would be too late since the cookies and authentication and such would already be sent. | |
| Sep 29, 2014 at 18:15 | comment | added | AJ Henderson | @Dr.McKay - that's the thing though, the place to do that is in the certificate. If Cloudflare is putting up certificates that don't make the state of the connection clear, then they should be stripped of trust until they fix the problem, just like we'd strip any other major misbehaving CA of not behaving in a trustworthy manner. That is how the SSL system is designed to operated, we don't need some new solution to a problem that is already solved. | |
| Sep 29, 2014 at 18:08 | comment | added | Dr. McKay | As it stands now, connections appear to be entirely secure to the user. It can only get better by exposing a mechanism to inform the browser that the connection isn't secure from end-to-end. | |
| Sep 29, 2014 at 18:06 | comment | added | Dr. McKay |
Well, there are plenty of legitimate uses for SSL proxying. CloudFlare is a legitimate company and they don't seem to have any ill intentions. The problem is that through their system people can configure sites that appear to be secure but in reality aren't. Their certificates are valid for the domains. Sure, you could check if the Server is cloudflare-nginx, but there are so many sites on CloudFlare now that you'd lose a good chunk of the Internet if you decided to just distrust all SSL/TLS CloudFlare connections.
|
|
| Sep 29, 2014 at 17:43 | history | answered | AJ Henderson | CC BY-SA 3.0 |