Source: snid
Section: golang
Priority: optional
Maintainer: Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
Uploaders: Daniel Gröber <dxld@darkboxed.org>,
Rules-Requires-Root: no
Build-Depends: debhelper-compat (= 13),
               help2man,
               dh-sequence-golang,
               golang-any,
               golang-agwa-go-listener-dev,
Testsuite: autopkgtest-pkg-go
Standards-Version: 4.7.2
Vcs-Browser: https://salsa.debian.org/go-team/packages/snid
Vcs-Git: https://salsa.debian.org/go-team/packages/snid.git
Homepage: https://github.com/AGWA/snid
XS-Go-Import-Path: github.com/AGWA/snid

Package: snid
Section: net
Architecture: any
Depends: ${misc:Depends},
         ${shlibs:Depends},
Static-Built-Using: ${misc:Static-Built-Using}
Description: Oblivious TLS-SNI proxy with zero config IPv4/v6 translation
 A lightweight proxy used to forward TLS connections (without decryption)
 to backend servers listening on IPv6 or UNIX sockets based only on the
 cleartext server name indication (SNI) hostname. Note: ESNI/ECH is not
 (yet) supported.
 .
 Backend addresses are constructed based on DNS lookups or filesystem path
 for IPv6 and UNIX listeners respectively, making snid deployments
 exceedingly easy to manage.
 .
 Unlike other TLS-SNI proxies snid's address mapping approach (-mode nat46)
 allows exposing any unmodified TLS-based service listening on IPv6 towards
 legacy IPv4 with no configuration or loss of client identity by encoding
 IPv4 client addresses into IPv6 source addresses.
 .
 Running a few snid nodes across an infrastructure thus removes the need to
 think about legacy IP problems like address exhaustion, port-forwarding or
 multi-layer NAT ever again.
 .
 Client identity in snid isn't handled using hacks such as the PROXY
 protocol or X-Forwarded-For/X-Real-IP headers in the case of HTTP based
 protocols. This avoids confusion as to what is the real client IP, at
 least for programs not already expecting these.