Skink: De la Transferencia Segura de Archivos a una Plataforma de Túneles Inversos

If you have ever needed to move a file between two machines securely without setting up SSH keys, configuring S3 buckets, or navigating corporate firewall rules, you have likely used — or at least heard of — croc, the go-to encrypted file transfer tool. Inspired by croc’s model, Skink takes the concept significantly further, growing into a complete encrypted file transfer and reverse tunnel platform — a single binary that handles everything from ad-hoc file sharing to multi-hop relay chains through optional WSS or QUIC transports, with an MCP server for AI agent integration and a plugin architecture designed to keep growing.

Si alguna vez has necesitado mover un archivo entre dos máquinas de forma segura sin configurar claves SSH, cubos de S3 o sortear reglas de firewall corporativas, probablemente has usado — o al menos has oído hablar de — croc, la herramienta de transferencia de archivos cifrados de referencia. Inspirado en el modelo de croc, Skink lleva el concepto significativamente más lejos, creciendo hasta convertirse en una plataforma completa de transferencia cifrada de archivos y túneles inversos — un único binario que maneja desde el intercambio ad-hoc de archivos hasta cadenas de relays multi-salto a través de transportes WSS o QUIC opcionales, con un servidor MCP para integración con agentes de IA y una arquitectura de plugins diseñada para seguir creciendo.

Who should use Skink? Security researchers and red teams who currently juggle croc for file transfer, ngrok or frp for tunnel exposure, and Chisel for SOCKS5 pivoting — Skink replaces the entire stack with one binary. DevOps engineers who need to expose local services through restrictive firewalls without standing up a VPN. AI engineers building agentic systems that need to move files, expose services, or route traffic programmatically through the MCP server. And anyone who wants encrypted, zero-knowledge relay infrastructure without trusting a SaaS provider with their data.

¿Quién debería usar Skink? Investigadores de seguridad y red teams que actualmente combinan croc para transferencia de archivos, ngrok o frp para exposición de túneles y Chisel para pivoting SOCKS5 — Skink reemplaza toda la pila con un solo binario. Ingenieros DevOps que necesitan exponer servicios locales a través de firewalls restrictivos sin montar una VPN. Ingenieros de IA que construyen sistemas agénticos que necesitan mover archivos, exponer servicios o enrutar tráfico programáticamente a través del servidor MCP. Y cualquiera que quiera infraestructura de relay cifrada y de conocimiento cero sin confiar sus datos a un proveedor SaaS.

The croc Foundation: Encrypted File Transfer

La Base de croc: Transferencia de Archivos Cifrada

At its core, Skink inherits and extends croc’s proven file transfer model. Two peers rendezvous through a relay server using PAKE (Password Authenticated Key Exchange) to establish a shared secret without exposing it to the relay. All data is encrypted with NaCl secretbox (XChaCha20-Poly1305), and the relay itself is zero-knowledge — it sees only encrypted bytes, never the content or the key. The transfer supports multi-file and folder sends, automatic resume of interrupted transfers, local LAN peer discovery, text paste, progress bars with QR codes for mobile pairing, and .gitignore-aware file selection via --git. Multiple hash algorithms are available (xxhash, imohash, md5, highway). The relay can run in TCP mode with configurable port ranges, WebSocket/SSE UI for browser-based transfers, and optional TLS wrapping. Everything runs on a single statically linked Go binary.

En su núcleo, Skink hereda y extiende el probado modelo de transferencia de archivos de croc. Dos pares se encuentran a través de un servidor relay usando PAKE (Password Authenticated Key Exchange) para establecer un secreto compartido sin exponerlo al relay. Todos los datos se cifran con NaCl secretbox (XChaCha20-Poly1305), y el propio relay es de conocimiento cero — solo ve bytes cifrados, nunca el contenido ni la clave. La transferencia soporta envíos multi-archivo y de carpetas, reanudación automática de transferencias interrumpidas, descubrimiento local de pares en LAN, pegado de texto, barras de progreso con códigos QR para emparejamiento móvil y selección de archivos consciente de .gitignore vía --git. Múltiples algoritmos de hash están disponibles (xxhash, imohash, md5, highway). El relay puede ejecutarse en modo TCP con rangos de puertos configurables, interfaz WebSocket/SSE para transferencias basadas en navegador y envoltura TLS opcional. Todo funciona en un único binario Go estáticamente enlazado.

But the file transfer layer, while fully functional, is now only the entry point. Where Skink truly distinguishes itself is the reverse tunnel platform that sits on top of the same relay infrastructure.

Pero la capa de transferencia de archivos, aunque completamente funcional, es ahora solo el punto de entrada. Donde Skink realmente se distingue es en la plataforma de túneles inversos que se asienta sobre la misma infraestructura de relay.

The Tunnel Platform: ngrok, frp, and Chisel in One Binary

La Plataforma de Túneles: ngrok, frp y Chisel en un Solo Binario

Skink’s tunnel subsystem is the most feature-dense part of the project. It exposes local services through a public relay using a dual-port design — one port for control connections (PAKE-authenticated) and one for stream-multiplexed proxy data. The tunnel client registers itself with the relay, receives a public URL or port, and forwards incoming connections to a local address. This is the standard ngrok/reverse-tunnel pattern, but Skink implements it across four tunnel types and four transport layers, each with distinct operational trade-offs.

El subsistema de túneles de Skink es la parte más densa en funcionalidad del proyecto. Expone servicios locales a través de un relay público usando un diseño de doble puerto — un puerto para conexiones de control (autenticadas con PAKE) y uno para datos proxy multiplexados por flujo. El cliente de túnel se registra con el relay, recibe una URL o puerto público y reenvía las conexiones entrantes a una dirección local. Este es el patrón estándar de túnel inverso (ngrok), pero Skink lo implementa a través de cuatro tipos de túnel y cuatro capas de transporte, cada una con compensaciones operativas distintas.

The tunnel types cover the most common use cases. HTTP tunnels expose local web servers through a public subdomain. TCP tunnels forward any TCP-based service — SSH, RDP, databases, reverse shells — to a public port. UDP tunnels frame datagrams over multiplexed streams for services like OpenVPN or DNS tunneling. SOCKS5 proxy mode is particularly powerful for red team work: it creates a single tunnel endpoint through which you route any tool — nmap, curl, impacket, sqlcmd — via proxychains, without each tool needing its own tunnel. Additionally, private tunnels (a --private flag on any type) expose a service through the relay without any public port — access is granted by token only, making the service invisible to internet scanners.

