Qual è il vantaggio di forzare un sito a caricare su SSL (HTTPS)?


55

Diciamo che ho un sito di soli contenuti di grandi dimensioni; nessun accesso o logout, nessun nome utente, nessun indirizzo e-mail, nessuna area sicura, niente di segreto sul sito, nada. Le persone vengono semplicemente sul sito, passano da una pagina all'altra e guardano i contenuti.

Oltre ad un lieve urto a livello SEO da Google ( molto leggero, da quello che ho letto), c'è qualche vantaggio di costringere il sito di carico tramite HTTPS?


1
Non credo che questo sia un duplicato di Force Using SSL sul sito ora? . Sebbene alcune risposte possano finire per essere simili, quella domanda richiede consigli sull'opportunità di utilizzare SSL mentre questa domanda non lo è. Semmai, l'altra domanda dovrebbe essere chiusa per essere basata sull'opinione pubblica.
Stephen Ostermiller

4
Ribaltiamolo: quali sono i vantaggi di NON utilizzare SSL? Non c'è nessuno che io sappia. Oh, certo, l'implementazione che sarebbe una tantum e richiederebbe (rispetto a tutto il resto) senza tempo. Quindi, se un approccio non ha aspetti negativi e alcuni aspetti positivi, l'altro non ha aspetti positivi e (secondo te) nessun aspetto negativo, quindi ... perché attenersi a quest'ultimo?
VLAZ,

3
@Vld - performance. In questi giorni, spesso cerchiamo di ottimizzare i tempi di caricamento iniziale del sito a valori di prestazioni inferiori al secondo, con un obiettivo di 1/2 secondo. Su una connessione Internet leggermente lenta (latenza dei pacchetti di circa 100 ms), l'handshake SSL può facilmente richiedere 300 ms, il che potrebbe benissimo spingerti oltre un obiettivo prestazionale. Peggio per gli utenti di telefonia mobile: le reti mobili hanno latenze di pacchetti più lunghe e il tempo di elaborazione per la verifica della certificazione potrebbe facilmente essere di qualche altra centinaia di ms su un telefono più lento.
Jules,

6
I gestori di telefonia mobile manomettono sempre il traffico HTTP non crittografato, sia che si tratti di compressione (sovra) di immagini, di iniezioni di JavaScript malvagio o di intestazioni di controllo della cache più aggressive. HTTPS impedirà tutte queste sciocchezze.
André Borie,

2
@Josef Non è vero. HTTP / 2 funziona anche su connessioni non crittografate. Nessun browser può farlo, ma questa è una limitazione del browser, non HTTP / 2. Dire che "HTTP / 2 funziona solo su TLS" è come dire che "la tecnologia X non funziona perché Internet Explorer non la implementa". Guarda dove ci ha portato.
Agent_L

Risposte:


84

HTTPS non fornisce solo segretezza (di cui dubiti del valore, anche se ci sono ancora buone ragioni per farlo) ma anche autenticità , che è sempre utile. Senza di essa, un punto di accesso / router / ISP / ecc. Dannoso. può riscrivere qualsiasi parte del tuo sito prima di mostrarlo all'utente. Ciò potrebbe includere:

  • iniettando annunci per i tuoi concorrenti
  • iniettare annunci o fastidiosi widget che rendono il tuo sito un aspetto negativo e danneggiano la tua reputazione
  • iniettare exploit per eseguire download drive-by di malware sul computer del visitatore, che poi (giustamente!) ti incolpa per l'accaduto
  • sostituendo i download di software dal tuo sito con quelli che hanno malware in bundle
  • abbassando la qualità delle tue immagini
  • rimuovendo parti del tuo sito che non vogliono farti vedere, ad esempio cose che competono con i loro servizi o li descrivono in cattiva luce
  • eccetera.

La mancata protezione degli utenti da queste cose è irresponsabile.


27
@Mike Non proprio. C'è un sacco di software standard per farlo e tutto gestisce bene la decompressione e la ricompressione.
Ceejayoz,

