Perché i browser non supportano TLS senza crittografia e deprecano la compressione per i dati pubblici

1

In questi giorni osserviamo la tendenza a utilizzare HTTP su TLS (HTTPS) per tutte le comunicazioni. Raccomanda tutti i fornitori di servizi Internet pesanti e che afferma di buone pratiche. Ma la suite TLS ha 3 opzioni per diversi scopi:

  1. Verifica del certificato per garantire l'autorizzazione del server.
  2. Verifica hash per garantire che il pacchetto HTTP non venga alterato da apparecchiature di rete, Man-in-the-Middle, ISP, ecc.
  3. Cripta i dati per nasconderlo dalla lettura di Man-in-the-Middle.

Le prime due opzioni hanno senso per tutti i tipi di connessione. Ma il terzo ha senso solo per i dati sensibili. Supponiamo che l'utente apra un sito di pubbliche relazioni pubbliche o una biblioteca pubblica. In che senso aggiungere un sovraccarico di crittografia a tali dati? La stessa situazione con la compressione TLS e la normale compressione HTTP nel canale TLS. Compressione deprecata perché CRIME e BREACH attacca la vulnerabilità dei dati crittografati e può essere utilizzata per dati pubblici.

Allo stesso tempo i browser più comuni non supportano la crittografia NULL. Puoi assicurarti sul test di ssllabs.com

Ho controllato Chrome / 54.0.2840.100 e Firefox / 49.0 ed entrambi non supportano TLS_RSA_WITH_NULL_SHA o simili

    
posta slonma 21.11.2016 - 11:12
fonte

4 risposte

2
  • dati pubblici non significa nessuna aspettativa di privacy durante la lettura : " come affrontare l'AIDS " forse una pagina pubblica, ma i lettori potrebbero desiderare la privacy .
  • Se sul sito web sono presenti cookie, probabilmente non sono dati pubblici (ad esempio i cookie di autorizzazione, ma anche i cookie di tracciamento, ad esempio)
risposta data 21.11.2016 - 12:33
fonte
1

Anche se i dati sono pubblicamente disponibili, potresti non volere che le persone sappiano che lo stai scaricando personalmente. Ad esempio, potresti non volere che il tuo datore di lavoro veda che stai guardando annunci di lavoro pubblicati pubblicamente.

    
risposta data 21.11.2016 - 11:18
fonte
0

Dalla tua domanda ho letto che sei d'accordo sul fatto che l'autenticazione del server è importante per assicurarti di connetterti al server giusto. Accetti anche che la resistenza alla manomissione usando un HMAC sia importante. Ma tu chiedi perché abbiamo bisogno della crittografia in tutti i casi, vale a dire anche per i dati disponibili pubblicamente e affermi che a causa di questa crittografia abbiamo deprecato l'uso della compressione (BREACH, CRIME ...) per il traffico TLS.

Innanzitutto, la compressione per i dati trasferiti tramite TLS è deprecata solo se questi dati contengono parti sensibili, come i token CSRF oi cookie di autenticazione. Se tutti i dati sono comunque disponibili pubblicamente, non è necessario disabilitare la compressione perché non c'è nulla da attaccare usando questo canale laterale.

In secondo luogo, la parte più costosa con TLS sia in termini di latenza che in termini di utilizzo della CPU è l'iniziale handshake TLS che include lo scambio di chiavi. La compressione del carico utile in sé non è gratuita ma relativamente economica, soprattutto se si considera che si vuole ancora calcolare HMAC a causa del requisito di resistenza alla manomissione e questo significa che tutto il carico utile deve essere comunque elaborato (solitamente nello spazio utente) e non può direttamente inviato dal disco.
E dato che la crittografia è relativamente economica, si potrebbe sostenere che in questo caso si potrebbe semplicemente crittografare il contenuto anziché utilizzare solo un HMAC perché aggiunge un po 'di privacy alla comunicazione in modo economico. Inoltre, la privacy può essere importante se si accede ai dati pubblici solo perché rende più difficile il monitoraggio e la profilazione del comportamento degli utenti. Non sai mai come verranno utilizzate queste informazioni e se potrebbero essere utilizzate contro di te. Quindi se riesci a nasconderli in un modo facile ed economico dovresti farlo.

    
risposta data 21.11.2016 - 12:07
fonte
0

Si tratta solo del supporto di crittografie crittografate null nei browser.

Nessun browser supporta le crittografie con crittografia nulla per predefinito . In alcuni browser (opera 12) è possibile abilitare i codificatori nulli (sono disponibili, ma disabilitati di default), a quanto pare Firefox ha avuto anche l'opzione di abilitare i codificatori nulli, ma quell'opzione è stata rimossa. ( link ).

    
risposta data 22.11.2016 - 10:26
fonte

Leggi altre domande sui tag