Los tipos de túnel cubren los casos de uso más comunes. Los túneles HTTP exponen servidores web locales a través de un subdominio público. Los túneles TCP reenvían cualquier servicio basado en TCP — SSH, RDP, bases de datos, reverse shells — a un puerto público. Los túneles UDP encuadran datagramas sobre flujos multiplexados para servicios como OpenVPN o DNS tunneling. El modo proxy SOCKS5 es particularmente potente para trabajo de red team: crea un único endpoint de túnel a través del cual enruta cualquier herramienta — nmap, curl, impacket, sqlcmd — vía proxychains, sin que cada herramienta necesite su propio túnel. Adicionalmente, los túneles privados (una bandera --private en cualquier tipo) exponen un servicio a través del relay sin ningún puerto público — el acceso se concede solo por token, haciendo que el servicio sea invisible para los escáneres de internet.

Transports: Beyond TCP

Transportes: Más Allá de TCP

Skink’s transport layer offers multiple options depending on the operational environment. The default transport is standard TCP, but the project ships three additional transports. WSS (WebSocket Secure) wraps the tunnel in a WebSocket connection using gorilla/websocket and utls for TLS fingerprint cloaking — it presents a Chrome 131 JA3 fingerprint instead of Go’s distinctive crypto/tls handshake, making the traffic harder to fingerprint by passive inspection tools. A Noise Protocol NK handshake runs inside the WSS connection, providing double-encryption that survives even TLS inspection proxies. QUIC transport uses HTTP/3 via quic-go, providing native stream multiplexing without head-of-line blocking and a 1-RTT TLS 1.3 handshake — no yamux layer needed, lower per-stream latency. Named pipe transport uses Windows SMB named pipes with 37 legitimate pipe names (eventlog, spoolss, lsarpc) for lateral movement scenarios. Each transport plugs into a StreamSession interface that abstracts the multiplexing layer, allowing the same client and server code to work across all four without modification.

La capa de transporte de Skink ofrece múltiples opciones dependiendo del entorno operativo. El transporte predeterminado es TCP estándar, pero el proyecto incluye tres transportes adicionales. WSS (WebSocket Secure) envuelve el túnel en una conexión WebSocket usando gorilla/websocket y utls para el camuflaje de huellas TLS — presenta una huella JA3 de Chrome 131 en lugar del característico handshake crypto/tls de Go, haciendo que el tráfico sea más difícil de identificar por herramientas pasivas de inspección. Un handshake Noise Protocol NK se ejecuta dentro de la conexión WSS, proporcionando doble cifrado que sobrevive incluso a proxies de inspección TLS. El transporte QUIC usa HTTP/3 vía quic-go, proporcionando multiplexación nativa de flujos sin bloqueo por cabeza de línea y un handshake TLS 1.3 de 1-RTT — sin necesidad de capa yamux, menor latencia por flujo. El transporte Named pipe usa pipes con nombre SMB de Windows con 37 nombres de pipe legítimos (eventlog, spoolss, lsarpc) para escenarios de movimiento lateral. Cada transporte se conecta a una interfaz StreamSession que abstrae la capa de multiplexación, permitiendo que el mismo código de cliente y servidor funcione en los cuatro sin modificación.

When to Use Each Transport

Cuándo Usar Cada Transporte

The choice of transport has real operational consequences. TCP (--transport tcp) is the default and the best choice for most scenarios — lowest overhead, highest raw throughput, universal compatibility, and full support for SOCKS5/HTTP proxy traversal. Use it when there are no DPI or TLS inspection concerns. WSS (--transport wss) is the right choice when operating through restrictive networks — corporate proxies, DPI firewalls, or TLS inspection appliances. The Chrome JA3 fingerprint makes the traffic look like ordinary browser WebSocket traffic, and the inner Noise layer protects the payload even if the outer TLS is terminated and re-encrypted. WSS also supports SOCKS5/HTTP proxy traversal, making it the best option for Tor routing. The trade-off is higher overhead from WebSocket framing and double encryption. QUIC (--transport quic) shines on lossy or high-latency links — a dropped packet on one stream doesn’t stall others (no head-of-line blocking), and the 1-RTT handshake reduces connection latency. However, QUIC uses UDP, which means it cannot traverse SOCKS5 or HTTP CONNECT proxies and is blocked by some corporate firewalls that only allow TCP:443. Use QUIC when you control both endpoints and want maximum performance on unreliable links. Named pipe (--transport pipe) is Windows-only and exists specifically for lateral movement via SMB — not a general-purpose transport.

La elección del transporte tiene consecuencias operativas reales. TCP (--transport tcp) es el predeterminado y la mejor opción para la mayoría de escenarios — menor sobrecarga, mayor rendimiento bruto, compatibilidad universal y soporte completo para travesía de proxy SOCKS5/HTTP. Úsalo cuando no haya preocupaciones de DPI o inspección TLS. WSS (--transport wss) es la elección correcta al operar a través de redes restrictivas — proxies corporativos, firewalls DPI o appliances de inspección TLS. La huella JA3 de Chrome hace que el tráfico parezca tráfico WebSocket ordinario de navegador, y la capa interna de Noise protege el payload incluso si el TLS externo se termina y re-cifra. WSS también soporta travesía de proxy SOCKS5/HTTP, lo que lo convierte en la mejor opción para enrutamiento Tor. La contrapartida es mayor sobrecarga por el encuadre WebSocket y el doble cifrado. QUIC (--transport quic) brilla en enlaces con pérdida o alta latencia — un paquete perdido en un flujo no detiene a otros (sin bloqueo por cabeza de línea), y el handshake de 1-RTT reduce la latencia de conexión. Sin embargo, QUIC usa UDP, lo que significa que no puede atravesar proxies SOCKS5 o HTTP CONNECT y está bloqueado por algunos firewalls corporativos que solo permiten TCP:443. Usa QUIC cuando controles ambos extremos y quieras máximo rendimiento en enlaces no confiables. Named pipe (--transport pipe) es solo para Windows y existe específicamente para movimiento lateral vía SMB — no es un transporte de propósito general.

