Criptare e autenticare il traffico localhost?

Hai bisogno della crittografia per scoraggiare gli attaccanti passivi (persone malvagie che spiano la linea e cercare di elaborare il contenuto dei dati) e integrità (e suo fratello autenticazione ) per bloccare gli attaccanti attivi che alterano i dati mentre sono in transito. SSL fornisce entrambi. Tuttavia, questo ha senso solo in contesti in cui gli aggressori possono effettivamente spiare o alterare i dati in transito. Per due processi sulla stessa macchina, che comunicano attraverso la rete "localhost", gli aggressori che possono farlo hanno, di solito, "già vinto".

I dettagli possono variare a seconda del sistema operativo. Tuttavia, la tua sicurezza dipenderà normalmente dal sistema operativo, non dalla crittografia. Si consideri, ad esempio, un sistema Unix con più utenti. Se i due processi parlano tra loro, i processi di altri utenti non possono dare un'occhiata agli scambi di dati (a meno che l'autore dell'attacco non sia root , e quindi possa fare qualsiasi cosa); tuttavia, possono provare rappresentazione : ad un certo punto, uno dei componenti deve connettersi all'altro e il punto di rendez-vous per i socket TCP è un numero di porta. Un utente malintenzionato che può eseguire il proprio codice (come un utente normale) sulla macchina può mantenere un server falso che riceverà la richiesta di connessione al posto del componente previsto. Per proteggersi da ciò, il client dovrebbe assicurarsi che parli al server previsto (e viceversa): questo può essere fatto con SSL, ma esistono soluzioni migliori (in questo caso, usando Unix -domini con un percorso protetto da diritti di accesso al sistema e / o getpeereid() ).

Se, nel tuo caso, la macchina locale è considerata "pulita" (nessun codice ostile viene eseguito sulla macchina, sotto alcuna identità), le connessioni a localhost sono sicure e non è necessaria alcuna protezione aggiuntiva. Se il codice potenzialmente ostile ma non privilegiato può essere eseguito sulla macchina (che è il modello "macchina multiutente condivisa", come era tipico dei sistemi Unix alla fine degli anni '80), allora dovresti usare le funzioni del sistema operativo per assicurarti che le connessioni siano effettivamente trasmesse al processo giusto (cioè a un processo in esecuzione sull'identità prevista). SSL sarebbe eccessivo.

Bene, se i due programmi sono in esecuzione sul localhost perché si desidera utilizzare la comunicazione di rete? Puoi utilizzare qualsiasi IPC (comunicazione interprocesso) come Named Pipes È possibile specificare un descrittore di sicurezza per una named pipe quando si chiama la funzione CreateNamedPipe. Il descrittore di sicurezza controlla l'accesso alle estremità client e server della named pipe.

Leggi il Modello di controllo degli accessi per sapere come proteggere le pipe denominate. link Oppure si può semplicemente usare un algoritmo di crittografia simmetrica per cui il segreto è noto a entrambi i processi, si può hardcode il segreto nel codice.