HTTP + HTTPS + One Time Pad / stream cipher

Question

HTTP + HTTPS + One Time Pad / stream cipher

#1 da (8 voti)
#2 da (4 voti)

3

Sto progettando un'applicazione web in cui gli utenti scambieranno brevi messaggi con il server molto frequentemente (ad esempio, alcuni caratteri al secondo). Voglio che l'intera comunicazione sia riservata, ma le prestazioni (percepite) devono essere accettabili. Ho avuto questa idea di mettere HTTP e HTTPS per lavorare insieme usando il seguente schema:

Il browser richiederà due chiavi (piuttosto grandi) dal server tramite HTTPS, quindi le memorizzerà in memoria (in linea di principio, sto pensando a tasti a tempo, cioè dati casuali). Quindi, i contenuti di ciascun messaggio saranno XORed con la prima chiave (senza alcun riutilizzo, ovviamente) e inviati via HTTP. Il server invierà la risposta nello stesso modo, usando l'altra chiave. Quando uno o entrambi i tasti stanno per essere esauriti, ne verrà richiesto un altro e così via.

La logica alla base di questo è che sia la richiesta XOR sia quella HTTP sono economiche per i piccoli messaggi, quindi le prestazioni percepite saranno buone. Le chiamate HTTPS, più costose, non saranno cruciali nel tempo e trarranno vantaggio dalla più ampia scala delle chiavi scambiate. È possibile utilizzare un altro codice di flusso al posto di one-time-pads e in futuro (se correttamente supportato ovunque) si potrebbero utilizzare WebSockets invece di richieste HTTP.

Questo tipo di cose è già stato usato prima? Questo potrebbe proteggere adeguatamente la comunicazione, o è un'idea stupida, per qualsiasi motivo? Non sono riuscito a vedere nessuna discrepanza, ma mi piacerebbe sentire l'opinione di persone più esperte prima di passare troppo tempo a questo.

http web-application tls

posta mgibsonbr 18.01.2012 - 23:07

fonte

2 risposte

4

La risposta breve è che questo non è necessario e semmai sarà meno efficiente e meno sicuro.

La parte più costosa di HTTPS è l'iniziale stretta di mano. Il client deve convalidare il certificato, eseguire una ricerca OCSP e qualche altro sovraccarico. Alla fine di questa stretta di mano viene creato un "master secret" che combina numeri casuali generati dal client e dal server. Dopo aver creato questo maestro segreto, è un sistema davvero leggero. È solo la crittografia dei dati con una chiave simmetrica, che è fondamentalmente ciò che stai suggerendo

Usa semplicemente HTTPS per tutto, è un protocollo molto leggero. Il client riutilizzerà questa chiave master senza necessità di rinegoziare. Tutto sarà sicuro ed efficiente. Non c'è bisogno di reinventare la ruota.

risposta data 18.01.2012 - 23:29

fonte

Leggi altre domande sui tag http web-application tls

cos'è il server dei nomi Akamai che vedo in alcune grandi aziende MiTM, un file binario può essere cambiato o scambiato durante il tragitto

score 8 · Accepted Answer

Stai parlando solo della crittografia; ti stai dimenticando dell'integrità, un errore spesso fatale. La crittografia ti protegge solo dagli attaccanti passivi, che possono spiare tutto ciò che dicono tutti, ma possono alterare le comunicazioni in alcun modo. Questo non è un modello molto realistico. È necessaria l'integrità verificata (vale a dire con chiave) e per questo si desidera un codice di autenticazione dei messaggi . Oppure uno di quegli schemi Crittografia autenticata .

Ora, un protocollo che inizia con una fase di inizializzazione potenzialmente costosa, che genera un segreto condiviso, che viene quindi utilizzato per crittografare i dati e proteggerli con integrità verificata ... che non è facile da costruire senza commettere errori. Fortunatamente, uno di questi protocolli esiste già, con tutti gli hard bit fatti nel modo giusto e le implementazioni già disponibili. Si chiama SSL.

Come dice @Rook, SSL è molto leggero una volta che l'handshake iniziale è stato fatto. Un tipico client HTTPS (ad esempio un browser Web) aprirà prima una connessione SSL, quindi tienilo aperto per l'invio di richieste. Una connessione SSL aperta implica un leggero overhead rispetto ai dati grezzi non protetti: in pratica, circa 30 byte extra per record (dipende dalla suite di crittografia), ogni record in grado di contenere fino a 16384 byte di dati, quindi stiamo parlando di meno dello 0,2% di aumento della dimensione, e lo otterresti con qualsiasi altro protocollo che garantisca comunque l'integrità e della riservatezza. D'altra parte, lo schema fatto a mano raddoppia il consumo di rete (il one-time-pad non è esattamente esente da inviare).

Inoltre, anche se la connessione SSL viene chiusa in qualche modo (ad esempio perché il server non desidera mantenere alcuna connessione aperta per più di 15 secondi di inattività), una nuova può essere riaperta con un handshake abbreviato che riutilizza i bit dell'handshake precedente; in particolare, richiede meno messaggi (quindi latenza ridotta), è solo simmetrico-crittografico (così leggero sulla CPU) e non comporta alcun certificato, quindi è semplice e sano.