Please do keep in mind that CloudFlare is essentially a consensual man-in-the-middle and for certain threat models is not compatible with the "secure" modifier.
Do also keep in mind that ssl on Heroku is terminated at their routing layer before your Dynos. Therefore it is as easy for Heroku (Salesforce) to man-in-the-middle your application as it is for CloudFlare, whether that be on instruction for the authorities or due to a bad actor on the staff.
Both of them you have to trust to do the right thing and that is an exercise left to the individual thinking of using either service. So lets not pretend that CloudFlare is a special case.
If you need to trust the none of your service providers can MITM your site then you can't use any PaaS or CDN, you need to terminate the SSL yourself, that includes for all static assets you use. No more jQuery from Google CDN, no more analytics/exception tracking/fonts from your favoured provider and no more advertising conversion tracking.
But then do also remember that it's possible for any web host to take over their customers site as long as they own the IP address. They just point the IP to another server, configure it to respond to the hostname and they can then even use any SSL certificate provider who validates the domain name with a file at a specific URL to grab a certificate.
Everyone has to make their own judgment on who they can trust. CloudFlare is no different.
Except for the part where anyone you'd like to partner with isn't going to trust your internal analytics to gauge your popularity. One of the points of third party analytics is that you have a disinterested third party who can provide the data to someone else.
If I use self hosted analytics and exception tracking I have to ensure its up-to-date with security patches. The pros will do a better job at this than anyone will self hosting. Concentrate on your core business, knowing when to outsource is important.
As someone running an ecommerce website without using advertising conversion tracking from to our various advertising networks it would simply not be measurable or cost effective. It is an essential part of how the systems works.
>Therefore it is as easy for Heroku (Salesforce) to man-in-the-middle your application as it is for CloudFlare
Heroku owns your server and can just as easily read your database off disk and/or your webserver process's memory. If you don't want to trust an infrastructure provider, you need to have physical control of your server. Such quibbles about architecture are deck chairs on the Titanic.
In one sense that's true, but as they say in the security field, the fact that someone could break down your home's front door with an axe doesn't keep us from locking our doors. Even if you generally trust your infrastructure provider, there's still no harm in considering the different layers at which you are and are not protected from certain attacks. For example, a single rogue employee might be able to do some harm in one area, but not another.
>No more jQuery from Google CDN, no more analytics/exception tracking/fonts from your favoured provider and no more advertising conversion tracking
You don't have to trust the CDN for any static resource you load as long as you use the subresource integrity feature of modern browsers[1]. You basically include the hash of the content on your main domain and the browser will validate it when it loads it from CDN. So you only need to trust your main site.
Yes. Some people have confused themselves into thinking TLS is end-to-end, when it's only point-to-point. Not specific to cloudflare; Google did this for years and the NSA took advantage of that (hence the "SSL added and removed here" thing).
We're suggesting CloudFlare as its one of the few DNS providers that supports SSL at the domain apex on Heroku.
I wouldn't recommend using their built-in SSL solution though and it's easy to turn off.
They have a lot more control that just the routing layer. They own your process, they have your source code, they have your API keys. There is a huge implicit trust in Heroku. It is my host of choice but they definitely own the keys to the palace.
"The Cloud" isn't a company that has direct access to a certificate authority.
"The Cloud" doesn't produce a valid TLS certificate for YOUR website, to encrypt the connection between them and your visitors, but not necessarily between them and your server.
"The Cloud" is a vague term for "other people's computers".
CloudFlare is better than plaintext HTTP, but if your goal is confidentiality, then CloudFlare is probably worse than direct HTTPS with no intermediaries.
Again, threat models differ. For most people, CloudFlare is probably just fine.
Is it possible to do this on the fly with subdomains? I have a specific problem with my instance where I have multiple domains and multiple subdomains. Right now I use a wildcard SSL because the subdomains are generated on the fly whenever a new client signs up.
Is it possible to create a new certificate without restarting all the servers each time a new client signs up?
No, that is not possible with the sabayon architecture. It needs to store letsencrypt key/token for all domains, and stores them as config vars.
You'd have to store them in a database for example to avoid having to restart the app.
But that wouldn't be a good solution either, as letsencrypt will not allow you to have more than 100 domains under the same certificate.
I'm using Cloudflare + Heroku to host https://www.gitignore.io [0], but I'm not using a LetsEncrypt certificate. I'm just using Cloudflare's Universal SSL[1] certificate. So far everything with Cloudflare has been amazing; they even prevented a 99 million+ request DDOS attack on my site a few years ago.
Is it possible to use this with multiple subdomains? I have multiple domains pointing to an heroku instance and each domain has multiple subdomains. Insofar as I understood LetsEncrypt does not support wildcard SSL but is it possible to use this tool (or another) to secure all subdomains as well?
Yep. Just pass in a comma delimited list to the subdomains parameters (subdomains=www,hello,another,test) and it'll add all of them to the certificate.
Is there a limit? Last I heard you could do up to 100 that way. That'd certainly be enough for my own needs (if I were using LetsEncrypt), but I don't know about other people.
CloudFlare is only providing DNS, no traffic goes though it in this instance.
It is trivial however to setup CloadFlare to have encrypted traffic to your Heroku app for free when using their cdn/webapp firewall service as your app is on https://appname.herokuapp.com which CloudFlare proxy.
Until they get nginx support working (the letsencrypt-auto tool still bangs on about its support being buggy and experimental), I don't have many options.
I can't recommend acme-tiny enough. I have cron calling a very short script every month that uses openssl & acme-tiny to renew the cert, and by adding a 'location' block to my nginx configs, they don't need to be touched during renovation.
In my experience it wasn't necessary to set up an external notification system. I got an email from expiry@letsencrypt.com 10 days before the expiration. But it's true that on Heroku it's meant to be used with automated renewals.
For this use case it really is. The number of DNS providers that have support for SSL at the domain apex using ALIAS or ANAME records could be counted on one hand.
You don't have to use any of the CloudFlare specific features, but their DNS management is really good.
If your threat model differs, this is cool.