3
@Mike Non proprio. Un proxy di riscrittura completo può decodificare tutto il traffico e iniettare da capo qualsiasi nuovo elemento desiderato.
Nayuki,

10
Cordiali saluti, la maggior parte se non tutti i miei esempi sono stati visti in natura.
R ..

2
@DavidMulder il tuo primo commento ha detto " de centralization [...] non è una buona cosa"
jiggunjer

3
Possiamo, per favore, non trasformare i commenti su questa risposta in uno spaccone fuori tema su questioni non correlate?
R ..

25

"niente di segreto sul sito"

... secondo te . Potrebbe esserci un motivo perfetto per cui qualcuno vuole una connessione sicura. Crea (in parte) la privacy:

Il mio amministratore può vedere che sto navigando su un sito di immagini sul mio telefono tramite url, ma non può dire se sto guardando foto di gatti carini o porno hardcore. Direi che è dannatamente buona privacy. "un contenuto" e "il contenuto" possono fare la differenza nel mondo. - Agente_L

Potresti pensare che sia insignificante, o forse non è un grosso problema ora, ma potrebbe essere in un altro momento. Sono fermamente convinto che nessuno a parte me e il sito web dovrebbe sapere esattamente cosa sto facendo.

Crea fiducia. Avere il lucchetto è un segno di sicurezza e può significare un certo grado di competenza riguardo al sito Web e quindi ai tuoi prodotti.

Ti rende meno un bersaglio per esempio attacchi MitM. La sicurezza aumenta.

Con iniziative come Let's Encrypt , che lo rendono molto più semplice e gratuito , non ci sono molti aspetti negativi. Oggigiorno la potenza della CPU assorbita da SSL è trascurabile.


11
Sfortunatamente SSL non impedisce all'IT aziendale, al tuo ISP o alle persone del caffè pubblico wifi di sapere quali siti stai visitando. Le ricerche DNS vengono ancora eseguite in chiaro . Sebbene non possano vedere il contenuto, né l'URL esatto, né che tu stia nemmeno utilizzando un browser web, possono vedere che stai accedendo a penisland.com (che è, ovviamente, un sito per gli appassionati di penna, ma potrebbe essere frainteso). L'uso di un proxy VPN o SOCKS5 proteggerà le tue query DNS.
Schwern,

3
@Martijn: con Server Name Indication (supportato da tutti i browser moderni), il nome host del sito Web viene inviato in chiaro come parte dell'handshake HTTPS. Non si tratta solo di attacchi sidechannel e non può essere mitigato, ad esempio, con DNSsec.
Kevin,

3
@Schwern Non ho mai capito l'argomento secondo cui HTTPS non protegge il nome host perché la ricerca DNS, SNI e il certificato del server sono in chiaro. Ovviamente è vero come affermato, ma HTTP in chiaro non è affatto migliore in questo senso!
un CVn del

5
@Schwern Il mio amministratore può vedere che sto navigando su Tumblr sul mio telefono, ma non può dire se sto guardando foto di gatti carini o porno hardcore. Direi che è dannatamente buona privacy. "un contenuto" e "il contenuto" possono fare la differenza nel mondo.
Agent_L

2
@Agent_L No, anche quello non è un buon consiglio. Se vai al https://penisland.tumblr.com/tuo browser eseguirà una richiesta DNS per la penisland.tumblr.comquale, a meno che tu non abbia protetto le tue query DNS, l'amministratore di rete può vedere. Quindi il tuo browser deve ottenere immagini, Javascript, CSS e annunci da vari domini che generano più richieste DNS. Potrebbero essere di qualsiasi dominio. I pochi domini di Tumblr porno che ho provato non hanno nulla di ovvio, Tumblr tende ad ospitare immagini e video in casa, ma non puoi fare affidamento su questo per la privacy.
Schwern l'

12

Ottieni supporto HTTP / 2 , il nuovo standard Web progettato per migliorare in modo significativo la velocità di caricamento del sito Web .

