On 2015-03-12 at 13:32 -0700, Robert Hajime Lanning wrote: > Unless both the server and client support SNI.
The only clients which don't are MSIE on Windows XP (or earlier) and ancient Android (2.something), right? And other stuff so ancient that the users are hosed with unfixed security vulnerabilities. With the recent push to finally disable SSLv3 by default (not just SSLv2), the only protocol versions left all support SNI. (It was optional with TLS1.0, coming as a TLS extension between the releases of the TLS1.0 and TLS1.1 specs. In practice, it's supported with TLS1.0 everywhere; it's exactly analogous to HTTP virtual hosting support in HTTP/1.0 -- everyone supports it, even though it only became mandatory with HTTP/1.1). You can enable SNI in the server and all clients which used to work will continue to work; you don't need to change any existing certificates or sites, this opens opportunities for future vhosts on the box. This limits how much client support in existing code-bases matters. Python _was_ following a policy that SNI was a feature extension which would only be supported in Python3; it took a long time and a lot of people protesting before the Python maintainers accepted that absence of support was becoming a security flaw and that Python2 needed support. (Disclaimer: I wrote the original patch adding SNI client support for Python). So you'll need recent Python 2 (with other security fixes too) before you can depend upon clients supporting it. Today, SNI has entered into "should assume it's present unless you know you're supporting a userbase which the OS vendor doesn't support" territory. Now, _getting_ a certificate to cover an unqualified name will be awkward; if you're running your own CA and have installed trust anchors in relevant clients, it's possible, but none of the CAs which ship as trusted-by-default should allow it any more. If your webserver requires TLS and multiple hosts but doesn't support SNI then, bluntly, you've let things rot. Time to get this onto your roadmap to clean up. It's going to get harder to justify extra public-facing IPv4 addresses with your RIR (IP address registry assigning to end organisations) with the "needs HTTPS" excuse. -Phil _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
