Bundled stunnel doesn't support hostname verification.

[dreid]

	version	released
Heroku	4.35	2011.02.05
Memcachier	5.09	2015.01.02
Latest	5.35	2016.07.18

The checkHost option was added in 5.15 released on 2015.04.16. It requires OpenSSL 1.0.2+ (latest release on 3 May 2016), heroku currently only ships OpenSSL 1.0.1f 6 Jan 2014 so memcachier-tls-buildpack will have to bundle (or statically link) an openssl in addition to the current stunnel. (Or get heroku to update it, which seems… improbable.)

It is worth mentioning that currently the memcachier issued certs don't have hostnames that would validate with checkHost turned on. But if/once that changes this should ticket be soon to follow.

[dterei]

Yes, right now we intentionally don't due hostname verification due to the complexity of certificate management under that scheme as we give each customer their own DNS records. We've yet to see a convincing argument about that impacting security (since we've pinned our certificate) for our use case but are always open to discuss it further as we care about these issues.

[edmorley]

Yes, right now we intentionally don't due hostname verification due to the complexity of certificate management under that scheme as we give each customer their own DNS records.

But this should still work so long as the cert served is a wildcard cert? eg with a common name of *.prod.memcachier.com.

Though I agree since the CA cert is pinned, checkHost doesn't really add much value.

[alevy]

@edmorley that's true, although multi-level wildcard certificates aren't well defined, as far as I knew, so seems a bit risky to use them (I haven't actually checked what stunnel does with them). We would need it since the form of server names are: identifier.region.provider.prod.memcachier.com.

[edmorley]

Oh yes sorry you're absolutely right.

The only way around that is if the list of {region, provider} were under 100 combinations, the single cert could have the other domains under the Subject Alternative Name field, eg:
*.us-east-1.heroku.prod.memcachier.com, *.us-east-2.heroku.prod.memcachier.com, ...

Though checking one of my Heroku apps now I see it has yet another nested level, something like:
identifier1.identifier2.us-east-N.heroku.prod.memcachier.com

...which wouldn't work.

[alevy]

ah yeah: identifier1 is a unique identifier for the proxy/cache pair and identifier2 is the cache name (which is just helpful for reference in, e.g., support tickets.