Poiché i produttori di browser hanno scelto di supportare HTTP / 2 solo su HTTPS, abilitare HTTPS (su un server che supporta HTTP / 2) è l'unico modo per ottenere questo aggiornamento di velocità.


1
Questo è piuttosto enorme e deve essere pubblicizzato di più. È un caso aziendale per il caricamento di HTTPS che solo la maggior parte dei manager può ottenere.
Dewi Morgan,

10

(Parti tratte dalla mia risposta a una domanda simile.)


HTTPS può ottenere due cose:

  • Autenticazione . Assicurarsi che il visitatore stia comunicando con il vero proprietario del dominio.
  • Crittografia . Assicurarsi che solo questo proprietario di dominio e il visitatore possano leggere la propria comunicazione.

Probabilmente tutti concordano sul fatto che HTTPS dovrebbe essere obbligatorio quando si trasmettono segreti (come password, dati bancari ecc.), Ma anche se il tuo sito non elabora tali segreti, ci sono molti altri casi in cui e perché l'uso di HTTPS può essere utile.

Gli aggressori non possono manomettere il contenuto richiesto.

Quando si utilizza HTTP, gli intercettatori possono manipolare il contenuto che i visitatori vedono sul tuo sito web. Per esempio:

  • Incluso malware nel software che offri per il download (o se non offri download di software, gli aggressori iniziano a farlo).
  • Censurare alcuni dei tuoi contenuti. Cambiare le tue espressioni di opinione.
  • Iniezione di annunci pubblicitari.
  • Sostituendo i dati dell'account delle donazioni con i propri.

HTTPS può impedirlo.

Gli aggressori non possono leggere il contenuto richiesto.

Quando si utilizza HTTP, gli intercettatori possono sapere a quali pagine / contenuti dell'host accedono i visitatori. Sebbene il contenuto stesso possa essere pubblico, la conoscenza che una persona specifica lo consuma può essere problematica:

  • Apre un vettore di attacco per il social engineering .
  • Violi la privacy.
  • Può condurre a sorveglianza e punizione (fino alla reclusione, tortura, morte).

Questo, ovviamente, dipende dalla natura dei tuoi contenuti, ma ciò che ti sembra innocuo può essere interpretato in modo diverso da altre parti.

Meglio prevenire che curare. HTTPS può impedirlo.


1
In effetti, HTTPS può impedirlo. In alcune situazioni, potrebbe non esserlo. Vedi Lenovo Superfish per un esempio abbastanza recente.
un CVn

