TLS socket wrapper server / forwarding agent?

1

Un'opzione generalmente utilizzata dalle organizzazioni per inoltrare una connessione TCP in chiaro sulla rete è SSH locale e il port forwarding remoto. SSH collega una porta localmente e inoltra tutto il traffico al computer remoto su SSH.

Questa è un'ottima soluzione per una serie di motivi, vale a dire che si ottiene la crittografia dei messaggi e l'autenticità dei messaggi, e si ha anche una certa garanzia di autorizzazione in quanto l'utente deve avere accesso SSH alla macchina (e root se il porta è sotto 1024).

Tuttavia, nel caso in cui volessi che la crittografia e l'autenticità dei messaggi senza volessero l'autenticazione di per sé, non sono sicuro di un'altra soluzione esistente.

Quello che ero in grado di immaginare, tuttavia, è una configurazione server / agente che avvolgere TLS e fare port forwarding dove necessario. Dite che ho bisogno di eseguire Redis su Internet (perché è oltre il punto, se vi state chiedendo il perché, chiedete un altro servizio che si adatti al meglio alla vostra immaginazione). Una soluzione decente sarebbe quella di eseguire un processo sul server Redis che si collegava a una determinata porta e fungeva da proxy TLS. Dovresti eseguire un intero handshake TLS per connetterti e trasferire dati a questo proxy.

La seconda metà dell'equazione sarebbe quella di eseguire qualcosa sul lato client sui server che devono connettersi a Redis. Ciò dovrebbe di nuovo ascoltare su una porta locale, ma inoltrare il traffico su TLS al suddetto proxy TLS.

Esiste una tale tecnologia? Mi piacerebbe l'eventuale possibilità di utilizzare i certificati SSL lato client per l'autenticazione, ma il semplice upgrade a TLS su testo in chiaro è un vantaggio enorme a mio parere.

    
posta Naftuli Kay 21.09.2015 - 22:08
fonte

2 risposte

1

Potresti dare un'occhiata a stunnel , che fornisce tunnel basati su SSL. A seconda di come lo si configura, può fornire ciò che si cerca.

Assicurati di fare la crittografia a causa di possibili aggressori e gli attaccanti possono diventare attivi , cioè provare a modificare i dati in transito o mascherati come un vero server o client. Se non c'è autenticazione del client, il server non può essere sicuro di chi sta parlando. Se si configura stunnel sul lato server per utilizzare un certificato autofirmato e si configurano i client in modo che accetti qualsiasi certificato inviato dal server, i client potrebbero essere costretti a parlare con un server falso, e questo può finire con un brutto Man-in-the-Middle .

Quindi, anche se rendete i client "anonimi" (senza autenticazione client), probabilmente vorrete ancora autenticare il server, cioè fate in modo che il server usi un certificato appropriato che il client convalida. (A meno che non si usi il tunnel solo per trasmettere un protocollo che è a sua volta adeguatamente protetto, ad esempio SSH-within-SSL, che è possibile ma forse non è quello che si sta pensando.)

    
risposta data 21.09.2015 - 22:16
fonte
0

Il bus di servizio di Azure è progettato per gestire questo scenario esatto. È possibile inoltrare e indirizzare qualsiasi porta su 443 a Azure Datacenter e consumarla su un altro host.

Sono possibili diversi scenari di autenticazione, incluso anonimo.

    
risposta data 22.10.2015 - 13:35
fonte

Leggi altre domande sui tag