Puoi usare gzip su SSL? E connessione: intestazioni Keep-Alive

Question

Sto valutando le prestazioni front-end di un'app Web protetta (SSL) qui al lavoro e mi chiedo se è possibile comprimere i file di testo (html/css/javascript) su SSL. Ho fatto qualche ricerca su google, ma non ho trovato nulla specificamente correlato a SSL. Se è possibile, vale anche i cicli extra della CPU poiché le risposte vengono anche crittografate? La compressione delle risposte danneggerebbe le prestazioni?

Inoltre, volevo essere sicuro che mantenessimo la connessione SSL attiva, quindi non stiamo facendo ripetutamente strette di mano SSL. Non vedo Connessione: Keep-Alive nella risposta intestazioni. Vedo Keep-Alive: 115 nelle intestazioni richieste ma questa è solo mantenendo la connessione attiva per 115 millisecondi (sembra che l'app server stia chiudendo la connessione dopo che una singola richiesta è stata elaborata?) Non vorresti che il server impostare l'intestazione per l'intestazione finché il timeout di inattività della sessione è?

Capisco che i browser non memorizzino il contenuto SSL su disco in modo tale da servire gli stessi file più e più volte nelle visite successive anche se nulla è cambiato. I principali suggerimenti di ottimizzazione stanno riducendo il numero di richieste HTTP, minificazione, spostamento degli script verso il basso, ottimizzazione delle immagini, possibile segmentazione del dominio (anche se occorre pesare il costo di un altro handshake SSL), cose di questo tipo.

Answer 1

Alla prima domanda: SSL sta lavorando su un livello diverso dalla compressione. In un certo senso, queste due sono le caratteristiche di un server web che può funzionare insieme e non sovrapporsi. Sì, abilitando la compressione userai più CPU sul tuo server ma avrai meno traffico in uscita. Quindi è più di un compromesso.

Alla tua seconda domanda: il comportamento Keep-Alive dipende in realtà dalla versione HTTP. È possibile spostare il contenuto statico su un server non SSL (può includere immagini, filmati, audio, ecc.)

Answer 2

Sì, è possibile utilizzare la compressione gzip e Keep-alive con HTTPS/SSL. Inoltre, i browser possono memorizzare nella cache il contenuto SSL.

Questo post del blog ha più informazioni su ottimizzazione di un sito web per HTTPS/SSL:

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

Answer 3

Sì, la compressione può essere utilizzato su SSL; ha luogo prima che i dati siano crittografati, quindi può aiutare su collegamenti lenti. Va notato che questa è una pessima idea : this also opens a vulnerability.

Dopo l'iniziale stretta di mano, SSL è meno di un sovraccarico di quanto molti pensino *, anche se il client si riconnette, c'è un meccanismo per continuare le sessioni esistenti senza rinegoziare le chiavi, con un minor utilizzo della CPU e un numero inferiore di round-trip.

I bilanciatori di carico possono avvitare con il meccanismo di continuazione, tuttavia: se le richieste si alternano tra i server, sono necessarie più strette di mano che possono avere un impatto notevole (~ poche centinaia di ms per richiesta). Configurare il servizio di bilanciamento del carico per inoltrare tutte le richieste dallo stesso IP allo stesso server delle applicazioni.

Quale server di applicazioni stai utilizzando? Se non può essere configurato per usare keep-alive, comprimere i file e così via, considera di metterlo dietro un proxy inverso che può (e mentre ci sei, rilassare le intestazioni della cache inviate con contenuto statico - HttpWatchSupport collegato l'articolo ha alcuni suggerimenti utili su quel fronte).

(* fornitori di hardware SSL diranno cose come "fino a 5 volte più CPU", ma alcuni chaps from Google riferito che quando Gmail è andato a SSL per impostazione predefinita, essa ha rappresentato solo per il carico della CPU ~ 1%)

Answer 4

Utilizzando la compressione con SSL ti apre vulnerabilità come BREAK, CRIME o altri attacchi di testo normale scelti.

È necessario disabilitare la compressione poiché SSL/TLS non ha modo di mitigare al momento questi attacchi oracle di lunghezza.

Answer 5

1. Probabilmente non si dovrebbe mai usare la compressione TLS. Alcuni programmi utente (almeno Chrome) lo disabiliteranno comunque.

2. È possibile utilizzare selettivamente la compressione HTTP

3. È sempre possibile minify

4. Parliamo di caching troppo

che sto per assumere si utilizza un HTTPS Everywhere stile web luogo.

Scenario:

1. contenuto statico come css o js:

   • Usa compressione HTTP
   • Usa minification
   • Lungo periodo di cache (come un anno)
   • ETAG è solo marginalmente utile (a causa della lunga cache)
   • Includere una sorta di numero di versione nel URL nel codice HTML che punta a questa risorsa in modo da poter memorizzare nella cache-busto

2. contenuti HTML con ZERO informazioni sensibili (come una pagina Chi siamo):

   • utilizzare la compressione HTTP
   • Usa minification
   • usare un breve periodo di cache
   • Usa etag
contenuti

3. HTML con qualsiasi info sensibili (come un numero di token o conto bancario CSRF):

   • nessuna compressione HTTP
   • Usa minification
   • Cache-Control: no-store, must-revalidate
   • ETAG è inutile qui (a causa di riconvalida)
   • Refresh: ${seconds until session expires + small buffer}

Quanto sopra aggiornerà la pagina subito dopo la scadenza della sessione, che "disconnetterà" l'utente, mostrando la schermata di accesso. Se qualcuno preme il pulsante Indietro del browser, le informazioni sensibili non vengono visualizzate a causa dell'intestazione della cache.

È possibile utilizzare la compressione HTTP con dati sensibili IF:

1. Non si può mai tornare l'input dell'utente nella risposta (ottenuto una casella di ricerca non utilizzare la compressione HTTP?)
2. O lo fai ritornare l'input dell'utente nella risposta ma in modo casuale la risposta