C'è sempre una buona ragione per non usare TLS / SSL?

Il problema principale di HTTPS è che fondamentalmente rende inutilizzabili i proxy Web nella cache (a meno che non si abbia fiducia nel proxy e si impersonino siti per te, ma non funziona con la graffatura del certificato ed è probabilmente illegale in alcune giurisdizioni) . Per alcuni casi d'uso, come ad esempio la distribuzione di aggiornamenti software firmati, HTTP ha perfettamente senso. Se hai, ad es. un centinaio di workstation dietro un proxy aziendale, il download degli aggiornamenti con HTTP significherà per tutti tranne uno che verrà consegnato dalla cache del proxy. Sarà molto più efficiente che ognuno di loro lo faccia su HTTPS ...

In breve, HTTP ha senso come livello di trasporto se c'è un altro meccanico per verificare l'autenticità e l'integrità del contenuto e se la riservatezza ha poca importanza ...

Per la navigazione web da parte di esseri umani reali, trovo molto difficile giustificare l'impossibilità di utilizzare HTTPS in questo giorno ed età.

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, è necessario innanzitutto l'handshake TCP tra client e server per HTTP e HTTPS, che richiede un round trip completo tra client e server.
• Per HTTPS hai in più l'handshake TLS che richiede due round trip nella creazione della sessione iniziale (solo uno se TLS false start è supportato) e un round trip se puoi riprendere una sessione.
• Mentre la crittografia simmetrica utilizzata all'interno della sessione TLS è economica, lo scambio di chiavi iniziale non lo è. Se lo fai bene, vuoi usare la segretezza in avanti, che significa DHE o ECDHE. Il semplice DHE è molto costoso da configurare, ECDHE è molto più economico ma non tutti i client lo supportano. Vedi link per i benchmark.

Queste cose combinate rendono le connessioni TLS più costose da configurare e introducono quindi un notevole impatto sulle prestazioni con connessioni brevi. Più hardware non aiuterà molto, perché il problema principale sono gli scambi aggiuntivi tra i peer, in cui devono attendere l'uno per l'altro per continuare.

Con connessioni lunghe questo overhead non ha più importanza, quindi se usi keep-alive (la maggior parte dei client e dei server lo fanno) e hai solo poche connessioni probabilmente starai bene. Ma poche connessioni significano che non dovresti includere alcuna rete pubblicitaria, perché spesso reindirizzano tra più host finché non raggiungono quella che alla fine serve l'annuncio. I siti che dipendono strongmente dagli annunci pubblicitari 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 pubblicitaria.

Un motivo per cui non ho ancora menzionato è che, per quanto arcaico possa sembrare, alcuni client potrebbero non supportare TLS / SSL. Si tratta di un caso specializzato, di sicuro, e in genere coinvolge sistemi incorporati o legacy, ma sfortunatamente alcuni esistono ancora.

Il primo esempio che ci viene in mente è un microcontrollore personalizzato che stavamo usando, in cui avevamo sottovalutato la quantità di spazio di cui avremmo avuto bisogno e che non saremmo stati in grado di includere la dimensione di una libreria SSL. Alla fine abbiamo dovuto interrompere e comunicare su HTTP standard, e siamo stati piuttosto grati che il server abbia dovuto estrarre i dati da entrambi i metodi offerti.

Sono stati inclusi anche in un sistema legacy alcuni anni fa che impedivano l'uso di TLS / SSL. È stato assunto un progetto per un mio amico che ha coinvolto la creazione di un server Web remoto e un client automatizzato in un'università. Lo script client era in esecuzione in un ambiente antiquato e pesantemente in modalità sandbox presso l'università: ogni parte della compilazione era gestita da un sistema automatizzato e l'insieme di librerie a cui si poteva accedere era un elenco codificato.

Sono abbastanza comuni da giustificare l'evitamento di TLS / SSL in casi normali? Direi di no, ma ci sono momenti in cui possono essere importanti. Se stai scrivendo software destinato principalmente a comunicare con sistemi embedded, ci penserei due volte prima di offrire solo TLS / SSL.

Un'altra nota su questo, poiché non la vedo specificata nella tua domanda, è che sembra che tutti abbiano fatto il salto per suggerire che quando hai chiesto informazioni su TLS / SSL, avevi un significato solo per HTTPS. Poiché si menzionano le comunicazioni TCP, si potrebbe anche considerare l'utilizzo di TLS / SSL per altre applicazioni che vengono eseguite su di esso oltre a HTTPS.

