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. This article is part of a series of articles about TLS.
Practical Problems
This is a very practical article. It deals with problems found in everyday network management.
When running secure web services, a dedicated port must usually be reserved for TLS-based protocols. This is necessary because a server shows a certificate to authenticate that it really is the server you are looking for, but this must be done before the client has told the server its assumed name. Catch-22, really.
This does not apply to all protocols; sometimes a protocol starts off in plaintext, and then executes a so-called STARTTLS handshake after which the client and continue with TLS setup and further traffic is protected. But this has not been built into all protocols. And on the Internet, the most-used protocols are the least likely to change (because there is so much code implementing it), so specifically HTTPS is a problem.
What you usually end up with is the wish to run multiple secure websites on a single default port number 443. An extension to TLS, known as SNI, solves this problem. It makes the client send the Server Name in an extension, prior to the server sending back a certificate. So, using this, the server can return the right certificate.
At another level, there still is a problem. When all software runs on one piece of software, such as the Apache web server, the server name can be used for internal switching. But what about running service components, over HTTPS, in self-contained programs? This is actually the way forwards for the web, because it deals with the silly structures of sites that build up a lot of state for every page, and always starting from zero. A dedicated web service can handle state with much more grace, and is therefore more in line with the way we use HTTP nowadays (which differs from the original design intention to make it statelessly serve resources).
It may seem like a solution to use the Apache web server as a proxy, and simply forward the TLS connection. But you quickly run out of luck trying this; you cannot crossover between HTTPS and HTTP due to differences in initiative; you may use SSLProxy in mod_ssl but cannot do the same thing with mod_gnutls. So you may get stuck, and have to do everything inside Apache.