Domanda:
Perché HTTPS non è il protocollo predefinito?
blunders
2011-06-05 23:59:48 UTC
view on stackexchange narkive permalink

Perché HTTP è ancora comunemente usato, invece quello che ritengo molto più sicuro HTTPS?

Esempio: [Perché i download delle applicazioni non vengono eseguiti regolarmente su HTTPS?] (Http://security.stackexchange.com/q/18853)
Non direttamente correlato, ma un'interessante interpretazione di Troy Hunt: https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/ Fondamentalmente HTTP / 2 funziona solo con TLS, quindi usando HTTPSpuò migliorare la velocità (se il client e il server utilizzano HTTP / 2).
IMO, i browser non dovrebbero accettare affatto un indirizzo senza schema.Se desideri trovare informazioni su un nome di dominio o un indirizzo IP, questo è un problema con Chrome e altri browser che non hanno un campo di ricerca separato.
Per chi cerca una soluzione: [usa un'estensione] (https://chrome.google.com/webstore/detail/smart-https/cmleijjdpceldbelpnpkddofmcmcaknm?hl=en)
Nove risposte:
#1
+68
Thomas Pornin
2011-06-06 01:39:39 UTC
view on stackexchange narkive permalink

SSL / TLS ha un leggero sovraccarico. Quando Google ha cambiato Gmail in HTTPS (da una funzione opzionale all'impostazione predefinita), hanno scoperto che il sovraccarico della CPU era di circa + 1% e il sovraccarico di rete + 2%; vedi questo testo per i dettagli. Tuttavia, questo è per Gmail, che consiste in dati privati, dinamici, non condivisi e ospitati sui sistemi di Google, accessibili da qualsiasi luogo con una latenza molto bassa. Gli effetti principali di HTTPS, rispetto a HTTP, sono:

  • L'avvio della connessione richiede alcuni roundtrip di rete aggiuntivi. Poiché tali connessioni vengono "mantenute attive" e riutilizzate quando possibile, questa latenza aggiuntiva è trascurabile quando un determinato sito viene utilizzato con interazioni ripetute (come è tipico di Gmail); i sistemi che servono principalmente contenuti statici possono trovare il sovraccarico di rete non trascurabile.

  • I server proxy non possono memorizzare nella cache le pagine servite con HTTPS (poiché non vedono nemmeno quelle pagine). Anche in questo caso, non c'è nulla di statico da memorizzare nella cache con Gmail, ma questo è un contesto molto specifico. Gli ISP amano molto il caching poiché la larghezza di banda della rete è la loro forza vitale.

  • HTTPS è HTTP all'interno di SSL / TLS. Durante l'handshake TLS, il server mostra il suo certificato, che deve designare il nome del server previsto - e ciò si verifica prima che la richiesta HTTP stessa venga inviata al server. Ciò impedisce l'hosting virtuale, a meno che non venga utilizzata un'estensione TLS nota come Indicazione del nome del server; ciò richiede il supporto del cliente. In particolare, Internet Explorer non supporta l'indicazione del nome del server su Windows XP (IE 7.0 e versioni successive lo supportano, ma solo su Vista e Win7). Data l'attuale quota di mercato dei sistemi desktop che utilizzano WinXP, non si può presumere che "tutti" supportino l'indicazione del nome del server. Invece, i server HTTPS devono utilizzare un IP per nome server; lo stato attuale della distribuzione IPv6 e la carenza di indirizzi IPv4 rendono questo un problema.

  • HTTPS è "più sicuro" di HTTP nel seguente senso: i dati sono autenticati come provenienti da un server denominato e il trasferimento è riservato nei confronti di chiunque possa intercettare la linea. Questo è un modello di sicurezza che non ha senso in molte situazioni: ad esempio, quando guardi un video da Youtube, non ti interessa davvero se il video proviene davvero da youtube.com o da qualche hacker che (cortesemente) invia tu il video che desideri vedere; e quel video è comunque un dato pubblico, quindi la riservatezza è di scarsa rilevanza qui. Inoltre, l'autenticazione viene eseguita solo relativamente al certificato del server, che proviene da un'autorità di certificazione di cui è a conoscenza il browser client. I certificati non sono gratuiti, poiché il punto dei certificati è che implicano l'identificazione fisica del proprietario del certificato da parte della CA (non sto dicendo che la CA commerciale stabilisca un prezzo equo per i loro certificati; ma anche la CA più giusta, gestita dallo stesso Buddha, lo farebbe devono ancora addebitare una tassa per un certificato). La CA commerciale vorrebbe solo apprezzare che HTTPS fosse "l'impostazione predefinita". Inoltre, non è chiaro se il modello PKI incorporato nei certificati X.509 sia realmente ciò che è necessario "per impostazione predefinita" per Internet in generale (in particolare quando si tratta di relazioni tra certificati e DNS - alcuni sostengono che un certificato del server deve essere emesso dal registrar al momento della creazione del dominio).

  • In molte reti aziendali, HTTPS significa che i dati non possono essere visti dagli intercettatori e quella categoria include tutti tipi di filtri dei contenuti e software antivirus. Impostare HTTPS come predefinito renderebbe molto infelici molti amministratori di sistema.

Tutti questi sono motivi per cui HTTPS non è necessariamente una buona idea come protocollo predefinito per il Web. Tuttavia, non sono il motivo per cui HTTPS non è, attualmente, il protocollo predefinito per il Web; HTTPS non è l'impostazione predefinita semplicemente perché HTTP era lì per primo.

+1 per i contenuti statici subisce un colpo. Considera un sito con più tag . Poiché ogni immagine avrà una connessione separata, l'overhead computazionale di una connessione crittografata a 2048 bit o 4096 bit può diventare abbastanza significativo su piattaforme mobili in cui l'aumento dell'utilizzo della CPU consuma rapidamente una batteria, gli utenti potrebbero evitare il tuo sito perché per un motivo o un altro pensano che scarichi la loro batteria. Questo è ovviamente un pregio dell'hosting di contenuto statico non riservato su un server separato (senza SSL).
+1 @puddingfox: Punto interessante per quanto riguarda il sovraccarico della CPU per i dispositivi mobili.
@puddingfox: Lavoravo come PM per lo sviluppo mobile e, come la vedo io, se è richiesta la sicurezza, il preferito attuale è usare un'app nativa specifica per la piattaforma, che utilizza un'API REST / SOAP crittografata solo per dati al servizio web. L'impostazione SSL utilizza fx 2048 bit (ricorda, dopo l'installazione passerai a fx 128 bit AES), ma ** il carico della CPU per la crittografia non è un vero problema **. I veri problemi con le app in-browser / SSL sono la latenza di rete e il supporto Javascript difettoso sui browser mobili. Ecco perché le app native sono preferite.
sovraccarico "leggero"? Penso di no. La latenza è il killer per le applicazioni basate sul web. Ciò è peggiorato dalla cronologia dei problemi sull'implementazione ssl di MSIE (ora per lo più risolti). Ci sono anche costi aggiuntivi relativi a SSL (l'acquisto di un certificato è solo l'inizio).
@puddingfox: un browser aprirà solo alcune connessioni SSL a un determinato sito (ad esempio 3 o 4), utilizzando HTTP keep-alive per inviare diverse richieste HTTP successive all'interno di ciascuno. Inoltre, solo il primo ha bisogno di uno scambio di chiavi asimmetriche (quello in cui è coinvolta una chiave di 2048 bit o giù di lì); le altre connessioni useranno la funzione di "ripresa della sessione" SSL / TLS (handshake più veloce, meno messaggi, solo crittografia simmetrica). Infine, la maggior parte dei server SSL / TLS utilizza una chiave RSA e la parte client di RSA è economica (il server sostiene la maggior parte del costo in RSA).
"Questo è un modello di sicurezza che non ha senso in molte situazioni ... non ti interessa davvero ..." - è altamente soggettivo. Ci tengo.
Buona risposta. Tuttavia, c'è un motivo per cui qualcuno sufficientemente paranoico potrebbe voler visualizzare i video di YouTube su https: visualizzarli su https significherebbe che un intercettatore non sarebbe facilmente in grado di compilare una registrazione dei video che guardi.
Per quanto riguarda l'affermazione che "non ti interessa davvero se il video proviene davvero da youtube.com", questo è sbagliato. Se sto guardando un video di Bruce Schneier che parla di crittografia e potrei prendere decisioni in base alla sua opinione, allora voglio sapere che il messaggio non è stato alterato durante il transito.
@dotancohen: è l'integrità che è un problema separato e può essere risolto senza utilizzare la crittografia. Una firma digitale del flusso video è sufficiente per stabilire che il video è inalterato dalla sua fonte. Sfortunatamente la firma digitale di contenuti non crittografati e memorizzabili nella cache non è ampiamente distribuita, poiché non esiste un'infrastruttura ampiamente distribuita per questo, AFAICT.
@LieRyan: Grazie, capisco cosa intendi. C'è un ulteriore ostacolo: i flussi video sono memorizzabili nella cache, contenuti _streaming_ non crittografati, quindi non è possibile fornire un hash SHA1 dei contenuti. Forse IPSec potrebbe essere la risposta.
I dettagli di @dotancohen: variano, ma ciò che la maggior parte della tecnologia di streaming video essenzialmente fa è tagliare il video in piccoli pezzi. Quei pezzi possono essere firmati individualmente. La cache ha già bisogno di capire come il flusso è suddiviso in blocchi per poter comunque memorizzare nella cache i flussi, quindi metà del lavoro è già lì. Esistono anche alcuni sistemi di flusso che utilizzano HTTP Range Request per il chunking, che è già ampiamente compreso dalla cache e dal proxy HTTP standard.
Esistono anche molti altri contenuti altamente memorizzabili nella cache che possono trarre vantaggio dalla firma digitale aggiungendo integrità e autenticazione senza necessariamente richiedere riservatezza e che non hanno il problema di dover essere uno streaming ricercabile come i video. Sarebbe davvero utile se ci fosse un meccanismo standardizzato in HTTP per aggiungere firme digitali che i browser possono controllare per garantire l'integrità e che consente ai contenuti firmati di essere memorizzati nella cache da cache intermedie. Questa sarà un'opzione nel mezzo di HTTPS e HTTP.
http://www.httpvshttps.com/
"Data l'attuale quota di mercato dei sistemi desktop che utilizzano WinXP" Windows XP non è più supportato e possiamo presumere che il client sia sottoposto a un attacco zero day che impedisce al client di mantenere qualsiasi tipo di riservatezza. Quindi come potrebbe essere riscritto?
"anche la più bella CA, gestita dallo stesso Buddha, dovrebbe comunque addebitare una commissione per un certificato" StartSSL non addebita una commissione per un singolo certificato TLS. Né Let's Encrypt.
@tepples, ciò che conta per gli operatori di siti Web non è tanto se Windows XP è supportato da MS o meno. Invece, si preoccupano di quanti utenti non saranno in grado di utilizzare il tuo sito web se attivi SNI (ad esempio, quota di mercato di Windows XP). Questo si è evoluto nel tempo. Molti siti sono disposti a escludere gli utenti di Win XP che utilizzano IE, ma non tutti, e ci sono alcuni segmenti di mercato in cui una frazione non banale di utenti utilizza IE su Win XP. Quindi, questo non è un problema in bianco e nero - gli operatori del sito devono esprimere un giudizio - e le osservazioni di Thomas rimangono utili e ampiamente valide.
_L'inerzia_ è una forza molto più forte di qualsiasi altra cosa nell'industria informatica. Combatto contro di essa ogni giorno.
[E la precisione?] (Http://goo.gl/Inw9GL) Vai su Youtube per i video ma ti dà invece contenuti da Facebook. Vai su Facebook e invece ti mostra Google. Vai su Google e ti mostra qualcosa che non è sicuro per la vita. O cose che potrebbero metterti in prigione. Come ... un download di virus o un exploit zero-day che utilizza il tuo computer per condividere materiale piratato, o trasmettere discorsi contro lo stato (un reato grave o capitale in più di diversi paesi), o esportare criptovalute o rilasciare segreti di stato, o * qualsiasi cosa * per quella materia. ** Tutti hanno bisogno di HTTPS **, solo che ancora non lo sanno.
@Thomas, La conclusione * "HTTPS non è l'impostazione predefinita semplicemente perché HTTP era lì per primo" * non è affatto convincente. Tante cose sono cambiate * da allora * e l'impostazione predefinita di HTTPS non ha alcun problema di compatibilità. Affermo ** il motivo è la velocità e la velocità da sole **. O quello o [monitoraggio dello stato] (https://goo.gl/h5eDpz). Se presumiamo (come afferma la tua conclusione) che la velocità e la latenza non fossero ** il motivo **, allora sicuramente Chrome potrebbe recuperare prima la pagina HTTPS e ripiegare su HTTP quando la connessione scade? (Anche SNI è un non-problema, come Chrome lo ha.)
La caduta di @Pacerier è dove fallirebbe completamente.Pensa agli attacchi MitM.MitM potrebbe semplicemente impedire l'accesso tramite la porta 443 e quando il tuo Chrome intelligente torna al testo normale, riceve i tuoi dati.
#2
+32
Jesper M
2011-06-06 02:46:01 UTC
view on stackexchange narkive permalink

Sebbene siano già state fornite ottime risposte, credo che finora un aspetto sia trascurato.

Eccolo: HTTP semplice è il protocollo predefinito per il Web perché la maggior parte delle informazioni su il web non ha bisogno di sicurezza.

Non intendo sminuire la domanda o le preoccupazioni sulla sicurezza di alcuni siti web / applicazioni. Ma a volte possiamo dimenticare quanto traffico web:

  • contiene solo informazioni completamente pubbliche
  • o ha poco o nessun valore
  • o dove avere più i visitatori sono visti come un aumento del valore del sito (mezzi di informazione, siti con effetto di rete)

Alcuni rapidi esempi, sono sicuro che puoi fare più nella tua mente:

  • Quasi tutti i siti web aziendali, a volte chiamati "siti di brochure", che elencano informazioni pubbliche su un'azienda.
  • Quasi tutti i media, i blog , Stazioni televisive e così via che hanno scelto il supporto pubblicitario come strategia di monetizzazione principale.
  • Servizi che possono offrire accessi e personalizzazione aggiuntiva, ma che regalano anche i propri contenuti gratuitamente a chiunque navigazione anonima (YouTube fx).
Sono d'accordo, non c'è motivo di lasciare nulla inosservato. Una cosa mi sono chiesto, e riguarda il tuo punto di vista sull'informazione pubblica. Gli URL visualizzati durante le transazioni HTTPS su uno o più siti Web da un unico IP sono distinguibili? Ad esempio, supponiamo che i seguenti siano URL HTTPS di due siti web con un IP in 5 minuti: "A.com/1", "A.com/2", "A.com/3", "B.com/1" , "B.com/2"; il monitoraggio dei pacchetti non rivelerebbe nulla, rivelerebbe solo l'IP che aveva visitato "A.com" e "B.com", rivelerebbe un elenco completo di tutti gli URL HTTPS visitati, rivelerebbe solo gli IP di "A.com" e "B.com" , o qualcos'altro?
I commenti di @blunders: non sono i posti migliori per porre nuove domande. Dai un'occhiata al seguente link o apri una nuova domanda. http://security.stackexchange.com/questions/2914/can-my-company-see-what-https-sites-i-went-to
+1 @Jesper Mortensen: Grazie, d'accordo. Ha esaminato l'altra domanda e ha pubblicato questa domanda: [Gli URL visualizzati durante le transazioni HTTPS su uno o più siti Web da un unico IP sono distinguibili?] (Http://security.stackexchange.com/questions/4388/are-urls-viewed- durante-transazioni-https-verso-uno-o-più-siti-da-un-singolo-i)
Un numero di telefono su un "sito di brochure" potrebbe essere un'informazione completamente pubblica. Ciò non significa che essere in grado di falsificare un numero di telefono su quel sito Web non sia un rischio per la sicurezza.
@JesperMortensen, Stai confondendo "non ha bisogno di sicurezza" con "non ha bisogno di privacy". Sì, i dati sono pubblici, ciò non significa che possiamo evitare HTTPS (il mitm può semplicemente restituire una pagina fasulla fuorviante).
@JesperMortensen, Riguardo a * "Quasi tutti i siti web aziendali, a volte chiamati siti di brochure, che elencano informazioni pubbliche su un'azienda" *, e senza HTTP un hacker può dirottare quella pagina e inserire quello che vuole in essa. È accettabile?
@JesperMortensen, Ok, mi sono reso conto che questo terzo commento è in ritardo di alcuni mesi, ma questo è importante: ** HTTPS non riguarda solo la sicurezza. ** Si tratta anche di accuratezza. Hai affermato che il Web non ha bisogno di sicurezza, ma il Web ha bisogno di precisione? (Immagina solo [quanto caos] (http://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#comment200128_4376) ci sarebbe quando visiteremo "a.com" ma ottieni contenuti da `b.com` e viceversa. Vai su` youtube.com` aspettandoti di vedere alcuni video ma ti reindirizza a `bing.com`.)
#3
+6
Mike Scott
2011-06-06 00:15:45 UTC
view on stackexchange narkive permalink
  • Mette molto più carico della CPU sul server, soprattutto per il contenuto statico.
  • È più difficile eseguire il debug con l'acquisizione di pacchetti
  • Non supporta i server virtuali basati sul nome
+2 @D.W .: Immagino abbia senso che sarebbe difficile avere un metodo universale per condividere implementazioni specifiche dell'applicazione; il che significa che non puoi semplicemente fare una copia delle chiavi e delle configurazioni per eseguire il rendering della decrittazione incorporata nel debugger. E sì, l'ho visto elencato nella risposta @Thomas, che è stata pubblicata dopo @Mike Scott; l'ho lasciato così com'è, dato che mi chiedevo se @Mike Scott avesse un altro motivo. Saluti!
@D.W. Anche Windows XP non è supportato. La sua fine del supporto nell'aprile 2014 rompe l'ultimo grande ostacolo all'implementazione di SNI.
@tepples, il mio commento è stato scritto 4 anni fa. Ovviamente, la situazione con Windows XP si è evoluta nel tempo. (E non è rilevante se Windows XP è supportato o meno. Ciò che è rilevante è quanti utenti usano Windows XP, cioè quanti utenti non saranno in grado di usare il tuo sito web se attivi SNI. Come ho scritto nel mio commento, vedere la risposta di Thomas Pornin.)
@D.W. Stavo facendo notare che il tuo commento da allora è diventato obsoleto. Mi scuso per non essere stato più esplicito al riguardo. Ma anche se avessi molti utenti XP, qual è il punto nel creare una connessione sicura a una macchina che rischia di essere compromessa con uno zero-day?
@tepples, non è così semplice. Qual è il valore di quell'utente per il proprietario del sito? La risposta dipenderà dal sito. Non perdono quell'utente e potrebbero essere in grado di monetizzare quell'utente (ad esempio, quell'utente potrebbe voler acquistare qualcosa da loro, quindi potrebbero perdere una vendita se bloccano tali utenti). Sono in gran parte solidale con la tua argomentazione, ma ancora una volta, quello che sto dicendo è che non è così semplice come stai cercando di far sembrare. Se vuoi persuadere gli altri, è importante comprendere le considerazioni che guidano le loro decisioni.
@tepples Solo perché XP è alla fine del supporto non significa che non sia ampiamente utilizzato. Questo è un non-starter di una risposta; Gli utenti di XP devono ancora acquistare cose, quindi hanno ancora bisogno di SSL, il che significa che SNI non è una buona soluzione.
@D.W. Ho aperto [un'altra domanda su queste considerazioni] (http://security.stackexchange.com/questions/82066/can-serving-https-to-internet-explorer-on-windows-xp-be-made-secure).
#4
+6
Rory Alsop
2011-06-06 00:33:32 UTC
view on stackexchange narkive permalink

Http è sempre stato il valore predefinito. Inizialmente https non era necessario per nulla, era praticamente un'aggiunta aggiunta poiché divenne ovvio che la sicurezza era necessaria in alcune circostanze.

Anche ora, ci sono così tanti siti web che non hanno bisogno di https non è ancora un argomento convincente per sostituire completamente http.

Con meccanismi sempre più efficaci per l'esecuzione di connessioni protette TLS, il sovraccarico della CPU sta diventando molto meno un problema.

#5
+6
Dog eat cat world
2011-08-23 02:10:32 UTC
view on stackexchange narkive permalink

Nessuno ha evidenziato un problema evidente che deriva dall'utilizzo di http come predefinito, piuttosto che https.

Quasi nessuno si preoccupa di scrivere l'uri completo quando richiede una risorsa che deve essere crittografata e / o firmato per vari scopi.

Prendi gmail come esempio, quando gli utenti visitano gmail.com , in realtà visitano il protocollo predefinito di http, anziché https. A questo punto la sicurezza è fallita negli scenari in cui l'avversario sta intercettando il traffico. Perché? Perché è possibile rimuovere html dalla richiesta https e indirizzarli a http.

Se https fosse in effetti il ​​protocollo predefinito, le tue sessioni ai siti web sarebbero state protette.

Al domanda perché http viene scelto su https, si applicano le varie risposte sopra. Il mondo non è ancora pronto per un uso diffuso della crittografia.

Stai descrivendo l'attacco "SSL stripping". Da allora i browser hanno implementato HTTP Strict Transport Security (HSTS) come contromisura, inclusi gli elenchi di precaricamento HSTS e HTTPS Everywhere (essenzialmente un elenco di precaricamento HSTS di terze parti).
@tepples HSTS è peggio che inutile, poiché può anche essere rimosso fornendo un falso senso di sicurezza ai proprietari dei server.
@Alice, Cosa intendi per HSTS può essere rimosso?
@Dogeatcatworld, La domanda è ** perché ** i browser cambiano la richiesta dell'utente (digitando l'URL) da `web.com` a` http: // web.com` invece di `https: // web.com`?
@Pacerier La prima volta che un utente segue un collegamento utilizzando lo schema "https:" a un sito che utilizza HSTS che non è nell'elenco di precaricamento, un proxy HTTP che riscrive tutti i collegamenti può riscrivere il collegamento per utilizzare invece lo schema "http:". Ecco perché esiste l'elenco dei precarichi, ma nessun elenco dei precarichi è esaustivo. Finché l'utente resta dietro ai proxy di stripping, visita solo i siti non presenti nell'elenco di precaricamento del browser, non digita mai manualmente lo schema "https:" e non si accorge mai della mancanza dell'icona di un lucchetto nel posto giusto, l'utente non è a conoscenza di qualsiasi attacco.
#6
+3
thomasrutter
2014-09-09 05:41:11 UTC
view on stackexchange narkive permalink

Oltre alle ragioni già fornite da altri:

  • Lavoro aggiuntivo richiesto per configurare HTTPS sul server

    L'amministratore del server deve configurare i certificati per ogni dominio. Ciò implica l'interazione con un'autorità di certificazione per dimostrare che sei il vero proprietario del dominio e ottenere il rinnovo del certificato. Ciò potrebbe significare la generazione manuale di richieste di firma del certificato e l'acquisto di rinnovi o l'impostazione di un processo automatizzato per farlo (come certbot utilizzando Let's Encrypt). In entrambi i casi, è più faticoso che non utilizzare HTTPS.

  • Sono necessari indirizzi IP aggiuntivi

    Questo non è un problema da quando il supporto SNI (Server Name Identification) è diventato molto diffuso nei browser e nelle librerie client SSL.

    Tradizionalmente, tuttavia, era necessario utilizzare un indirizzo IP diverso per ogni sito distinto utilizzando SSL su un server e una porta particolari. Ciò ha interferito con la possibilità di eseguire l'hosting basato sul nome (hosting virtuale), una pratica ampiamente utilizzata che consente di ospitare molti domini diversi dallo stesso indirizzo IP. Con HTTPS, il normale hosting basato sul nome non funziona perché il server dovrebbe sapere quale nome host presentare nel livello di convalida SSL / TLS prima della richiesta HTTP, contenente il hostname, può essere decrittografato.

    Server Name Identification (SNI), che implementa efficacemente l'hosting basato sul nome a livello SSL / TLS, rimuove questa limitazione.

  • Lenta velocità di cambiamento

    HTTPS era una modifica a un protocollo esistente, HTTP, che era già molto radicato prima che molte persone iniziassero a pensare alla sicurezza. Una volta che una tecnologia si è affermata e onnipresente come l'HTTP, può volerci molto tempo prima che il mondo passi al suo successore, anche se le ragioni del cambiamento sono convincenti.

Ciao fjw, questa è una domanda molto vecchia, con buone risposte e una risposta accettata. La tua risposta non porta nulla di nuovo: ti incoraggio a contribuire rispondendo a nuove domande.
La consideri davvero una risposta di bassa qualità? Mi dispiace davvero, mi sono imbattuto in questo mentre stavo cercando qualcosa e sentivo che le risposte esistenti non riuscivano ad affrontare quelli che pensavo fossero alcuni punti importanti. Non sono assolutamente d'accordo sul fatto che questa sia una "risposta di bassa qualità".
Mi è stato segnalato dai membri della comunità e sono d'accordo con loro. Il mio commento sopra spiega il mio punto.
#7
+2
Simon East
2014-04-13 09:14:24 UTC
view on stackexchange narkive permalink

Thomas ha già scritto un'ottima risposta, ma ho pensato di offrire un paio di motivi in ​​più per cui HTTPS non è più ampiamente utilizzato ...

  • Non necessario . Come la risposta di Jesper sottolinea in modo acuto "la maggior parte delle informazioni sul web non ha bisogno di sicurezza". Tuttavia , con il crescente numero di tracciamenti effettuati da motori di ricerca, società pubblicitarie, filtri Internet a livello nazionale e altri programmi del "Grande Fratello" (es. NSA); sta aumentando la necessità di misure di privacy maggiori.

  • Velocità. Spesso sembra lento a causa dei viaggi di andata e ritorno aggiuntivi e richieste aggiuntive per elenchi di revoche di certificati ( OCSP ecc.). Per fortuna SPDY (creato da Google e ora supportato in tutti i principali browser) e alcuni lavori interessanti di CloudFlare stanno aiutando a cambiare questa situazione.

  • Prezzo dei certificati. La maggior parte delle autorità di certificazione addebita importi esorbitanti (centinaia di dollari) per un certificato. Per fortuna ci sono opzioni gratuite, ma queste non ricevono molta pubblicità (non sai perché?).

  • Prezzo degli indirizzi IP . Fino a quando IPv6 non sarà diffuso, i siti web dovranno affrontare la crescente scarsità (e quindi il costo) degli indirizzi IPv4. SNI consente di utilizzare più certificati su un singolo indirizzo IP, ma senza il supporto SNI in Windows XP o IE 6, la maggior parte dei siti necessita ancora di un indirizzo IP dedicato per fornire SSL.

  • Aumento dell'utilizzo della CPU del server. Questa è una credenza comune, ma secondo Google " SSL / TLS non è più costoso dal punto di vista computazionale ".

Anche mancanza di retrocompatibilità.
Una settimana dopo aver pubblicato questa risposta, Windows XP stesso non è più supportato. Cosa cambia questo?
@tepples niente, poiché quelle persone non sono state aggiornate automaticamente a Windows 7, per quanto ne so.
[StartSSL ha ora ottenuto un po 'di pubblicità] (http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-web-security/) ma non nel modo in cui presumibilmentericercato :-)
Devo dire che non sono assolutamente d'accordo con l'affermazione che TLS non è computazionalmente costoso.Si presume che i siti siano tutti serviti da un potente hardware.Questo semplicemente non è vero quando il server web è in esecuzione su un dispositivo incorporato in cui il consumo energetico è una considerazione primaria.
#8
+1
blfoleyus
2014-12-30 03:18:13 UTC
view on stackexchange narkive permalink

La spiegazione più semplice e ragionevole che ho trovato tra i miei colleghi è che è sempre stato fatto con HTTP, perché cambiarlo ora.

Se non è rotto, non aggiustarlo.

La privacy di HTTP è sempre stata violata.
iOS 9 lo rompe.Nessun http per le app non browser per impostazione predefinita.E nessuna implementazione https obsoleta consentita per impostazione predefinita.
#9
+1
Rob
2016-07-11 10:09:21 UTC
view on stackexchange narkive permalink

La vera risposta è che i certificati SSL nella loro forma attuale sono comicamente difficili da usare. Sono così inutilizzabili da minacciare la sicurezza dei certificati, poiché le persone prendono scorciatoie solo per fare le cose. Lo dico come qualcuno che si occupa abitualmente di SSL a 2 vie (certificati PKI), le incompatibilità dello stack TLS create dalla complessità delle specifiche e il numero folle di combinazioni di configurazioni (limiti di cifratura, opzioni, bug di libreria specifici della lingua , ecc.) che sono chiamati "TLS".

Vedi l'ascesa di LetsEncrypt come prova che questo è vero.

Caddy è un progetto di proxy inverso che utilizza LetsEncrypt. Può rinnovare i certificati mentre il server è in esecuzione e le persone utilizzano scadenze molto brevi perché i rinnovi sono automatizzati.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...