Noise Protocol and TLS Fingerprint Cloaking

Protocolo Noise y Camuflaje de Huellas TLS

Skink’s WSS transport combines two privacy techniques. First, the TLS layer uses utls to mimic the Chrome 131 JA3 fingerprint — at the TLS handshake level, the connection is indistinguishable from a browser-initiated WebSocket connection to passive fingerprinting tools. Second, a Noise Protocol NK handshake runs inside the WSS tunnel, providing an additional encryption layer that wraps the payload independently of TLS. This means even if a TLS inspection proxy terminates and re-encrypts the outer connection, the inner Noise layer remains intact — the proxy sees encrypted Noise frames, not the actual tunnel traffic. The Noise keypair is generated with skink noise-keygen and used for server-authenticated tunnels, where the client knows the server’s public key in advance.

El transporte WSS de Skink combina dos técnicas de privacidad. Primero, la capa TLS usa utls para imitar la huella JA3 de Chrome 131 — a nivel de handshake TLS, la conexión es indistinguible de una conexión WebSocket iniciada por navegador para herramientas pasivas de fingerprinting. Segundo, un handshake Noise Protocol NK se ejecuta dentro del túnel WSS, proporcionando una capa de cifrado adicional que envuelve el payload independientemente de TLS. Esto significa que incluso si un proxy de inspección TLS termina y re-cifra la conexión externa, la capa interna de Noise permanece intacta — el proxy ve tramas Noise cifradas, no el tráfico real del túnel. El par de claves Noise se genera con skink noise-keygen y se usa para túneles autenticados por servidor, donde el cliente conoce la clave pública del servidor de antemano.

Multi-Hop Relay Chaining

Encadenamiento Multi-Salto de Relays

For operations that require traffic to pass through multiple administrative boundaries, Skink supports multi-hop relay chaining. Relays can be stacked with the --upstream flag: Target → Relay-C → Relay-B → Relay-A → You. Each relay only knows the immediate next hop, not the full path or the final destination. The upstream relay allocates ports and handles connections, and the downstream relay forwards all multiplexed streams. This creates a chain where compromise of any single relay reveals at most one hop in each direction, not the full path or the identity of the endpoints.

Para operaciones que requieren que el tráfico pase a través de múltiples límites administrativos, Skink soporta el encadenamiento multi-salto de relays. Los relays pueden apilarse con la bandera --upstream: Objetivo → Relay-C → Relay-B → Relay-A → Tú. Cada relay solo conoce el salto inmediato siguiente, no la ruta completa ni el destino final. El relay upstream asigna puertos y maneja conexiones, y el relay downstream reenvía todos los flujos multiplexados. Esto crea una cadena donde el compromiso de cualquier relay individual revela como máximo un salto en cada dirección, no la ruta completa ni la identidad de los extremos.

SOCKS5 and HTTP CONNECT Proxying

Proxy SOCKS5 y HTTP CONNECT

Skink supports routing its own connections — file transfers, tunnels, exec, and even relay chaining — through SOCKS5 or HTTP CONNECT proxies via the global --socks5 and --connect flags. This applies to every command and is particularly useful for operating through restrictive networks. The proxy performs remote DNS resolution, so .onion addresses resolve correctly through Tor. Local targets (loopback, LAN IPs, localhost) bypass the proxy automatically. Only --transport tcp and wss can traverse a SOCKS5/HTTP proxy — QUIC uses UDP and cannot go through a TCP proxy, a critical operational constraint.

Skink soporta enrutar sus propias conexiones — transferencias de archivos, túneles, exec, e incluso cadenas de relays — a través de proxies SOCKS5 o HTTP CONNECT mediante las banderas globales --socks5 y --connect. Esto se aplica a todos los comandos y es particularmente útil para operar a través de redes restrictivas. El proxy realiza resolución DNS remota, por lo que las direcciones .onion se resuelven correctamente a través de Tor. Los destinos locales (loopback, IPs LAN, localhost) evitan el proxy automáticamente. Solo --transport tcp y wss pueden atravesar un proxy SOCKS5/HTTP — QUIC usa UDP y no puede pasar a través de un proxy TCP, una restricción operativa crítica.

This enables Tor routing for any Skink operation. The client connects through Tor’s SOCKS5 listener (default 127.0.0.1:9050), and the relay can be deployed as a Tor hidden service — no public IP, no inbound ports, no certificate-transparency footprint. Combined with multi-hop chaining, this allows building relay chains that pass through Tor exit nodes, .onion relays, and CLEARNET hops in any sequence.

Esto permite el enrutamiento a través de Tor para cualquier operación de Skink. El cliente se conecta a través del listener SOCKS5 de Tor (por defecto 127.0.0.1:9050), y el relay puede desplegarse como un servicio oculto de Tor — sin IP pública, sin puertos de entrada, sin huella de transparencia de certificados. Combinado con el encadenamiento multi-salto, esto permite construir cadenas de relays que pasan a través de nodos de salida de Tor, relays .onion y saltos CLEARNET en cualquier secuencia.

Designed for AI Agents from Day One

Diseñado para Agentes de IA Desde el Primer Día

One of Skink’s most distinctive design decisions is its comprehensive support for AI agent integration — not as an afterthought, but as a first-class concern. Every command understands --output json for structured output, --agent (a meta-flag that sets --quiet --log-format json --output json --yes in one shot), and semantic exit codes (0 success, 1 general error, 2 auth failure, 3 network error, 4 bad input, 5 timeout, 6 unavailable) that agents can branch on without parsing human-readable output. JSON logging outputs newline-delimited structured records for programmatic ingestion. The --agent flag responds with structured JSON everywhere, including --version: skink —agent —version → {“status”:“ok”,“data”:{“version”:“v1.0.0”}}