@ MichaelKjörling: Sì, ne sono consapevole (è per questo che mi sono assicurato di usare "can";)), ma è un problema derivante dal comportamento del visitatore, non un problema con HTTPS stesso o il modo in cui il webmaster utilizza vero? Il visitatore dovrebbe preoccuparsi di quali CA fidarsi (e il visitatore dovrebbe preoccuparsi di quale software installare, specialmente se ha il permesso di armeggiare con l'elenco delle CA di cui fidarsi).
unor

Infatti; Non sto discutendo contro il tuo punto, solo aggiungendo ad esso!
un CVn

6

Previene gli attacchi man in the middle che ti fanno pensare che stai visitando il tuo sito ma presentano una pagina che proviene effettivamente da un altro e potrebbe tentare di ottenere informazioni da te. Poiché i dati sono crittografati, rende anche più difficile per un utente malintenzionato manipolare la pagina come la vedi.

Perché hai bisogno di un certificato SSL, che verifica che sei il proprietario del sito almeno fornendo almeno una verifica di chi sei.


3

Le aziende di marketing come Hitwise pagano gli ISP per raccogliere dati sul tuo sito quando non usi SSL. Vengono raccolti dati sul tuo sito che potresti non conoscere i tuoi concorrenti:

  • dati demografici dell'utente
  • statistiche sui visitatori
  • pagine popolari
  • parole chiave del motore di ricerca (anche se con "non fornito" questo è un problema minore in questi giorni)

3

E, solo per aggiungere un'altra cosa a tutte le risposte, parlerò solo della latenza. Perché, sembra che nessuno abbia scritto qui a riguardo.

Avere una bassa latenza HTTP da client a server è fondamentale per creare siti Web responsive a caricamento rapido.

TCP / IP da solo ha un handshake a 3 vie (la configurazione iniziale della connessione per HTTP su TCP semplice richiede 3 pacchetti). Quando si utilizza SSL / TLS, l'impostazione della connessione è maggiormente coinvolta, il che significa che la latenza per le nuove connessioni HTTPS è inevitabilmente superiore a quella del testo in chiaro HTTP.

Il problema con HTTP è che non è sicuro. Quindi, se si dispone di dati sensibili, è necessaria una qualche forma di sicurezza. Quando si digita qualcosa nel browser Web che inizia con "https", si chiede al browser di utilizzare un livello di crittografia per proteggere il traffico. Ciò fornisce una protezione ragionevole contro gli intercettatori, ma il problema è che sarà più lento. Dal momento che vogliamo crittografare il nostro traffico, ci sarà un certo calcolo coinvolto, che aumenta il tempo. Ciò significa che se non si progetta correttamente il sistema, il sito Web apparirà lento per gli utenti.

Concludere:

Ho un sito di soli contenuti di grandi dimensioni; nessun accesso o logout, nessun nome utente, nessun indirizzo e-mail, nessuna area sicura, niente di segreto sul sito, nada. Le persone vengono semplicemente sul sito, passano da una pagina all'altra e guardano i contenuti.

In questo caso, non userò affatto SSL. Vorrei avere la mia pagina quando fai clic su di essa che si apre in un secondo. È per esperienza dell'utente. Fai come desideri, io non metto certificati su tutto ciò che faccio. In questo caso particolare, non lo userei affatto.


IMO, questa è una risposta tanto corretta quanto quella che ottiene tutti i voti.
Michael Yaeger,

youtube.com/watch?v=e6DUrH56g14 menziona alcune tecniche per mitigare l'impatto delle prestazioni anche se tu (o una grande parte dei tuoi clienti) non puoi fare HTTP / 2 per qualche motivo.
un CVn il

1

Oltre ai vantaggi menzionati da altri c'è un motivo che ti farà passare a SSL a meno che non ti interessi dei tuoi visitatori che usano Chrome: le nuove versioni di Chrome (a partire dalla fine dell'anno per quanto mi ricordo) sono mostrerà un avviso (che allontanerà gli utenti dal tuo sito) per impostazione predefinita per tutti i siti che non utilizzano HTTPS.

//MODIFICARE:

Qui ci sono collegamenti ad altri due articoli dettagliati, anche se non riesco a trovare quello di cui ho letto quando hanno intenzione di presentare ufficialmente la funzione:

https://motherboard.vice.com/read/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https

http://www.pandasecurity.com/mediacenter/security/websites-that-arent-using-https/


Non è una citazione perfetta per l'affermazione fatta nella risposta, ma c'è sempre la marcatura di HTTP come non sicura .
un CVn

1

La semplice risposta è che non c'è una buona ragione per non farlo . In passato c'erano argomenti sull'utilizzo di SSL solo se assolutamente necessario (ad esempio sui siti di e-commerce che raccolgono dettagli di pagamento).

Ciò dipendeva in gran parte dalla procedura di installazione per i certificati SSL, i costi, il carico aggiuntivo sul server web e le limitazioni della rete, in un momento in cui le persone non avevano la banda larga, ecc. Nessuno di questi motivi si applica davvero nel 2016.

In termini di SEO, sappiamo che l'obiettivo della maggior parte dei motori di ricerca è quello di fornire i migliori risultati per i loro utenti, e questo può essere fatto dando loro una connessione sicura al sito che stanno navigando. A questo proposito, i motori di ricerca non si preoccupano se sul sito siano presenti dati "sensibili" (presentati o raccolti); è semplicemente il caso che se il sito viene offerto tramite HTTPS, tutti i potenziali rischi di autenticazione e crittografia sono notevolmente ridotti al minimo, quindi il sito sarebbe considerato "migliore" rispetto al sito equivalente senza HTTPS.