Ciò che viene in mente è TLS / SSL come usato da SMTP. Quando si tratta di utilizzare TLS / SSL per le comunicazioni SMTP, personalmente non lo farei mai come un metodo gestibile per la sicurezza (si noti, intendo le comunicazioni SMTP, non l'uso di TLS / SSL per fornire sicurezza tra un client di posta e una mail server). La ragione per cui dico questa è la natura intrinseca di TLS / SSL. Stai cercando una connessione socket sicura che sia adattata per un meccanismo di comunicazione a più hop.

Quindi, anche se imposti l'uso di TLS / SSL per le tue connessioni SMTP, puoi solo verificare che la connessione sia sicura e che il tuo hop sia fuori dal tuo server. Poiché la maggior parte dei flussi di posta ha più hop come questo:

mail server - > Soluzione AV - > Internet - > Soluzione AV - > Mail Server

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

Per il gusto di argomentare (come ho fatto io) diciamo che ci si prende il tempo necessario per garantire che il traffico SMTP tra due siti verificando ogni singolo salto tra i siti costringa TLS. Va bene per oggi, ma cosa succede quando l'infrastruttura cambia tra 5 anni? Se non si presta attenzione ad esempio, quando la soluzione AV viene modificata / sostituita, è possibile lasciare facilmente un hop non forzando TLS.

Volevo solo lanciarlo come un'altra implementazione TLS per il brainstorming (e se avessi bisogno di e-mail sicure dovrei usare la route S / Mime per cifrare effettivamente il messaggio sul lato del mittente e decifrare sul lato del destinatario). Come con qualsiasi strumento, devi usare 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 prestazioni e prezzo, ma entrambi sono cattivi motivi. Il successo della performance è minimo (sono corretto) Altri manifesti indicano alcune metriche interessanti. Continuo a pensare che "TLS è un must" è una buona guida generale) e anche il prezzo è basso - la maggior parte la gente spenderà ordini di grandezza più di quello sul caffè).

Pensando in retrospettiva avrebbe dovuto essere integrato nel protocollo HTTP, ma nel passato nessuno pensava che l'HTTP si sarebbe evoluta per essere qualcosa che è oggi. Nel passato è stato utilizzato per trasferire documenti ipertestuali senza alcuna garanzia di integrità, sicurezza o altro.

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

Quindi per lo sviluppo ho quasi sempre disattivato.

Ho già scritto una risposta a questo su Quora:

link

10 years ago I would have agreed with the other answers that HTTPS is unnecessary for most web sites. Today, I'm no longer convinced it's optional.

• Le connessioni crittografate riducono l'opportunità per ISP e monitoraggio governativo, entrambi problemi nella maggior parte dei paesi, compresi gli Stati Uniti.
• Le connessioni crittografate riducono l'opportunità di malware on-the-wire e spoofing.
• Le connessioni crittografate compensano in parte l'inadeguatezza dell'infrastruttura DNS non protetta.
• Il browser applica una politica di sicurezza leggermente più elevata per le connessioni HTTPS, riducendo le opportunità di hacking sul client indipendentemente dal canale di comunicazione.
• Se HTTPS non è presente, neanche una volta, per un sito Web, un utente è vulnerabile a tutti gli attacchi o il monitoraggio di cui sopra.
• Un computer che viene violato anche solo una volta appartiene all'hacker, per sempre o finché non viene riformattato e ripristinato in uno stato sicuro.

The cost of HTTPS are also minimal for each web connection.

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

The benefits far outweigh the costs in the modern computing environment on the Internet. Written 3 Jul.

Una delle ragioni che mi viene in mente è IPsec.

In questi giorni, la crittografia sulle reti interne è riconosciuta come una pratica ad alta sicurezza. Probabilmente non è una pratica standard solo ora, ma va in questo modo.

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

Normalmente non è necessario eseguire la doppia crittografia, quindi se utilizzi IPsec internamente, in genere non è consigliabile utilizzare TLS.

Dispositivi per il monitoraggio della rete dei dispositivi di crittografia (IDS / IPS / ecc.). A seconda della rete si può scegliere di non crittografare il traffico. Utilizza invece IPsec per garantire che l'integrità del traffico sia mantenuta mentre consente di passare in chiaro. Fornendo così ai dispositivi di monitoraggio della rete un accesso completo senza il sovraccarico della crittografia.

Semplice e chiaro: 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 è inutile e dispendiosa. (Come altri hanno notato, è anche uno spreco di risorse di altre persone in quanto interferisce con il caching.)

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

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

Un secondo è il costo ricorrente di un certificato da un'autorità di certificazione commerciale nota. Anche se utilizzi una CA che offre un livello di servizio gratuito, come StartSSL, è ancora un lavoro manuale ogni 12 mesi per 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 a cui riesco a pensare e non ha offerto 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 HTTPS potrebbe essere pericoloso.

Quando l'ora di un computer client non è impostata correttamente, ciò causa problemi con i certificati per l'esplorazione del web. Si può osservare questo quando la batteria CMOS non mantiene 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 numero elevato di computer, causerebbe un blackout Internet per i siti https: //.