Una de las decisiones de diseño más distintivas de Skink es su soporte integral para la integración con agentes de IA — no como una ocurrencia tardía, sino como una preocupación de primera clase. Cada comando entiende --output json para salida estructurada, --agent (una meta-bandera que activa --quiet --log-format json --output json --yes de un solo golpe) y códigos de salida semánticos (0 éxito, 1 error general, 2 fallo de autenticación, 3 error de red, 4 entrada incorrecta, 5 timeout, 6 no disponible) en los que los agentes pueden bifurcarse sin analizar salida legible por humanos. El logging JSON produce registros estructurados delimitados por nueva línea para ingestión programática. La bandera --agent responde con JSON estructurado en todas partes, incluyendo --version: skink —agent —version → {“status”:“ok”,“data”:{“version”:“v1.0.0”}}

The capstone of this design is the MCP (Model Context Protocol) server — a standalone binary (skink-mcp) that exposes Skink’s feature set as native AI agent tools. The MCP server registers 10 tools (send_file, receive_files, tunnel_start, tunnel_stop, tunnel_list, tunnel_access, relay_start, generate_code, noise_keygen, version) and 5 resources (version info, command summary, active tunnels on a relay, relay status and metrics, default configuration reference). The implementation wraps the skink CLI via os/exec with the --agent flag, providing process isolation — a crash in file transfer doesn’t take down the agent session. All file operations are restricted to a configurable working directory, tunnel connections can be limited to an allowlist of relay hosts, and commands run with configurable timeouts via exec.CommandContext. Setup is a one-liner in opencode.jsonc or Claude Desktop config: point it at the skink-mcp binary and the agent immediately has encrypted file transfer, tunnel creation, and Noise key generation available as native tools.

La culminación de este diseño es el servidor MCP (Model Context Protocol) — un binario independiente (skink-mcp) que expone el conjunto de funcionalidades de Skink como herramientas nativas para agentes de IA. El servidor MCP registra 10 herramientas (send_file, receive_files, tunnel_start, tunnel_stop, tunnel_list, tunnel_access, relay_start, generate_code, noise_keygen, version) y 5 recursos (información de versión, resumen de comandos, túneles activos en un relay, estado y métricas del relay, referencia de configuración predeterminada). La implementación envuelve el CLI de skink vía os/exec con la bandera --agent, proporcionando aislamiento de procesos — un fallo en la transferencia de archivos no derriba la sesión del agente. Todas las operaciones de archivos están restringidas a un directorio de trabajo configurable, las conexiones de túneles pueden limitarse a una lista blanca de hosts relay, y los comandos se ejecutan con timeouts configurables vía exec.CommandContext. La configuración es una línea en opencode.jsonc o la configuración de Claude Desktop: apunta al binario skink-mcp y el agente tiene inmediatamente transferencia de archivos cifrada, creación de túneles y generación de claves Noise disponibles como herramientas nativas.

The repository also ships a discoverable agent skill at .agents/skills/skink/SKILL.md, following the agentskills.io convention. Agents like opencode, Claude Code, and Cursor automatically load Skink usage guidance from the project directory — command reference, critical gotchas (global flag ordering, data port = control+1, transport constraints for proxying), and operational patterns. The skill references a separate references/operations.md with end-to-end scenarios for reverse shells, Tor/onion setups, and multi-hop chains.

El repositorio también incluye un skill de agente descubrible en .agents/skills/skink/SKILL.md, siguiendo la convención agentskills.io. Agentes como opencode, Claude Code y Cursor cargan automáticamente la guía de uso de Skink desde el directorio del proyecto — referencia de comandos, errores críticos (orden de banderas globales, puerto de datos = control+1, restricciones de transporte para proxying) y patrones operativos. El skill referencia un references/operations.md separado con escenarios completos para reverse shells, configuraciones Tor/onion y cadenas multi-salto.

Architecture: The Plugin Engine

Arquitectura: El Motor de Plugins

Under the hood, Skink’s architecture is organized around two layers of plugin interfaces. The engine package defines the core infrastructure: Transport (Dial/Listen/Name/IsStreamBase — TCP, WSS, QUIC, named pipe), StreamMultiplexer (yamux for TCP/WSS, native QUIC streams), TunnelProtocol (reverse proxy, forward proxy, remote exec, private access, relay hop), CryptoProvider (PAKE+NaCl, Noise Protocol), and ProxyDriver (TCP, UDP, HTTP proxying). On top of this, the tunnel package defines an extension layer: AuthPlugin for custom authentication backends, ObfuscatorPlugin for traffic transformation, and StreamProcessorPlugin for per-stream middleware. Both layers are registered in thread-safe registries that allow runtime discovery and compile-time feature selection — the tunnel-only build (make build-tunnel) and transfer-only build (make build-transfer) exclude unused components, producing binaries as small as ~2MB with UPX.

Internamente, la arquitectura de Skink está organizada alrededor de dos capas de interfaces de plugins. El paquete engine define la infraestructura central: Transport (Dial/Listen/Name/IsStreamBase — TCP, WSS, QUIC, named pipe), StreamMultiplexer (yamux para TCP/WSS, flujos nativos de QUIC), TunnelProtocol (proxy inverso, proxy directo, ejecución remota, acceso privado, salto de relay), CryptoProvider (PAKE+NaCl, Noise Protocol), y ProxyDriver (proxy TCP, UDP, HTTP). Sobre esto, el paquete tunnel define una capa de extensión: AuthPlugin para backends de autenticación personalizados, ObfuscatorPlugin para transformación de tráfico, y StreamProcessorPlugin para middleware por flujo. Ambas capas se registran en registros thread-safe que permiten descubrimiento en tiempo de ejecución y selección de características en tiempo de compilación — la compilación solo-túnel (make build-tunnel) y solo-transferencia (make build-transfer) excluyen componentes no utilizados, produciendo binarios de hasta ~2MB con UPX.

Security Model

Modelo de Seguridad

Skink’s security model is defense-in-depth across five layers. Key exchange uses PAKE (Password Authenticated Key Exchange) — two parties derive a shared secret from a short password without ever transmitting it, so the relay never sees the key. Data encryption uses NaCl secretbox (XChaCha20-Poly1305) for all file transfer data and tunnel control messages — authenticated encryption that detects tampering. For tunnels that traverse TLS inspection, an optional Noise Protocol NK handshake adds a second encryption layer inside the WSS transport, independent of TLS. Forward secrecy is provided by periodic ECDH P-256 rekeying (--rekey-interval) — even if a session key is compromised, only the traffic between rekey intervals is exposed. State at rest is protected by AES-256-GCM encryption of persistence files (--state-key), so a stolen state file is useless without the master key.

