Quali sono i pro e i contro di SSL su tutto il sito (https)?

Poiché la maggior parte delle altre risposte qui trattano gli aspetti negativi del SSL a livello di sito (principalmente problemi di prestazioni - questi possono essere facilmente mitigati scaricando la terminazione SSL, sia in una casella proxy SSL, sia in una scheda SSL), I segnalerà alcuni problemi con la sola pagina di accesso su SSL, quindi passando a non SSL:

• Il resto del sito non è protetto (anche se questo è ovvio, a volte il focus è troppo sulla sola password dell'utente).
• L'ID della sessione dell'utente deve essere trasmesso in chiaro, consentendone l'intercettazione e l'utilizzo, consentendo così ai cattivi di impersonare i tuoi utenti. (Questo è principalmente ciò che era la confusione 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.
• Ho visto siti con accesso solo SSL e, naturalmente, trascurato di includere 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 tuo server web e in molti casi farà apparire un messaggio spaventoso per i tuoi utenti.
• Se è SOLO la pagina di accesso e f.e. c'è un collegamento alla pagina di accesso dalla home page dei siti - cosa garantire che qualcuno non possa spoofare / modificare / intercettare la tua home page e farlo puntare a una pagina di accesso diversa?
• Poi c'è il caso in cui la pagina di login non è SSL, ma solo SUBMIT è - dato che è l'unica volta che viene inviata la password, quindi dovrebbe essere sicuro, giusto? Ma in verità ciò rimuove dall'utente la capacità di assicurare 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" aumenta come un "con" significativo è un mito comune. I tecnici di Google hanno notato che quando si passa a Gmail al 100% SSL non hanno implementato hardware aggiuntivo e che SSL rappresentava meno dell'1% di aumento del carico della CPU e del 2% nel traffico di rete. Stack Overflow ha anche alcune domande relative a questo: Quanto overhead impone SSL? e Prestazioni HTTP contro HTTPS .

Dalla voce del blog zscaler Perché il web ha non è ancora passato a SSL-only?

"With the session-sidejacking issue highlighted once more by Firesheep, a many people have asked me why more websites, or at least the major players (Google, Facebook, Amazon, etc.) have not enabled SSL by default for all communication. Indeed, encryption is the only way to ensure that user sessions cannot be easily sniffed on a open wireless network.

This sounds easy - just add an s after http in the URL! It's not actually that easy. Here are some of the challenges."

Riepilogo delle sfide (contro):

• "server overhead"
• "increased latency"
• "challenge for CDNs"
• "wildcard certificates are not enough"
• "mixed HTTP/HTTPS: the chicken & the egg problem"
• "warnings are scary!"

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

Uno dei più grandi: la maggior parte delle reti pubblicitarie non fornisce alcun modo per pubblicare annunci su SSL. Inoltre, se si incorporano annunci (distribuiti tramite HTTP) in una pagina principale consegnata tramite HTTPS, i browser invieranno avvisi di contenuto misto spaventosi, ai quali non si desidera sottoporre i propri utenti. Pertanto, è probabile che i siti supportati dalla pubblicità trovino molto difficile la transizione verso 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 basso. Tuttavia, ho qualcosa da aggiungere al lato "contro".

Latenza HTTPS:

Avere una bassa latenza HTTP client-to-server è fondamentale per rendere siti web veloci e di rapido caricamento . E i tempi di caricamento rapidi della pagina aumentano la felicità degli utenti finali .

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

Si noti che l'impatto di questo può essere ridotto (ma non eliminato) riutilizzando la connessione HTTPS molte volte, ad esempio usando connessioni persistenti, e altri ottimizzazioni delle prestazioni come l'avvio falso SSL .

Modellare esattamente quanto HTTPS rallenta i carichi di pagina è 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 è mancato nelle altre risposte sopra è il massiccio affidamento in questi giorni sulle reti di distribuzione dei contenuti (ad es. Akamai) - molte pagine Web in uso utilizzano i contenuti di una varietà di domini in modo che il browser debba disporre di certificati per ognuno di questi o avvertimenti apparirebbe. E poi, naturalmente, se l'attaccante ha usato una piattaforma CDN per la quale il browser aveva già dei certificati, potrebbe non ricevere un avviso quando dovrebbe.

Difficile problema con il modo in cui le applicazioni e i contenuti vengono attualmente pubblicati.

I professionisti hanno sicuramente aumentato la sicurezza. I contro potrebbero essere connessioni relativamente più lente, un uso più intenso della CPU, una gestione accurata dei certificati, alcuni costi per il certificato (se non si utilizzano certificati autofirmati). Ma negli ultimi tempi c'è una pratica diffusa nell'uso di https e quei cons si fanno in secondo piano a vantaggio degli utenti finali e maggiore fiducia a una società che fornisce servizi.

Altre risposte hanno asserito un "problema pollo / uovo" a causa di avvertimenti con contenuto misto che rendono difficile la migrazione HTTP- > HTTPS. È un problema, ma non credo sia difficile come lo rendono.

I contenuti misti possono essere indirizzati usando URL relativi al protocollo e gli stessi scanner che dovresti utilizzare per trovare i problemi XSS.

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

A relative reference that begins with two slash characters is termed a network-path reference

Esegui prima la scansione delle tue pagine finché non trovi tutti gli usi di http://example.com/ nei link di origine originaria, nelle immagini e in altre risorse del sito e li sostituisci con URL relativi al protocollo ( //example.com/... ). Ciò ti consente di pubblicare lo stesso codice HTML indipendentemente dal fatto che tu stia servendo una pagina tramite HTTP o HTTPS e ti mette in una posizione migliore per il rollback se qualcosa dovesse andare storto in seguito nella tua migrazione.

Quindi imposta reindirizzamenti permanenti HTTP- > HTTPS in modo che gli URL esistenti su siti esterni al tuo controllo continuino a funzionare e inizino a essere pubblicati tramite HTTPS. L'utilizzo di un reindirizzamento permanente con headers di cache aggressivi aiuterà i motori di ricerca a trasferire il page rank e ad accelerare il sito per i visitatori di ritorno.

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

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

SPDY

L'uso di mod_spdy su Apache richiede SSL.

Non hai ancora distribuito SPDY, fallo! Sia Chrome che Firefox supportano il protocollo, oltre a Opera.

È circa la metà dei tuoi utenti che potranno usufruire di SPDY.

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

Tutto il buon punto menzionato qui, tuttavia, ho sbagliato il costo della truffa! 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.

I vantaggi di mantenere l'intero sito crittografato:

• non farai incazzare i visitatori interessati alla privacy inviandoli in chiaro dopo l'accesso.
• minor rischio di errori durante il reindirizzamento / collegamento tra le parti http e https del sito.

Il con:?

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 pagine, potrebbe modificare l'HTML per includere riferimenti a risorse esterne al sito, ad esempio immagini, su HTTP. Ho creato un sito di acquisti che utilizza SSL solo laddove necessario e reindirizza le altre pagine su HTTP, perché altrimenti riceverai avvisi di contenuti misti a causa di tutte le immagini esterne del sito che il proprietario ha bloccato nel sito.