Domanda:
Quali sono i pro e i contro dell'SSL a livello di sito (https)?
Olivier Lalonde
2010-11-13 04:32:57 UTC
view on stackexchange narkive permalink

Quali sono i pro e i contro della crittografia di tutto il traffico HTTP per l'intero sito tramite SSL, rispetto a SSL solo nella pagina di accesso?

Tredici risposte:
#1
+61
AviD
2010-11-18 22:59:55 UTC
view on stackexchange narkive permalink

Poiché la maggior parte delle altre risposte qui si occupano degli aspetti negativi dell'SSL a livello di sito (principalmente problemi di prestazioni - btw questi possono essere facilmente mitigati scaricando la terminazione SSL, su una casella proxy SSL o su una scheda SSL), io evidenzierà alcuni problemi con avere solo la pagina di accesso su SSL, quindi passare a non SSL:

  • Il resto del sito non è protetto (sebbene questo sia ovvio, a volte anche il focus è molto solo sulla password dell'utente).
  • L'ID di sessione dell'utente deve essere trasmesso in chiaro, consentendo di essere intercettato e utilizzato, consentendo così ai malintenzionati di impersonare i propri utenti. (Questo è principalmente ciò di cui parlava Firesheep).
  • A causa del punto precedente, i cookie di sessione non possono essere contrassegnati con l'attributo secure , il che significa che possono essere recuperati in altri modi.
  • I hanno visto siti con SSL di solo accesso e, naturalmente, trascurano di includere in tale pagina la pagina Password dimenticata, la pagina Modifica password e persino la pagina Registrazione ...
  • Il passaggio da SSL a non SSL è spesso complicato, può richiedere una configurazione complessa sul tuo server web e in molti casi farà apparire un messaggio spaventoso per i tuoi utenti.
  • Se è SOLO la pagina di accesso, e fe c'è un collegamento alla pagina di accesso dalla home page dei tuoi siti: cosa garantisce che qualcuno non falsifichi / modifichi / intercetti la tua home page e faccia riferimento a una pagina di accesso diversa?
  • Poi c'è è il caso in cui la pagina di accesso stessa non è SSL, ma solo INVIA è - poiché è l'unica volta che viene inviata la password, quindi dovrebbe essere sicuro, giusto? Ma in verità ciò toglie all'utente la possibilità di assicurarsi in anticipo che la password venga inviata al sito corretto, fino a quando non sarà troppo tardi. (Ad esempio Bank of America e molti altri).
Per maggiori informazioni su firesheep vedi [Ep. 272 di Security Now!] (Http://media.GRC.com/sn/SN-272.mp3) per l'episodio in cui approfondiscono il tema del firesheep (iniziano a parlarne alle 44:05).
#2
+47
user502
2011-01-14 20:58:58 UTC
view on stackexchange narkive permalink

Il "sovraccarico del server" che aumenta come un significativo "con" è un mito comune. Gli ingegneri di Google hanno notato che, passando da Gmail a SSL al 100%, non utilizzavano hardware aggiuntivo e che SSL rappresentava un aumento inferiore dell'1% del carico della CPU e del 2% del traffico di rete. Stack Overflow ha anche alcune domande su questo argomento: quanto overhead impone SSL? e prestazioni HTTP rispetto a HTTPS.

Non tanto un mito quanto informazioni obsolete: nei tempi antichi, quando i dinosauri vagavano per la Terra (cioè alla fine degli anni '90), i computer erano molto più lenti di oggi, e quindi una percentuale molto maggiore del tempo della CPU sarebbe stata data a SSL, anche rendendo il server vincolato alla CPU. I server moderni sono generalmente associati al database o al disco, per non parlare delle CPU più potenti, in modo che SSL * non sia più * un significativo maiale alla CPU.
Inoltre, @Piskvor, gli algoritmi che abbiamo ora sono molto più veloci, 3DES è 5 volte più lento di AES-128, anche prima di utilizzare AES-NI (accelerazione hardware) e quasi 25 volte più lento di AES-128 con AES-NI!
Non sei [Google] (http://security.stackexchange.com/a/4376/2379). ** Ancora ** un sovraccarico: https://www.httpvshttps.com/
@Pacerier, secondo quel test (con un singolo punto dati, attenzione), http è ~ 1% più veloce di https.Sembra essere in linea con la risposta, no?
@Pacerier E ora il sito dice che http è il 2655% _slow_ di HTTPS (molto probabilmente a causa dei vantaggi di HTTP / 2, che è supportato solo su HTTPS).
#3
+25
Tate Hansen
2010-11-17 14:39:50 UTC
view on stackexchange narkive permalink

Dalla voce del blog di zscaler Perché il Web non è ancora passato a solo SSL?

"Con il problema del sidejacking della sessione evidenziato ancora una volta da Firesheep, molte persone mi hanno chiesto perché più siti Web, o almeno i principali attori (Google, Facebook, Amazon, ecc.) Non hanno abilitato SSL per impostazione predefinita per tutte le comunicazioni. In effetti, la crittografia è l'unico modo per garantire che le sessioni utente non possano essere sniffato facilmente su una rete wireless aperta.

Sembra facile: basta aggiungere una s dopo http nell'URL! In realtà non è così facile. Ecco alcune delle sfide. "

Riepilogo delle sfide (contro):

  • "sovraccarico del server"
  • "aumento della latenza"
  • "sfida per CDN "
  • " i certificati jolly non sono sufficienti "
  • " HTTP / HTTPS misto: il pollo & il problema dell'uovo "
  • " gli avvisi fanno paura! "
Inoltre offre agli utenti un falso senso di sicurezza: "beh, l'intero sito utilizza SSL, quindi deve essere sicuro!"
@Steve +1, crittografia garantita SSL. In genere la crittografia viene negoziata, ma tecnicamente non è richiesta; una sessione SSL può essere negoziata solo con autenticazione.
Non del tutto vero. Richiede un indirizzo IP univoco per certificato. Ma puoi avere un certificato multidominio. Non necessariamente sensato o pratico, ma fattibile!
@SteveS: Cosa, come chiudere la porta di casa, ti dà un falso senso di sicurezza? Sicuramente non è un buon motivo per non farlo, è un motivo per istruire meglio gli utenti.
#4
+19
D.W.
2011-03-27 11:29:17 UTC
view on stackexchange narkive permalink

Ars Technica ha un eccellente articolo che spiega alcune delle sfide nell'implementazione di SSL in tutto il sito.

Una grande: la maggior parte delle reti pubblicitarie non fornisce alcun modo per offrire annunci su SSL . Inoltre, se incorpori annunci (forniti su HTTP) in una pagina principale che viene consegnata su HTTPS, i browser emetteranno spaventosi avvisi di contenuto misto, a cui non vuoi sottoporre i tuoi utenti. Pertanto, i siti supportati da pubblicità probabilmente troveranno molto difficile la transizione a SSL a livello di sito.

L'articolo delinea anche alcune altre sfide, come widget di terze parti, analisi, video incorporati, ecc.

Mi spiace, non posso modificare il tuo post per meno di 6 caratteri, hai fatto un errore di battitura qui: "consegnato su HTTP" dove intendevi "consegnato su HTTPS"
#5
+15
Jesper M
2011-07-17 03:04:00 UTC
view on stackexchange narkive permalink

OK, questa è una domanda antica, quindi la mia risposta probabilmente languirà qui in fondo. Tuttavia, ho qualcosa da aggiungere al lato "contro".

Latenza HTTPS:

Avere una bassa latenza HTTP client-server è fondamentale per creare siti Web reattivi e a caricamento rapido. E tempi di caricamento rapidi delle pagine aumentano la soddisfazione dell'utente finale.

Solo TCP / IP ha il famoso handshake TCP a 3 vie, ovvero la configurazione iniziale della connessione per HTTP semplice su TCP richiede 3 pacchetti . Quando viene utilizzato SSL / TLS, la configurazione della connessione è più complessa, il che significa che la latenza per le nuove connessioni HTTPS è inevitabilmente maggiore rispetto a HTTP in chiaro.

Tieni presente che l'impatto di ciò può essere ridotta (ma non eliminata) riutilizzando più volte la connessione HTTPS, ovvero utilizzando connessioni persistenti e altre ottimizzazioni delle prestazioni come SSL False Start.

Modellando esattamente quanto HTTPS rallenta il caricamento delle pagine è complicato, perché tutti i browser moderni scaricano oggetti HTTP in parallelo quando possibile. Anche così, il tempo di configurazione della connessione iniziale più elevato è sia significativo che inevitabile con la tecnologia attuale; quindi la maggiore latenza della nuova connessione è una considerazione importante.

La [bozza di TLS 1.3] (https://tools.ietf.org/html/draft-ietf-tls-tls13) ottiene l'handshake verso 1-RTT e 0-RTT con la ripresa della sessione. [La ripresa ha degli svantaggi] (https://www.imperialviolet.org/2013/06/27/botchingpfs.html): se i ticket vengono conservati per più di qualche ora si perde PFS.
#6
+12
Rory Alsop
2010-12-03 01:24:57 UTC
view on stackexchange narkive permalink

Uno svantaggio che si perde nelle altre risposte sopra è l'enorme dipendenza in questi giorni dalle reti di distribuzione di contenuti (ad es. Akamai): molte pagine web nell'uso corrente acquisiscono contenuti da una varietà di domini, quindi il browser dovrebbe avere certificati ognuno di questi o avvisi verranno visualizzati. E poi, naturalmente, se l'aggressore utilizzava una piattaforma CDN per la quale il browser disponeva già di certificati, potrebbe non ricevere un avviso quando dovrebbe.

Problema complicato con il modo in cui le applicazioni e i contenuti vengono attualmente forniti.

Non capisco l'affermazione secondo cui gli utenti devono disporre di certificati. Il modo in cui funziona SSL è che il server deve avere un certificato; il client non ha bisogno di avere un certificato (il server invia il suo certificato al client per la convalida). I browser Web hanno già tutto ciò di cui hanno bisogno (in particolare, contengono un elenco di certificati root attendibili). Potrebbe aiutare a spiegare / elaborare ciò che avevi in ​​mente.
@D.W. L'utente deve accettare i certificati dal server. Questo processo di accettazione è il problema qui. La maggior parte degli utenti non sono tecnici, quindi non capiscono cosa stanno accettando. Avere una formulazione aggiornata per chiarire.
Solo se provi a creare il tuo certificato e non proviene da una fonte convalidata ... So che è vecchio ma sono solo informazioni sbagliate.
Non capisco davvero perché questo sia un problema. Quale CDN serio non avrebbe un certificato SSL considerato attendibile da tutti i principali browser?
#7
+7
anonymous
2010-11-13 04:47:01 UTC
view on stackexchange narkive permalink

Il vantaggio è sicuramente una maggiore sicurezza. Gli svantaggi potrebbero essere connessioni relativamente più lente, un utilizzo più intenso della CPU, una gestione accurata dei certificati richiesta, alcuni costi per il certificato (se non si utilizzano certificati autofirmati). Ma negli ultimi tempi si sta diffondendo la pratica di utilizzare https e questi svantaggi vengono in secondo piano a causa del vantaggio per gli utenti finali e di una maggiore fiducia verso un'azienda che fornisce servizi.

#8
+5
Mike Samuel
2011-10-26 19:42:12 UTC
view on stackexchange narkive permalink

Altre risposte hanno affermato un "problema di gallina / uovo" a causa di avvisi di contenuto misto che rendono difficile la migrazione HTTP-> HTTPS. È un problema, ma non credo sia così difficile come sembra.

Il contenuto misto può essere affrontato utilizzando URL relativi al protocollo e lo stesso scanner che dovresti utilizzare per trovare problemi XSS.

RFC 3986 sezione 4.2 utilizza il termine riferimento percorso di rete:

Un riferimento relativo che inizia con due caratteri barra viene definito un riferimento al percorso di rete

Prima scansiona le tue pagine finché non trovi tutti gli usi di http://example.com/ in link, immagini e altre risorse del sito della stessa origine e sostituirli con URL relativi al protocollo ( //example.com / ... ). Ciò ti consente di avere lo stesso HTML servito indipendentemente dal fatto che tu stia servendo una pagina tramite HTTP o HTTPS e ti mette in una posizione molto migliore per eseguire il rollback se qualcosa va storto in seguito nella migrazione.

Quindi imposta permanente HTTP-> HTTPS reindirizza in modo che gli URL esistenti su siti al di fuori del tuo controllo continuino a funzionare e inizino a servire tramite HTTPS. L'utilizzo di un reindirizzamento permanente con intestazioni cache aggressive aiuterà i motori di ricerca a trasferire il page-rank e ad accelerare il sito per i visitatori di ritorno.

Ovviamente dovresti mantenere i tuoi scanner alla ricerca di contenuti misti in modo da rilevare le regressioni.

#9
+4
Spock
2013-06-17 02:41:29 UTC
view on stackexchange narkive permalink

So che questa è una vecchia domanda / thread, ma volevo solo segnalare un enorme PRO per fare SSL side-side.

SPDY

L'utilizzo di mod_spdy su Apache richiede SSL.

Se non hai ancora distribuito SPDY, fallo! Sia Chrome che Firefox supportano il protocollo, così come Opera.

Si tratta di circa la metà dei tuoi utenti che potranno trarre vantaggio da SPDY.

Puoi spiegare in modo più esplicito quali sono i vantaggi visibili all'utente finale dell'utilizzo di SPDY o le ragioni più convincenti per cui gli operatori del sito supportano SPDY? Inoltre, perché il supporto per SPDY richiede di attivare SSL per l'intero sito, invece di solo una parte del sito?
@D.W. Non richiede di attivare SSL (non sono sicuro del motivo per cui Spock ha detto che lo fa.) Ma i vantaggi per l'utente finale sono un sito web che si carica più velocemente. I test mostrano che ci sono miglioramenti significativi delle prestazioni. La pagina del progetto chromium afferma che il 27% -60% più veloce del semplice tcp e il 39% -55% più veloce di SSL / TLS quando testato contro 25 dei primi 100 siti su Internet.
@Jared: Anche nel 2014 SPDY non aveva modo di negoziare da HTTP / 1.1 diverso da SSL Next-Protocol-Notification, e non c'era implementazione che offrisse una soluzione alternativa.Nel 2016, SPDY è deprecato a favore di HTTP / 2.Una descrizione dei vantaggi sarebbe stata utile qui: SSL / TLS aggiunge un minimo di 1 RTT extra per connessione (più tipicamente 2) che ha un enorme impatto su un sito lontano dai suoi utenti.I confronti con HTTP su TCP vanilla e SSL / TLS sono in qualche modo privi di significato in relazione alla domanda posta poiché la maggior parte di questi vantaggi derivano dal multiplexing.
So che questa è una vecchia domanda / thread, ma volevo solo sottolineare che SPDY è deprecato, non supportato e non viene utilizzato già da molto tempo.
#10
+3
Nev Stokes
2010-11-14 06:18:16 UTC
view on stackexchange narkive permalink

Un altro aspetto negativo (toccato da altri) è la mancanza di cache che ovviamente influirà sulla velocità. Inoltre, alcune variabili del server non sono disponibili, come HTTP_FORWARDED_FOR credo.

È possibile memorizzare nella cache su HTTPS. Alcune versioni di Firefox richiedono solo l'intestazione di risposta "Cache control: public".
@realworldcoder: I browser più recenti generalmente memorizzano nella cache il contenuto HTTPS quando vengono fornite le intestazioni Cache-Control appropriate. Ma tutti i browser meno recenti e molte o la maggior parte delle cache * pubbliche * implementate oggi non memorizzeranno nella cache il contenuto SSL.
La maggior parte dei CDN memorizzerà nella cache il contenuto HTTPS se configurato con un certificato del server (che è forse una considerazione in termini di esposizione del certificato).Le intestazioni HTTP opzionali sono in qualche modo irrilevanti.
#11
+3
Henri
2011-01-15 18:26:25 UTC
view on stackexchange narkive permalink

Tutto bene menzionato qui, tuttavia, ho sbagliato il costo! E per costo non intendo solo acquistare il certificato, ma avere l'infrastruttura adeguata per gestire certificati, revoche, moduli crittografici dedicati per diminuire il carico della CPU del server web, ecc.

"Acquisto del certificato": $ 25 / anno / certificato da GoDaddy. "Infrastruttura adeguata": CRL di GoDaddy. Moduli crittografici dedicati per ridurre il carico della CPU del server web ": basta procurarsi un secondo server web e servire davvero bene i clienti - con la privacy a livello di trasporto.
#12
+3
MattBianco
2011-03-28 19:19:46 UTC
view on stackexchange narkive permalink

Vantaggi di mantenere l'intero sito criptato:

  • non farai incazzare i tuoi visitatori interessati alla privacy inviando loro testo in chiaro dopo l'accesso.
  • meno rischi di errori durante il reindirizzamento / collegamento tra le parti http e https del sito.

Lo svantaggio:?

Leggi le testimonianze di Google e altri. Non deve essere costoso passare al 100% https.

#13
+2
TRiG
2013-11-10 04:52:34 UTC
view on stackexchange narkive permalink

Se un sito Web è gestito da un CMS che un utente non tecnico può utilizzare per modificare le pagine, potrebbe modificare l'HTML per includere riferimenti a risorse esterne al sito, come immagini, su HTTP. Ho creato un sito di shopping che utilizza SSL solo dove necessario e reindirizza altre pagine a HTTP, perché altrimenti riceveresti avvisi di contenuto misto a causa di tutte le immagini fuori sito che il proprietario ha bloccato nel sito. >



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...