Non sono d'accordo con la risposta di @valentinas. C'è una perdita di prestazioni con TLS. Se è rilevante per te dipende dal tuo sito:

• Per stabilire la connessione devi prima avere l'handshake TCP tra client e server sia per HTTP che per HTTPS, che richiede un round trip completo tra client e server.
• Per HTTPS hai anche l'handshake TLS che necessita di due round trip durante la creazione della sessione iniziale (solo uno se TLS false start è supportato) e un round trip se puoi riprendere una sessione.
• Sebbene la crittografia simmetrica utilizzata all'interno della sessione TLS sia economica, lo scambio di chiavi iniziale non lo è. Se lo fai bene, vuoi utilizzare la segretezza di inoltro, che significa DHE o ECDHE. Simple DHE è molto costoso da configurare, ECDHE è molto più economico ma non tutti i client lo supportano. Vedi http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html per i benchmark.

Queste cose combinate rendono le connessioni TLS più costose da configurare e quindi introduce un notevole calo delle prestazioni con connessioni brevi. Più hardware non aiuterà molto, perché il problema principale sono gli scambi aggiuntivi tra i peer, dove devono aspettare l'un l'altro per continuare.

Con connessioni lunghe questo sovraccarico non ha più molta importanza, quindi se usi keep-alive (la maggior parte dei client e dei server lo fa) e hai solo poche connessioni probabilmente starai bene. Ma poche connessioni significano che non dovresti includere reti pubblicitarie, perché spesso reindirizzano tra più host fino a raggiungere quello che finalmente serve l'annuncio. I siti che dipendono fortemente dalla pubblicità sono già rallentati da questo (round trip iniziale per TCP) ma saranno più lenti se passano a HTTPS, a causa di altri due round trip necessari per stabilire la sessione TLS a ciascuno dei server nel catena di annunci.

Un motivo che non ho ancora visto menzionato è che, per quanto arcaico possa sembrare, alcuni client potrebbero non supportare TLS / SSL. Questo è un caso specifico, di sicuro, e di solito coinvolge sistemi incorporati o legacy, ma sfortunatamente alcuni esistono ancora.

Il primo esempio che viene in mente è un microcontrollore personalizzato che stavamo utilizzando, dove ci siamo " d sottovalutato la quantità di spazio di cui avremmo avuto bisogno e non saremmo stati in grado di includere la dimensione di una libreria SSL. Alla fine abbiamo dovuto interromperlo e comunicare tramite HTTP standard, ed eravamo piuttosto grati che il server da cui doveva estrarre i dati offrisse entrambi i metodi.

Ci siamo imbattuti anche in un sistema legacy alcuni anni fa che ha impedito l'uso di TLS / SSL. Un progetto per il quale è stato assunto un mio amico prevedeva la creazione di un server web remoto e un client automatizzato presso un'università. Lo script client era in esecuzione in un ambiente antiquato e fortemente sandbox all'università: ogni parte della compilazione era gestita da un sistema automatizzato e l'insieme di librerie a cui era possibile accedere era un elenco codificato.

Sono queste abbastanza comune da garantire di evitare TLS / SSL in casi normali? Direi di no, ma ci sono momenti in cui possono essere importanti. Se stai scrivendo software principalmente inteso a comunicare con sistemi incorporati, ci penserei due volte prima di offrire solo TLS / SSL.

Un'altra nota su questo, poiché non lo vedo specificato nella tua domanda, è che tutti sembrano aver fatto il salto per suggerire che quando hai chiesto di TLS / SSL intendevi solo HTTPS. Dal momento che accenni alle comunicazioni TCP, potresti anche prendere in considerazione l'uso di TLS / SSL per altre applicazioni che girano su di esso oltre a HTTPS.