El modelo de seguridad de Skink es defensa en profundidad a través de cinco capas. El intercambio de claves usa PAKE (Password Authenticated Key Exchange) — dos partes derivan un secreto compartido a partir de una contraseña corta sin transmitirla nunca, por lo que el relay nunca ve la clave. El cifrado de datos usa NaCl secretbox (XChaCha20-Poly1305) para todos los datos de transferencia de archivos y mensajes de control del túnel — cifrado autenticado que detecta manipulación. Para túneles que atraviesan inspección TLS, un handshake Noise Protocol NK opcional añade una segunda capa de cifrado dentro del transporte WSS, independiente de TLS. El secreto hacia adelante lo proporciona el rekeying periódico ECDH P-256 (--rekey-interval) — incluso si una clave de sesión se ve comprometida, solo se expone el tráfico entre intervalos de rekey. El estado en reposo está protegido por cifrado AES-256-GCM de los archivos de persistencia (--state-key), por lo que un archivo de estado robado es inútil sin la clave maestra.

On top of encryption, three features provide integrity and accountability. Per-message integrity (--integrity) attaches an HMAC-SHA256 tag to every control message, derived from the PAKE session key — active tampering is detected immediately. Tamper-evident audit logging (--audit-log) writes an append-only JSON log where each entry is HMAC-chained to the previous one — any modification breaks the chain. Per-tunnel ACLs (--acl-allow/--acl-deny) enforce fine-grained access control on every proxy connection before forwarding, supporting IP, CIDR, and domain patterns. Combined with relay-level CIDR allowlists, rate limiting, and private tunnel tokens, this gives operators granular control over who can access what, with a forensic trail for incident response.

Sobre el cifrado, tres características proporcionan integridad y rendición de cuentas. La integridad por mensaje (--integrity) adjunta una etiqueta HMAC-SHA256 a cada mensaje de control, derivada de la clave de sesión PAKE — la manipulación activa se detecta inmediatamente. El registro de auditoría a prueba de manipulación (--audit-log) escribe un registro JSON de solo adición donde cada entrada está encadenada por HMAC a la anterior — cualquier modificación rompe la cadena. Las ACLs por túnel (--acl-allow/--acl-deny) aplican control de acceso granular en cada conexión proxy antes de reenviar, soportando IP, CIDR y patrones de dominio. Combinado con listas blancas CIDR a nivel de relay, límites de tasa y tokens de túneles privados, esto da a los operadores control granular sobre quién puede acceder a qué, con una pista forense para respuesta a incidentes.

Operational Features

Características Operativas

Beyond the headline capabilities, Skink is packed with operational features that reflect real deployment needs. The REST API (binding to 127.0.0.1 only, with optional bearer token auth) provides programmatic tunnel management: list, inspect, and delete tunnels at /api/v1/tunnels. Config hot-reload via --watch applies route rules, bypass patterns, and heartbeat parameter changes without restarting the tunnel — active connections are preserved. Dynamic split tunneling supports both CIDR notation and wildcard domain patterns (*.corp.internal, *.sso.example.com) in the same rules — domain patterns are checked before DNS resolution, so routing decisions for named hosts don’t require a lookup. Per-tunnel resource controls allow operators to set connection caps (--max-connections), bandwidth limits (--bandwidth-limit bytes/sec), and idle timeouts (--idle-timeout) per tunnel registration. Health checking with configurable TCP/HTTP probes per tunnel entry enables automated failover. Prometheus metrics expose tunnel counts, proxy bytes, and connection rates on a configurable /metrics endpoint. CIDR allowlists (--tunnel-allowlist), per-IP rate limiting (--tunnel-rate-limit), and max concurrent connections (--tunnel-max-conns) provide defense-in-depth for relay operators. The relay supports password file sources and password exec sources for reading credentials from files or external commands like HashiCorp Vault. HTTPS proxy supports TLS certificates and Let’s Encrypt autocert for automatic certificate management.

Más allá de las capacidades principales, Skink está repleto de características operativas que reflejan necesidades reales de despliegue. La API REST (vinculándose solo a 127.0.0.1, con autenticación opcional por bearer token) proporciona gestión programática de túneles: listar, inspeccionar y eliminar túneles en /api/v1/tunnels. La recarga en caliente de configuración vía --watch aplica cambios en reglas de ruta, patrones de bypass y parámetros de heartbeat sin reiniciar el túnel — las conexiones activas se conservan. El enrutamiento dinámico de túnel dividido soporta tanto notación CIDR como patrones de dominio comodín (*.corp.internal, *.sso.example.com) en las mismas reglas — los patrones de dominio se verifican antes de la resolución DNS, por lo que las decisiones de enrutamiento para hosts nombrados no requieren una consulta. Los controles de recursos por túnel permiten a los operadores establecer límites de conexiones (--max-connections), límites de ancho de banda (--bandwidth-limit bytes/seg) y timeouts de inactividad (--idle-timeout) por registro de túnel. La verificación de salud con sondas TCP/HTTP configurables por entrada de túnel permite failover automatizado. Las métricas de Prometheus exponen conteos de túneles, bytes de proxy y tasas de conexión en un endpoint /metrics configurable. Las listas blancas CIDR (--tunnel-allowlist), el límite de tasa por IP (--tunnel-rate-limit) y el máximo de conexiones concurrentes (--tunnel-max-conns) proporcionan defensa en profundidad para operadores de relay. El relay soporta fuentes de archivo de contraseña y fuentes de ejecución de contraseña para leer credenciales de archivos o comandos externos como HashiCorp Vault. El proxy HTTPS soporta certificados TLS y Let’s Encrypt autocert para gestión automática de certificados.

Zero-copy on Linux uses splice(2) through a kernel pipe buffer for TCP-to-TCP proxy paths and sendfile(2) for file-to-socket transfers, with fallback to pooled io.CopyBuffer on non-Linux or non-TCP transports. Buffer pooling via sync.Pool of 32KB buffers eliminates allocation churn on the GC for sustained transfers. Adaptive window tuning (--adaptive-window) sends RTT probes every 5 seconds and auto-adjusts the yamux stream window to match the bandwidth-delay product — optimal throughput on high-latency links without manual tuning. In SOCKS5 mode, configurable DNS resolution (--dns remote|local|both) controls where lookups happen: remote (default, relay resolves), local (client resolves), or both. GOMEMLIMIT guidance for constrained environments and fuzz testing (make fuzz) across all ingress parsers complete the performance story.

