The TLS protocol is usually considered as a black box that somehow
bestows security. But like any other protocol, it is a sequence of
bits and bytes. This article explains how a bit more depth about the
protocol is helpful to understand how it can be split into two
dramatically different components; and how this can be incredibly useful
from an operational perspective.
Since support for XP is ending soon, and because IE on XP was the
only realistic platform that fails to send SNI alongside its web
requests, we can assume that SNI is everywhere. Or at least, that is a
safe assumption from April 8th, 2014 -- when IE on XP is officially
acknowledged by its source as an insecure browser. (Others have said the
same thing for much longer already.) So it is not unlogical to stop
supporting browsers without SNI.
TLS servers often struggle with a limited amount of ports. Even when
using IPv6 there may be reasons why this problems shows up; backward
compatibility with IPv4 and a desire for central entrance of web traffic
to your site are a few. SNItch makes it possible to switch to various
backend servers based on the Server Name Indication contained in (at
least) web traffic.
TLS is the protocol that replaces SSL, best known for its protection
of secure websites. Connections over TLS can greatly enhance security,
but only when key management is properly implemented. When centrally
managed, such as by X.509 CA's then all risk concentrates with that CA.
Solutions like DANE help to lighten that burden, but decentral
organisation of security is in fact a much more solid model. This
article explains how to use OpenPGP-based TLS for security connections