Ciò che viene in mente è TLS / SSL utilizzato da SMTP. Quando si tratta di utilizzare TLS / SSL per le comunicazioni SMTP, personalmente non ci farei mai affidamento come metodo di sicurezza gestibile (nota, intendo comunicazioni SMTP, non l'uso di TLS / SSL per fornire sicurezza tra un client di posta e la posta server). Il motivo per cui dico questo è la natura intrinseca di TLS / SSL. Stai cercando una connessione socket sicura punto a punto adattata per un meccanismo di comunicazione a salti multipli.

Quindi, anche se forzi l'uso di TLS / SSL per le tue connessioni SMTP, puoi solo verificare che la connessione fosse sicura un salto dal tuo server. Poiché la maggior parte dei flussi di posta ha più passaggi come questo:

server di posta -> Soluzione AV -> Internet -> Soluzione AV -> Server di posta

E l'uso di soluzioni AV di terze parti nel cloud sta diventando sempre più importante, è difficile garantire che TLS venga utilizzato per ogni hop tra due organizzazioni.

Per amor di discussione (come ho fatto io) diciamo che ti prendi il tempo per garantire che il traffico SMTP tra due siti verificando che ogni salto tra i siti imponga TLS. Per oggi va tutto bene, ma cosa succede quando l'infrastruttura cambia tra 5 anni? Se non stai attento, ad esempio, quando la soluzione AV viene modificata / sostituita, potresti facilmente lasciare un salto senza forzare TLS.

Volevo solo lanciarlo come un'altra implementazione TLS per il brainstorming (e BTW se richiedesse un'e-mail sicura, avrei seguito il percorso S / Mime per crittografare effettivamente il messaggio sul lato mittente e decrittografare sul destinatario lato). Come con qualsiasi strumento, devi utilizzare lo strumento giusto per il lavoro giusto

"Se l'unico strumento che hai è un martello, ogni problema diventa un chiodo"

No.

Le solite scuse sono le prestazioni e il prezzo, ma entrambi sono cattivi motivi. Il rendimento è minimo (ho corretto. Altri poster qui indicano alcune metriche interessanti. Continuo a pensare che "TLS è un must" sia una buona linea guida generale) e anche il prezzo è basso - la maggior parte le persone spenderanno ordini di grandezza di più per il caffè).

Pensando in retrospettiva avrebbe dovuto essere integrato nel protocollo HTTP, ma il giorno in cui nessuno pensava che HTTP si evolverà per diventare qualcosa che è oggi. In passato veniva utilizzato per trasferire documenti ipertestuali senza alcuna garanzia di integrità, sicurezza o altro.

Durante lo sviluppo, SSL rende molto più difficile eseguire il debug delle connessioni HTTP. Sicuramente puoi registrare i certificati del server in Wireshark, ma è una seccatura.

Quindi per lo sviluppo l'ho quasi sempre disattivato.

Ho già scritto una risposta a questa domanda su Quora:

https://www.quora.com/If-HTTPS-is-more-secure-than-HTTP-why-dont -all-website-use-HTTPS? s = 1

10 anni fa avrei concordato con le altre risposte che HTTPS non è necessario per la maggior parte dei siti web. Oggi non sono più convinto che sia facoltativo.

• Le connessioni crittografate riducono le opportunità di monitoraggio dell'ISP e del governo, entrambi un problema nella maggior parte dei paesi, inclusi gli Stati Uniti.
• Le connessioni crittografate riducono la possibilità di malware in transito e spoofing.
• Le connessioni crittografate compensano in una certa misura l'inadeguatezza dell'infrastruttura DNS non sicura.
• browser applica una politica di sicurezza leggermente superiore per le connessioni HTTPS, riducendo le opportunità di hacking sul client indipendentemente dal canale di comunicazione.
• Se HTTPS non è presente, nemmeno una volta, per un sito Web, un utente è vulnerabile a tutti degli attacchi o del monitoraggio di cui sopra.
• Un computer che viene violato anche una volta è di proprietà dell'hacker, per sempre o finché non viene riformattato e ripristinato in uno stato sicuro.

Anche il costo di HTTPS è minimo per ogni connessione web.

• Il costo della CPU della crittografia a 256 bit è molto basso, comparabile o basso erano superiori agli algoritmi di compressione.
• La latenza extra di ~ 500 ms dell'handshake SSL a 7 vie si verifica solo una volta per connessione web.