La copia cero en Linux usa splice(2) a través de un buffer pipe del kernel para rutas de proxy TCP-a-TCP y sendfile(2) para transferencias de archivo a socket, con caída a io.CopyBuffer agrupado en no-Linux o transportes no-TCP. El agrupamiento de buffers vía sync.Pool de buffers de 32KB elimina la fluctuación de asignaciones en el GC para transferencias sostenidas. El ajuste adaptativo de ventana (--adaptive-window) envía sondas RTT cada 5 segundos y ajusta automáticamente la ventana de flujo yamux para coincidir con el producto ancho de banda-retardo — rendimiento óptimo en enlaces de alta latencia sin ajuste manual. En modo SOCKS5, la resolución DNS configurable (--dns remote|local|both) controla dónde ocurren las consultas: remote (por defecto, el relay resuelve), local (el cliente resuelve), o both. La guía GOMEMLIMIT para entornos con recursos limitados y las pruebas de fuzzing (make fuzz) en todos los analizadores de ingreso completan la historia de rendimiento.

Resilience and High Availability

Resiliencia y Alta Disponibilidad

Skink’s tunnel infrastructure is designed to survive failures. Session resumption persists tunnel state to a JSON file on the relay (--persist /var/lib/skink/state.json); when the relay restarts, it reloads the state file and existing tunnels reconnect with their saved tunnel ID (--resume /tmp/tunnel-resume.json) instead of re-registering. If the saved ID is no longer valid — the relay was wiped, the state file is stale — the client automatically falls back to a fresh registration. This means a relay can be upgraded or restarted without dropping active tunnels.

La infraestructura de túneles de Skink está diseñada para sobrevivir a fallos. La reanudación de sesión persiste el estado del túnel a un archivo JSON en el relay (--persist /var/lib/skink/state.json); cuando el relay se reinicia, recarga el archivo de estado y los túneles existentes se reconectan con su ID de túnel guardado (--resume /tmp/tunnel-resume.json) en lugar de volver a registrarse. Si el ID guardado ya no es válido — el relay fue borrado, el archivo de estado está obsoleto — el cliente cae automáticamente a un registro nuevo. Esto significa que un relay puede ser actualizado o reiniciado sin perder túneles activos.

Relay HA clustering takes this further: multiple relays share tunnel state via a sync protocol. Each relay runs a sync listener (--sync-port 9400) and peer list (--sync-peers relayA:9400); when a tunnel registers or unregisters on one relay, the change propagates to all peers. Clients configure a comma-separated failover list (--server relayA:9090,relayB:9091); with shared state and --resume, the tunnel reconnects to whichever relay is available. This turns the relay layer into a fault-tolerant cluster rather than a single point of failure.

El clustering HA de relays lleva esto más lejos: múltiples relays comparten el estado del túnel vía un protocolo de sincronización. Cada relay ejecuta un listener de sincronización (--sync-port 9400) y una lista de pares (--sync-peers relayA:9400); cuando un túnel se registra o desregistra en un relay, el cambio se propaga a todos los pares. Los clientes configuran una lista de conmutación separada por comas (--server relayA:9090,relayB:9091); con estado compartido y --resume, el túnel se reconecta al relay que esté disponible. Esto convierte la capa de relay en un clúster tolerante a fallos en lugar de un único punto de fallo.

For environments where no relay is available at all, an embedded relay mode (--embedded-relay 9009) starts a minimal P2P relay directly in the client process — useful as a fallback when the primary relay is unreachable, or for fully self-contained deployments that don’t want to manage a separate server. Connection migration (--migrate relay-b:9090) takes this further: it moves a live tunnel to another relay without dropping the connection — establish new control + data session on the target, then close the old one. State files persisted via --persist are encrypted at rest with AES-256-GCM (--state-key, defaults to SHA-256 of relay password). Use --persist :memory: for in-memory-only state that never touches disk.

Para entornos donde no hay ningún relay disponible, un modo de relay embebido (--embedded-relay 9009) inicia un relay P2P mínimo directamente en el proceso del cliente — útil como respaldo cuando el relay primario es inalcanzable, o para despliegues totalmente autónomos que no quieren gestionar un servidor separado. La migración de conexión (--migrate relay-b:9090) lleva esto más allá: mueve un túnel en vivo a otro relay sin perder la conexión — establece una nueva sesión de control + datos en el destino, luego cierra la anterior. Los archivos de estado persistidos vía --persist se cifran en reposo con AES-256-GCM (--state-key, por defecto SHA-256 de la contraseña del relay). Usa --persist :memory: para estado solo en memoria que nunca toca el disco.

Operational Hardening

Endurecimiento Operativo

Skink includes several features that harden tunnels against traffic analysis, tampering, and key compromise. Traffic obfuscation (--padding-min 64 --padding-max 1024) adds random-length padding to every control message, making traffic patterns harder to analyze statistically. Combined with heartbeat jitter (--heartbeat-jitter 0.4), the timing and size distributions of tunnel traffic become unpredictable, defeating beaconing detection.

Skink incluye varias características que endurecen los túneles contra el análisis de tráfico, la manipulación y el compromiso de claves. La ofuscación de tráfico (--padding-min 64 --padding-max 1024) añade relleno de longitud aleatoria a cada mensaje de control, haciendo que los patrones de tráfico sean más difíciles de analizar estadísticamente. Combinado con el jitter de heartbeat (--heartbeat-jitter 0.4), las distribuciones de temporización y tamaño del tráfico del túnel se vuelven impredecibles, derrotando la detección de balizamiento.

Message integrity verification (--integrity) attaches an HMAC-SHA256 tag to every control message, derived from the PAKE session key. The relay verifies each message before processing; tampering is detected immediately. This protects against active manipulation of tunnel control traffic in transit.

