Il recente articolo pubblicato su slashdot link afferma che le connessioni protette con TLS 1.0 sono suscettibili alla decifrazione man-in-the-middle (l'exploit BEAST). Ho un'app ospitata su Google Appengine, che sembra utilizzare TLS 1.0. Fa molto affidamento su javascript, quindi non posso consigliare ai miei utenti di spegnerlo. Cosa posso fare?
Teoria del BEAST Attack
SSL utilizza varie combinazioni di algoritmi di chiavi pubbliche e simmetriche. ( elenco OpenSSL ) Quando l'algoritmo simmetrico è un algoritmo di blocco (in contrapposizione al flusso), il concatenamento del blocco di cifratura è usato - il blocco precedente è parte dell'input al nuovo blocco.
I problemi che stiamo vedendo in questo momento sono basati sull'implementazione e sono stati discussi almeno fino al 2002. Questo La discussione CBC fa notare che è generalmente molto difficile costruire testo in chiaro nella maggior parte dei protocolli. HTTP con Javascript sta permettendo che questo accada.
Perché ne stiamo ancora soffrendo
Dovremmo allontanarci da TLS 1.0 e passare a 1.2. Ma, naturalmente, viviamo ancora in un mondo con SSL 2. Più precisamente, anche dove puoi passare a versioni TLS più recenti sul tuo server, l'onnipresente NSS non supporta la libreria. Ciò significa che non riceveresti visitatori di Firefox o Chrome.
È possibile utilizzare le cifre di flusso (RC4) e questo impedirà l'attacco. Non so se verrà utilizzato il messaggio di apertura vuoto del mio primo collegamento o se ciò influenzerebbe le varie implementazioni del client.
La tua reazione personale
Aiuta a scrivere TLS 1.2 nella libreria NSS. Fai sapere agli altri che consideri la sicurezza una priorità. Se hai tempo, fai qualche ricerca, testando quali configurazioni SSL non standard funzioneranno e quali piattaforme influenzeranno negativamente. Se scopri che RC4 funziona con tutto, pubblicalo quindi sappiamo che è stato testato.
Se non hai il tempo o la capacità per quello ... attendi. Succede troppo spesso, ma almeno alcuni utenti sono essere cigolante al riguardo.
La cosa migliore da fare è aspettare. Non ci sono abbastanza dettagli noti sull'attacco per valutare se si tratti di una cosa reale o meno vera o di come potrebbe essere risolta. Alcuni dettagli indicano un difetto nelle implementazioni e potrebbero essere corretti nei relativi browser.
Spostare le suite di crittografia basate su rc4 in cima all'elenco; l'attacco sembra essere correlato a CBC e rc4-sha non è vulnerabile in questo caso.
Aggiornamento: abbiamo pubblicato un white paper in cui viene indicato come apportare le modifiche. Disponibile qui . Per chiarire, la versione del protocollo non ti aiuterà qui a causa di considerazioni pratiche - i server non possono disabilitare TLS1.0 / SSL3 al momento a causa del supporto client scadente, e semplicemente abilitare 1.1 ti lascia ancora aperto a un attacco di downgrade anche se il client fa supporto 1.1. Passare a un cifrario non CBC è l'unica mitigazione lato server efficace di cui sono a conoscenza.
Inoltre, mail.google.com è passato a RC4 che non è suscettibile all'attacco, potrebbe anche essere che anche il motore di app di Google sia passato. Se visiti il sito con SSL, puoi fare clic sull'indicatore SSL nella barra degli URL, fare clic su "ulteriori informazioni" e vedere quale cifra viene utilizzata.
Potresti avere una visione migliore di Voci del diario di SANS a link l'unico modo possibile (discusso alla voce precedente) per contrastarlo su Server è menzionato come disabilitare i cipher usando CBC
Per una migliore comprensione del BEAST , potresti avere accesso al documento SSL per esso e al codice Java all'indirizzo link
Leggi altre domande sui tag javascript tls beast