What SNItch does is very simple, and it will stay simple: it switches
connections based on
ServerNameIndication in the onset of TLS.
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
ClientHellothat holds the server name
- TODO: Barren?
Potential future support could be for:
- 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'
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.