On Wed, Oct 18, 2017 at 10:01 PM, Simon Sapin <simon.sa...@exyr.org> wrote:
> On 18/10/2017 21:09, Gregory Szorc wrote: > >> Having somewhat recently overhauled Mercurial’s TLS code, I can tell >> you that Python installs without the ssl module additions added in >> 2.7.9 are still quite common in the wild. I suspect that requiring >> SNI support in the Python client will draw ire from a significant >> population. >> >> Also, there are versions of Python <2.7.9 that have the ssl module >> improvements backported. For example, RHEL/CentOS 7 ship a Python >> 2.7.5 that has all the ssl goodies from 2.7.9. >> > > Good to know, thanks. > > So please look for presence of attributes on the ssl module instead >> of version sniffing. >> > > Something like this? > > try: > from ssl import HAS_SNI > except ImportError: > HAS_SNI = False > Yes. Or use getattr() or hasattr() on an already imported module to avoid the double import. While e.g. Python <2.7.9 can speak TLS >1.0 even though you may not have e.g. ssl.PROTOCOL_TLSv1_2 defined, AFAIK Python won't support SNI unless ssl.HAS_SNI is present. > > If I were in your shoes, I would provide a hostname without SNI as a >> fallback. (I’m assuming you aren’t willing to do non-SNI CDN for cost >> reasons - last I looked this was somewhat costly.) I.e. the script >> would attempt to use CDN+SNI and fall back to a single homed service >> if the client lacks modern crypto. >> > > Part of the issue here is that we (the Servo team) are not the ones > providing the hostname. The Rust team recently declared everything other > than static.rust-lang.org (the one that requires SNI) to be “considered > private and unstable — use at your own risk”. > > https://internals.rust-lang.org/t/public-stable-rust-services/6072 > > And it’s not just a matter of updated our scripts when the server setup > changes, I’d like old git commits to keep working. (To the extend > reasonably possible.) > > Assuming you are using CloudFront backed by S3, the fallback could be >> the generic per-region S3 hostname. This is how we handle “clone >> bundle” hosting for hg.mozilla.org. >> > It is definitely S3, and I believe it is CloudFront. And yes, > https://static-rust-lang-org.s3.amazonaws.com/ is what we use at the > moment. > > > I’ll discuss with the Rust team to see if they’re willing to commit to > supporting some non-SNI hostname. > I'd set up your own S3 bucket and potentially CloudFront distribution so you are in control of your own hostnames. Also, S3 buckets are available both under https://<bucket>.<s3 region>. amazonaws.com/ and https://<region>.amazonaws.com/<bucket>/. The former requires SNI. The latter merely requires an up-to-date trusted CA certificate roots bundle for x509 certificate verification (assuming the client does certificate validation properly - which older versions of Python don't unless configured to do so - Python's default security story was a mess until relatively recently). _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
