What SNItch does is very simple, and it will stay simple: it switches connections based on ServerNameIndication in the onset of TLS.

Functional Scope

Things it will not do because they are better done at endpoints include:

• Implementations of TLS mechanisms
• Selection of TLS/SSL versions

Things that SNItch can do with relative ease include:

• Handle wildcards to cover subordinate DNS names
• Accept TLS in a variety of wrapping forms
• Dramatic sizability by using a local Oracle/BerkeleyDB for the names

Supported TLS Carrier Protocols

Currently considered algorithms are:

• SSL/TLS run over TCP
• SNItch is TLS reduced to a ClientHello that holds the server name
• TODO: Barren?

Potential future support could be for:

• *-EAP-TTLS
• OpenVPN's TLS flow

Integration with Network Relays?

Most of what SNItch does comes down to accepting packets and forwarding them. This could be done more efficiently in kernel space; it could be said that SNItch sets up a NAT translation (with possible IPv4/IPv6 crossover).

SNItch could perhaps be used as a userspace plugin to Linux' iptables and ip6tables, that sets up a DNAT connection based on the initial parts of the protocol. It does not seem that netfilter supports such userspace plugins; a kernel API may remedy this.

Either way, building SNItch as a kernel module would make it highly specific for one operating system, presumably Linux, whereas SNItch is highly portable. Such special cases may be useful for efficiency reasons, but not in the early stages.