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).

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.

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! "

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. >