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/

Reply via email to