Quali sono i vantaggi e gli svantaggi di SSL a livello di sito (https)?

Poiché la maggior parte delle altre risposte qui affronta gli aspetti negativi di SSL a livello di sito (principalmente problemi di prestazioni - tra l'altro questi possono essere facilmente mitigati scaricando la terminazione SSL, su una casella proxy SSL o una scheda SSL), sottolineo alcuni problemi con avere solo la pagina di accesso su SSL, quindi passare a non SSL:

• Il resto del sito non è protetto (anche se questo è ovvio, a volte l'attenzione è troppo focalizzata solo sulla password dell'utente).
• L'ID di sessione dell'utente deve essere trasmesso in chiaro, consentendogli di essere intercettato e utilizzato e quindi consentire ai cattivi di impersonare i tuoi utenti. (Questo è principalmente ciò di cui parlava Firesheep hubbub).
• A causa del punto precedente, i cookie della sessione non possono essere contrassegnati con l'attributo secure, il che significa che possono essere recuperati in modi aggiuntivi.
• Ho visto siti con SSL di solo accesso, e ovviamente trascuro di includere in quella la pagina Password dimenticata, la pagina Cambia password e persino la pagina Registrazione ...
• Il passaggio da SSL a non SSL è spesso complicato, può richiedere una configurazione complessa sul server Web e in molti casi viene visualizzato un messaggio spaventoso per i tuoi utenti.
• Se è SOLO la pagina di accesso, ad es. esiste un collegamento alla pagina di accesso dalla home page del tuo sito: che cosa garantisce che qualcuno non falsificherà/modificherà/intercetterà la tua home page e la farà puntare a un'altra pagina di accesso?
• Quindi c'è il caso in cui la stessa pagina di accesso non è SSL, ma solo il [~ # ~] submit [~ # ~] è - poiché quello è l'unica volta che viene inviata la password, quindi dovrebbe essere sicuro, giusto? Ma in verità ciò toglie all'utente la possibilità di garantire in anticipo che la password venga inviata al sito corretto, fino a quando non è troppo tardi. (Ad esempio Bank of America, e molti altri).

Il "sovraccarico del server" in aumento come significativo "truffatore" è un mito comune. Ingegneri di Google notato che quando si passa da Gmail al 100% SSL non hanno distribuito hardware aggiuntivo e che SSL ha rappresentato un aumento inferiore all'1% del carico della CPU e del 2% nel traffico di rete. Stack Overflow ha anche alcune domande su questo: Quanto overhead impone SSL? e prestazioni HTTP vs. HTTPS .

Dal post sul blog di zscaler Perché il web non è ancora passato solo a SSL?

"Con il problema del sidejacking della sessione messo in evidenza ancora una volta da Firesheep, molte persone mi hanno chiesto perché più siti Web, o almeno i principali player (Google, Facebook, Amazon, ecc.) Non abbiano abilitato SSL per impostazione predefinita per tutte le comunicazioni. , la crittografia è l'unico modo per garantire che le sessioni utente non possano essere facilmente sniffate 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):

• "overhead del server"
• "latenza aumentata"
• "sfida per i CDN"
• "i certificati jolly non sono sufficienti"
• "Misto HTTP/HTTPS: il problema pollo e uovo"
• "gli avvertimenti fanno paura!"

Ars Technica ha n eccellente articolo che spiega alcune delle sfide nella distribuzione di SSL in tutto il sito.

Uno grande: la maggior parte delle reti pubblicitarie non fornisce alcun modo per pubblicare annunci su SSL. Inoltre, se incorpori annunci (consegnati su HTTP) in una pagina principale che viene fornita su HTTPS, i browser emetteranno avvisi di contenuto misto spaventosi, a cui non desideri sottoporre i tuoi utenti. Pertanto, i siti supportati da pubblicità probabilmente troveranno molto difficile passare a SSL in tutto il sito.

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

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 da client a server è fondamentale per creare siti Web responsive a caricamento rapido . E i tempi di caricamento rapidi della pagina aumentano la felicità dell'utente finale .

TCP/IP da solo ha il famoso TCP handshake a 3 vie, ovvero la configurazione iniziale della connessione per HTTP semplice su TCP richiede 3 pacchetti. Quando SSL/TLS è utilizzato, la configurazione della connessione è più complessa, ovvero la latenza per le nuove connessioni HTTPS è inevitabilmente superiore rispetto al semplice testo HTTP.

Si noti che l'impatto di questo può essere ridotto (ma non eliminato) riutilizzando più volte la connessione HTTPS, ovvero utilizzando connessioni persistenti e altri ottimizzazioni delle prestazioni come SSL False Start .

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

Un aspetto negativo che manca nelle altre risposte sopra è l'enorme dipendenza di questi tempi sulle reti di distribuzione dei contenuti (ad es. Akamai) - molte pagine Web nell'uso corrente catturano contenuti da una varietà di domini, quindi il browser dovrebbe avere certs per ciascuno di questi o verranno visualizzati degli avvisi. E poi, naturalmente, se l'attaccante utilizzava una piattaforma CDN per la quale il browser aveva già i certificati, potrebbe non ricevere un avviso quando dovrebbe.

Problema problematico con il modo in cui le applicazioni e il contenuto vengono attualmente distribuiti.

Pro è sicuramente maggiore sicurezza. Contro potrebbero essere connessioni relativamente più lente, un uso 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 esiste una pratica diffusa di utilizzare https e questi svantaggi vengono alla luce dei benefici per gli utenti finali e della maggiore fiducia nei confronti di un'azienda che fornisce servizi.

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

Il contenuto misto può essere indirizzato usando RL relativi al protocollo e gli stessi scanner che dovresti usare per trovare problemi XSS.

RFC 3986 sezione 4.2 usa il termine riferimento al percorso di rete:

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

Prima scansiona le tue pagine fino a trovare tutti gli usi di http://example.com/ nei link, le immagini e le risorse di altri siti dello stesso Origin e sostituirli con URL relativi al protocollo (//example.com/...). Ciò ti consente di avere lo stesso HTML offerto indipendentemente dal fatto che tu stia offrendo una pagina tramite HTTP o HTTPS e ti mette in una posizione molto migliore per il rollback se qualcosa va storto in seguito nella tua migrazione.

Quindi imposta i reindirizzamenti HTTP-> HTTPS permanenti in modo che gli URL esistenti sui siti al di fuori del tuo controllo continuino a funzionare e inizino a essere pubblicati tramite HTTPS. L'uso di un reindirizzamento permanente con intestazioni cache aggressive aiuterà i motori di ricerca a trasferire il ranking delle pagine e ad accelerare il sito per i visitatori di ritorno.

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

So che questa è una vecchia domanda/discussione, ma volevo solo sottolineare un grande PRO per fare SSL laterale.

SPDY

L'uso di mod_spdy su Apache richiede SSL.

Non hai ancora distribuito SPDY, fallo! Sia Chrome e Firefox supportano il protocollo, sia Opera.

Questa è circa la metà dei tuoi utenti che potranno sfruttare SPDY.

Altri aspetti negativi (toccati da altri) è la mancanza di memorizzazione nella cache che influirà ovviamente sulla velocità. Inoltre, alcune variabili del server non sono disponibili - come HTTP_FORWARDED_FOR credo.

Tutti i punti positivi menzionati qui, tuttavia, mi dispiace il costo di con! E per costo non intendo solo acquistare il certificato, ma avere l'infrastruttura adeguata per gestire certificati, revoche, moduli crittografici dedicati per ridurre il carico della CPU del server web, ecc.

Vantaggi della crittografia dell'intero sito:

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

Il truffatore:?

Leggi le testimonianze di google e altri. Non deve essere costoso andare al 100% https.

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 le altre pagine a HTTP, perché altrimenti otterrai avvisi di contenuto misto a causa di tutte le immagini off-site che il proprietario ha inserito nel sito.