I vantaggi superano di gran lunga costi nell'ambiente informatico moderno su Internet. Scritto il 3 luglio.

Uno dei motivi che mi viene in mente è IPsec.

Oggigiorno, la crittografia sulle reti interne è riconosciuta come una pratica ad alta sicurezza. Probabilmente non è una pratica standard in questo momento, ma sta andando così.

IPsec presenta alcuni vantaggi rispetto a TLS per la crittografia di rete interna. Principalmente perché se hai intenzione di crittografare tutto, allora è un protocollo progettato per crittografare tutto, che TLS non è.

Normalmente non ha senso fare la doppia crittografia, quindi se stai usando IPsec internamente, è generalmente una cattiva idea usare anche TLS.

La crittografia rende ciechi i dispositivi di monitoraggio della rete (IDS / IPS / ecc.). A seconda della rete, si può scegliere di non crittografare il traffico. Sfrutta invece IPsec per garantire che l'integrità del traffico venga mantenuta pur consentendogli di passare in chiaro. Fornendo così accesso completo ai dispositivi di monitoraggio della rete senza il sovraccarico della crittografia.

Chiaro e semplice: quando la sicurezza non è richiesta. In altre parole, quando un visitatore anonimo sta navigando nel tuo sito web pubblico, HTTP è sufficiente e l'aggiunta di protocolli di sicurezza non è necessaria e spreca. (Come altri hanno notato, è anche uno spreco di risorse di altre persone poiché interferisce con la memorizzazione nella cache.)

La maggior parte dei siti web fornisce informazioni di uso generale senza requisiti di sicurezza speciali. Ovviamente, se il tuo sito contiene informazioni che le persone possono utilizzare in un contesto in cui l'affidabilità del contenuto è essenziale, allora ovviamente non rientri in questa categoria e dovresti prendere in considerazione misure come un sito solo HTTPS.

Probabilmente la scusa più grande che le persone danno per non utilizzare TLS riguarda l'hosting web di livello base nell'era dell'esaurimento degli indirizzi IPv4. Gli host web economici utilizzano l'hosting virtuale basato sul nome per impacchettare i siti web di dozzine di abbonati su una macchina dietro un indirizzo IP. Quando ospitavo il mio sito personale su Go Daddy, ho scoperto che il mio dominio era uno degli oltre mille su un singolo IP. L'utilizzo di HTTPS con l'hosting virtuale basato sul nome richiede un'aggiunta relativamente recente a TLS denominata Server Name Indication (SNI). Quasi tutti i principali browser Web ancora in uso, ad eccezione di Android Browser su Android 2.x e Internet Explorer su Windows XP, supportano SNI. Alcuni provider di hosting di fascia bassa offrono servizi SNI, ma non molti lo fanno a causa dei problemi di supporto causati da IE / XP e Android 2. Potrebbe essere necessario pagare di più per passare a un VPS.

Un secondo è il costo ricorrente di un certificato da una nota autorità di certificazione commerciale. Anche se utilizzi una CA che offre un livello di servizio gratuito, come StartSSL, è comunque un lavoro manuale ogni 12 mesi riemettere e reinstallare il certificato.

Infine, molte reti pubblicitarie non funzionano nelle pagine HTTPS a causa del blocco dei contenuti misti dei browser web. AdSense è l'unico che mi viene in mente e non offriva HTTPS fino a settembre 2013.

Non posso rispondere alla tua domanda per quanto riguarda la sicurezza delle comunicazioni e delle prestazioni, ma vedo una buona ragione per cui un world wide web solo HTTPS potrebbe essere pericoloso.

Quando il tempo di una macchina client è non impostato correttamente, questo causa problemi di certificato per la navigazione sul web. Si può osservare quando la batteria CMOS non tiene più la carica. Naturalmente, in tal caso, è possibile impostare nuovamente l'ora corretta nel sistema operativo.

Tuttavia, se un virus fosse in grado di apportare modifiche permanenti all'ora del sistema operativo su un gran numero di computer, causerebbe un blackout Internet per i siti https: //.