La verificación de integridad de mensajes (--integrity) adjunta una etiqueta HMAC-SHA256 a cada mensaje de control, derivada de la clave de sesión PAKE. El relay verifica cada mensaje antes de procesarlo; la manipulación se detecta inmediatamente. Esto protege contra la manipulación activa del tráfico de control del túnel en tránsito.

Forward secrecy via rekey (--rekey-interval 3600) rotates the session key periodically using ECDH key exchange over the encrypted channel. Even if a session key is compromised, only the traffic between rekey intervals is exposed — past intervals used a different key, and future intervals will use a new one. The rekey uses ephemeral ECDH P-256 keys exchanged within the existing encrypted session.

El secreto hacia adelante vía rekey (--rekey-interval 3600) rota la clave de sesión periódicamente usando intercambio de claves ECDH sobre el canal cifrado. Incluso si una clave de sesión se ve comprometida, solo se expone el tráfico entre intervalos de rekey — los intervalos pasados usaron una clave diferente, y los futuros intervalos usarán una nueva. El rekey usa claves efímeras ECDH P-256 intercambiadas dentro de la sesión cifrada existente.

Tamper-evident audit logging (--audit-log /var/log/skink-audit.json) writes an append-only JSON log of all tunnel operations — registration, access, proxy connections, errors. Each entry is HMAC-chained to the previous one; any tampering with the log file breaks the chain and is immediately detectable. This provides a forensic trail for compliance and incident response.

El registro de auditoría a prueba de manipulación (--audit-log /var/log/skink-audit.json) escribe un registro JSON de solo adición de todas las operaciones de túnel — registro, acceso, conexiones proxy, errores. Cada entrada está encadenada por HMAC a la anterior; cualquier manipulación del archivo de registro rompe la cadena y es inmediatamente detectable. Esto proporciona una pista forense para cumplimiento y respuesta a incidentes.

Per-tunnel ACLs (--acl-allow "10.0.0.0/8,*.internal.corp" --acl-deny "0.0.0.0/0") provide fine-grained access control inside tunnels — checked on every proxy connection before forwarding. Supports IP, CIDR, and domain patterns, separate from the relay-level allowlist. Built-in compression (--compress gzip) negotiates compression per tunnel (deflate default, gzip, or none) across all control messages and data streams — particularly effective for HTTP tunnels carrying text-heavy responses. Domain regex routing extends split tunneling with re: prefixed patterns (--route "re:.*\.corp\.example\.(com|net)"), working alongside CIDR and wildcard domain patterns for complex routing rules.

Las ACLs por túnel (--acl-allow "10.0.0.0/8,*.internal.corp" --acl-deny "0.0.0.0/0") proporcionan control de acceso granular dentro de los túneles — verificado en cada conexión proxy antes de reenviar. Soporta IP, CIDR y patrones de dominio, separado de la lista blanca a nivel de relay. La compresión integrada (--compress gzip) negocia compresión por túnel (deflate por defecto, gzip, o none) en todos los mensajes de control y flujos de datos — particularmente efectiva para túneles HTTP que transportan respuestas con mucho texto. El enrutamiento por regex de dominios extiende el túnel dividido con patrones prefijados con re: (--route "re:.*\.corp\.example\.(com|net)"), funcionando junto a notación CIDR y patrones de dominio comodín para reglas de enrutamiento complejas.

For UDP tunnels behind NAT, STUN-assisted NAT traversal (--stun-server stun:3478) performs a STUN binding request to discover the public mapping and enable direct peer-to-peer connections when possible, falling back to relay traversal when NAT type prevents it.

Para túneles UDP detrás de NAT, la travesía NAT asistida por STUN (--stun-server stun:3478) realiza una solicitud de enlace STUN para descubrir el mapeo público y habilitar conexiones directas de igual a igual cuando sea posible, cayendo a travesía de relay cuando el tipo de NAT lo impide.

Private Tunnel Sharing: Access by Token

Compartición Privada de Túneles: Acceso por Token

A particularly elegant feature is private tunnel sharing. When a tunnel is registered with --private, the relay allocates no public port. Instead, an access token is generated, and the service remains completely dark — no URL to scan, no port to probe. A secondary client connects to the relay with the access token, and the relay bridges the connection to the tunnel’s data session through the existing RequestProxy mechanism. The token is the sole authorization; the relay cannot decrypt the payload. This works with all tunnel types (TCP, HTTP, UDP) and is particularly useful for sharing services with a specific operator without exposing them to internet-wide scanning.

Una característica particularmente elegante es la compartición privada de túneles. Cuando un túnel se registra con --private, el relay no asigna ningún puerto público. En su lugar, se genera un token de acceso, y el servicio permanece completamente oscuro — sin URL que escanear, sin puerto que sondear. Un cliente secundario se conecta al relay con el token de acceso, y el relay puentea la conexión a la sesión de datos del túnel a través del mecanismo existente RequestProxy. El token es la única autorización; el relay no puede descifrar el payload. Esto funciona con todos los tipos de túnel (TCP, HTTP, UDP) y es particularmente útil para compartir servicios con un operador específico sin exponerlos a escaneo global de internet.

Build System and Distribution

Sistema de Compilación y Distribución

Skink’s build system is comprehensive and release-oriented. make produces a standard build with version information injected from git tags. make build-tunnel produces a tunnel-only binary (~2MB with UPX). make build-transfer produces a transfer-only binary. make build-mcp produces the MCP server binary. make release generates a cross-platform release matrix (linux/darwin/windows, multiple architectures including riscv64 and 32-bit x86) with SHA256 checksums. make sbom produces a software bill of materials. make check runs lint, vet, and format checks. The Docker setup uses a multi-stage build with docker-compose and healthcheck. Pre-built binaries are available from the GitHub releases page, or via go install github.com/octagono/skink@latest.

El sistema de compilación de Skink es completo y orientado a lanzamientos. make produce una compilación estándar con información de versión inyectada desde las etiquetas git. make build-tunnel produce un binario solo-túnel (~2MB con UPX). make build-transfer produce un binario solo-transferencia. make build-mcp produce el binario del servidor MCP. make release genera una matriz de lanzamiento multiplataforma (linux/darwin/windows, múltiples arquitecturas incluyendo riscv64 y x86 de 32 bits) con sumas de verificación SHA256. make sbom produce una lista de materiales de software. make check ejecuta lint, vet y verificaciones de formato. La configuración Docker usa una compilación multi-etapa con docker-compose y healthcheck. Los binarios pre-compilados están disponibles desde la página de releases de GitHub, o vía go install github.com/octagono/skink@latest.

