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.
Previous parts of this series have used the Global Directory for
storing public authentication information in the form of public key
material. These mechanisms are much better than the common poor man's
choice of using passwords. Unfortunately however, we are all poor men
(and women) in some parts of our daily lives; we all use protocols and
tools that are not capable of those advanced cryptographic exchanges.
And a plethora of scripted web-tools is not improving that! So the ideal
would be to publish a password verification method in the Global
Directory as well. The SRP mechanism makes this possible.
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