Fondamentalmente, è così semplice e diretto da implementare, oggi è visto come la migliore pratica. Come sviluppatore web, prendo in considerazione l'installazione di un certificato SSL e quindi la forzatura di tutte le richieste su HTTPS (molto facile usando .htaccess o un equivalente) come parte standard di qualsiasi sito o applicazione web che creo.


1

Oltre alle altre risposte, i browser dovrebbero (come in RFC 2119) inviare l' User-Agentintestazione. Fornisce informazioni sufficienti sulla piattaforma utilizzata da un utente se invia l'effettivo User-Agent. Se Eva riesce a intercettare una richiesta fatta da Alice, e Alice invia l'attuale User-Agent, Eve saprà quale piattaforma utilizza Alice senza che Alice si colleghi al server di Eva. Sarà più facile hackerare il computer di Alice con tale conoscenza.


È un po 'come dire che se Eva riesce a vedere il numero VIN della macchina di Alice attraverso il parabrezza della macchina, rende più facile per Eva entrare nella macchina di Alice perché il numero VIN le permette di scoprire quale marca e modello di auto possiede Alice. Certo, è una possibilità, ma ci sono un sacco di modi per ottenere più o meno le stesse informazioni senza che il MITM abbia fatto nulla, in modi che a malapena si registrerebbero come qualcosa di più del rumore di fondo di Internet per un nodo foglia sulla rete. Ad esempio: Eva (o forse Mallory) potrebbe inviare ad Alice un link a una pagina web sotto il suo controllo. Alla gente piace fare clic sui collegamenti.
un CVn

1

Hai due opzioni per proteggere il tuo dominio principale (mysite.com) e i suoi sottodomini (play.mysite.com e test.mysite.com). SSL non è solo per e-commerce, siti di commercianti di pagamento in cui le transazioni finanziarie o le credenziali di accesso sono condivise sul sito Web. È altrettanto importante per il sito Web basato sul contenuto. Gli aggressori cercano sempre un sito Web HTTP semplice o una scappatoia nel sito Web. SSL non solo fornisce sicurezza ma autentica anche il tuo sito web. Il vantaggio principale di avere SSL sul sito Web basato sul contenuto è che,

  • Puoi evitare attacchi man-in-middle che possono alterare il contenuto del sito.

  • Inoltre, il tuo sito Web avrà autenticità che notifica ai visitatori che le loro informazioni saranno protette se condividono con il sito Web.

  • Ottengono la certezza dell'autenticità del sito Web.

  • Inoltre, il tuo sito Web sarà libero dall'iniezione di annunci dannosi, exploit, widget indesiderati, sostituzione di software e danni alle pagine Web una volta che avrai SSL sul tuo sito web.

  • Il certificato SSL offre un sigillo del sito statico che può essere inserito in qualsiasi pagina Web per sicurezza e i clienti possono fare clic sul sigillo per conoscere i dettagli del certificato SSL installato.


1

Altre risposte hanno parlato dei vantaggi di HTTPS. Da un utente sarebbe costretto a utilizzare HTTPS? Per due motivi:

  • Se offri agli utenti la possibilità di non utilizzare HTTPS, probabilmente non lo faranno, soprattutto perché la maggior parte dei browser utilizza http: // e non https: // per impostazione predefinita quando digita un dominio nella barra degli indirizzi.
  • Implementando sia una versione protetta che una versione non sicura, si aumenta la superficie di attacco della connessione. Dai agli aggressori la possibilità di eseguire un attacco di downgrade anche se pensi di utilizzare la versione sicura.
  • Se reindirizzi ogni URL http: // all'https: // equivalente, ciò semplifica la vita dell'amministratore del server e dei motori di ricerca. Nessuno deve preoccuparsi se http: // e https: // debbano essere equivalenti o destinati a puntare a cose completamente diverse, reindirizzando l'uno all'altro è chiaro a tutti quali URL devono essere utilizzati.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.