Pentesting and Red Team Use Cases

Casos de Uso para Pentesting y Red Team

Skink is particularly well-suited for authorized penetration testing and red team operations where a single binary must serve as file transfer, tunnel, proxy, and persistence layer. The most common workflows:

Skink es particularmente adecuado para pruebas de penetración autorizadas y operaciones de red team donde un único binario debe servir como transferencia de archivos, túnel, proxy y capa de persistencia. Los flujos de trabajo más comunes:

SOCKS5 pivoting is the primary use case. A single skink tunnel --type socks5 on the target creates a proxy endpoint through the relay. From the operator’s machine, any tool — nmap, impacket-secretsdump, CrackMapExec, sqlcmd, xfreerdp — routes through proxychains over the encrypted tunnel. No per-tool configuration needed. Per-tunnel ACLs (--acl-allow "10.0.0.0/8,*.target.corp") scope the pivot to authorized ranges. Stealthy access uses private tunnels (--private) so no port is exposed — the relay allocates no public endpoint, and the operator connects by access token. Multi-hop pivoting chains relays across network boundaries for OPSEC: each hop knows only the next relay, and traffic obfuscation (--padding-min 64 --padding-max 1024 --heartbeat-jitter 0.4) defeats beaconing detection. Data exfiltration uses skink send over an existing tunnel or through Tor (--socks5 127.0.0.1:9050) for encrypted, resumable file transfer. Persistent access combines session persistence (--persist), HA clustering (--sync-peers), and PFS rekeying (--rekey-interval 3600) to maintain resilient tunnels that survive relay restarts and rotate keys automatically.

El pivoting SOCKS5 es el caso de uso principal. Un único skink tunnel --type socks5 en el objetivo crea un endpoint proxy a través del relay. Desde la máquina del operador, cualquier herramienta — nmap, impacket-secretsdump, CrackMapExec, sqlcmd, xfreerdp — se enruta a través de proxychains por el túnel cifrado. Sin configuración por herramienta. Las ACLs por túnel (--acl-allow "10.0.0.0/8,*.target.corp") limitan el pivote a rangos autorizados. El acceso sigiloso usa túneles privados (--private) para que no se exponga ningún puerto — el relay no asigna ningún endpoint público, y el operador se conecta por token de acceso. El pivoting multi-salto encadena relays a través de límites de red para OPSEC: cada salto solo conoce el siguiente relay, y la ofuscación de tráfico (--padding-min 64 --padding-max 1024 --heartbeat-jitter 0.4) derrota la detección de balizamiento. La exfiltración de datos usa skink send sobre un túnel existente o a través de Tor (--socks5 127.0.0.1:9050) para transferencia de archivos cifrada y reanudable. El acceso persistente combina persistencia de sesión (--persist), clustering HA (--sync-peers) y rekey PFS (--rekey-interval 3600) para mantener túneles resilientes que sobreviven reinicios de relay y rotan claves automáticamente.

How Skink Compares

Cómo se Compara Skink

What makes Skink notable is not any single feature — most of the individual capabilities exist in other tools. ngrok provides HTTP tunnels. frp provides multi-protocol reverse proxying. Chisel provides SOCKS5 over WebSocket. croc provides encrypted file transfer. What Skink does is unify all of these into a single codebase with a consistent architecture, a shared authentication and encryption model, and a design philosophy that treats AI agents as first-class consumers. The plugin interfaces in the engine package mean the architecture can grow without accumulating technical debt — new transports implement Transport, new protocols implement TunnelProtocol, new crypto implements CryptoProvider, and the existing infrastructure of stream multiplexing, proxy routing, heartbeat management, and metrics collection applies automatically.

Lo que hace notable a Skink no es ninguna característica individual — la mayoría de las capacidades individuales existen en otras herramientas. ngrok proporciona túneles HTTP. frp proporciona proxy inverso multi-protocolo. Chisel proporciona SOCKS5 sobre WebSocket. croc proporciona transferencia de archivos cifrada. Lo que hace Skink es unificar todo esto en un único código base con una arquitectura consistente, un modelo compartido de autenticación y cifrado, y una filosofía de diseño que trata a los agentes de IA como consumidores de primera clase. Las interfaces de plugins en el paquete engine significan que la arquitectura puede crecer sin acumular deuda técnica — los nuevos transportes implementan Transport, los nuevos protocolos implementan TunnelProtocol, los nuevos cifrados implementan CryptoProvider, y la infraestructura existente de multiplexación de flujos, enrutamiento de proxy, gestión de heartbeats y recolección de métricas se aplica automáticamente.

For security researchers, red teams, and operators who have been cobbling together croc for file transfer, ngrok for HTTP exposure, frp for TCP relay, and Chisel for SOCKS5 — each with its own config format, authentication model, and deployment pattern — Skink offers a single binary that replaces all four, with a consistent flag interface, unified PAKE-based auth, and the same zero-knowledge relay model throughout. For AI engineers building agentic systems that need to move files, expose services, or route traffic through restrictive networks, the MCP server provides the same capabilities as structured tools with JSON output, semantic exit codes, and configurable access controls — no shell scripting required.

Para investigadores de seguridad, red teams y operadores que han estado combinando croc para transferencia de archivos, ngrok para exposición HTTP, frp para relay TCP y Chisel para SOCKS5 — cada uno con su propio formato de configuración, modelo de autenticación y patrón de despliegue — Skink ofrece un único binario que reemplaza los cuatro, con una interfaz de banderas consistente, autenticación unificada basada en PAKE y el mismo modelo de relay de conocimiento cero en todas partes. Para ingenieros de IA que construyen sistemas agénticos que necesitan mover archivos, exponer servicios o enrutar tráfico a través de redes restrictivas, el servidor MCP proporciona las mismas capacidades como herramientas estructuradas con salida JSON, códigos de salida semánticos y controles de acceso configurables — sin necesidad de scripting de shell.

---

References

Referencias