Domanda:
Un sito HTTPS può essere dannoso o pericoloso?
Ulkoma
2014-08-29 04:57:19 UTC
view on stackexchange narkive permalink

So che è possibile che un computer venga infettato semplicemente visitando un sito web. So anche che i siti web HTTPS sono sicuri.

Per quanto ne so, "sicuro" qui si riferisce a "immuni agli attacchi MITM", ma poiché tali siti web hanno certificati e simili, è giusto presumere che lo siano " pulito "e non dannoso?

Significa solo che se contraggi malware da quel sito, in realtà proveniva da quel sito e non da qualche altra parte, quindi almeno sei sicuro di chi dare la colpa.
"So che il tuo computer può essere infettato semplicemente visitando un sito web". Questo è vero solo se il tuo browser ha una vulnerabilità al suo interno. Se il tuo browser è sempre aggiornato, non è davvero un problema.
@Gudradain * Di solito * non è un problema se il tuo browser è aggiornato. C'è ancora la possibilità di zero giorni. (Anche se ovviamente le probabilità che tu ti imbatta in uno di questi sono piuttosto scarse.)
HTTPS significa garantire che solo l'altro sito possa leggere le tue comunicazioni. Quello che l'altro sito fa con quelli semplicemente non è nel dominio del problema che HTTPS cerca di risolvere. Anche se hai la certezza di parlare con la persona con cui pensi di parlare, e nessun malintenzionato può origliare le tue comunicazioni o modificarle, non ha alcuna importanza se quella persona sia malvagia, se il contatto di una spia è un doppio agente, non importa quanto siano sicure le comunicazioni della spia con loro, perché non è lì che si trova l'attacco.
@cpast La tua prima frase dà l'impressione che si tratti di riservatezza. Ma qui l'autenticità e l'integrità dei dati sono davvero fondamentali. Ma questi non rimuovono realmente i vettori di attacco per il malware, ma aggiungono invece vettori di attacco per il malware.
"So anche che i siti Web HTTPS sono sicuri." Non proprio. Le connessioni HTTPS ** sono sicure. Questo non dice nulla sul sito Web dall'altra parte della connessione.
Potresti * tu, personalmente * scrivere un sito web ostile? Sicuro. Potresti * personalmente * ottenere un certificato per ospitare un sito HTTPS? Sicuro. Se * tu * puoi farlo, possono * altre persone * farlo anche tu? Sì.
@Shadur _a meno che il suo computer o browser fosse già infetto e fingeva di funzionare sotto https quando in realtà non lo era. Ovviamente è una specie di punto controverso.
Alla fine di un'e-mail legittima ricevuta da Twitter, si legge: "Come faccio a sapere che un'e-mail proviene da Twitter? I collegamenti in questa email inizieranno con "https: //" e conterranno "twitter.com".Il tuo browser mostrerà anche l'icona di un lucchetto per farti sapere che un sito è sicuro. "È fuorviante?
Dieci risposte:
Xander
2014-08-29 05:34:47 UTC
view on stackexchange narkive permalink

No, HTTPS non significa necessariamente che un sito non sia dannoso. HTTPS significa molto poco per quanto riguarda la sicurezza di un sito. È specificamente concepito per mantenere la tua comunicazione con il sito al sicuro da intercettazioni e manomissioni, ma non offre nulla per quanto riguarda la sicurezza del sito stesso.

Sì, un sito che serve contenuti su HTTPS dispone di un certificato. Ciò significa che la persona che ha richiesto il certificato dalla CA ha un indirizzo e-mail associato al dominio. Tranne nel caso dei certificati di convalida estesa (quelli che offrono una barra degli indirizzi verde) questo è letteralmente tutto ciò che significa. Nessuno della CA sta verificando che il sito sia sicuro, protetto e che non serva malware. Qualsiasi sito, con o senza un certificato SSL, può presentare bug e vulnerabilità che consentono a un utente malintenzionato di sfruttarli per servire un exploit. O un amministratore o un utente che ha la capacità di causare maliziosamente o inconsapevolmente il sito a servire malware. Anche se il sito stesso non lo fa, se offre pubblicità (o qualsiasi altro contenuto, per quella materia) da una rete pubblicitaria o un altro sito, quello potrebbe essere vulnerabile.

Quindi , HTTPS significa che nessuno dovrebbe essere in grado di visualizzare o manomettere il tuo traffico. Questo è tutto ciò che significa.

Jeff Clayton
2014-08-29 05:04:51 UTC
view on stackexchange narkive permalink

Per niente una garanzia. HTTPS significa che la pagina web ha SSL, il che significa semplicemente che la tua connessione alla pagina è crittografata. Il contenuto della pagina potrebbe essere qualsiasi cosa che possa essere pubblicata su qualsiasi sito web, crittografata o meno da SSL.

Inoltre, come elencato nelle risposte nei commenti qui sotto, puoi essere ingannato in un falso senso di sicurezza quando (in diversi tipi di esempi) il server di destinazione viene compromesso o un hacker reindirizza i dati del tuo sito https a una posizione crittografata https diversa. Puoi ancora essere crittografato su un sito, ma forse anche su un sito falso che assomiglia a quello reale.

E il certificato? Le CA non devono verificare l'identità del proprietario del sito ... ecc.?
Non tutti i certificati vengono acquistati da una CA. Le persone possono firmare i propri certificati. Inoltre, non tutte le persone che pagano denaro a una CA per un certificato sono oneste, le persone sono persone.
@Ulkoma Inoltre, nota che molte CA non verificano l'identità dell'acquirente di un certificato, ma semplicemente che la persona con cui hanno a che fare ha il controllo del dominio (ad esempio inviando e-mail a un indirizzo nel dominio). Potresti voler esaminare i certificati ssl di "convalida estesa", in cui l'emittente del certificato ha garantito di aver verificato l'identità, ma anche in questo caso il sistema non è infallibile.
Quando si parla di pirateria informatica, e sebbene non sia direttamente una risposta a questa domanda, è possibile che la tua connessione SSL venga dirottata, il che ti ingannerebbe in un falso senso di sicurezza. Controlla i vari post su questo sito sull'attacco SSLSTRIP Man in the Middle per ulteriori informazioni su questo tipo di problema: http://security.stackexchange.com/search?q=sslstrip
Non tutti i siti SSL sono privi della falla di sicurezza HEARTBLEED: http://security.stackexchange.com/search?q=heartbleed
Marco Valente
2014-08-29 19:25:58 UTC
view on stackexchange narkive permalink

In breve: sì, può effettivamente essere dannoso!

Accedere a un sito tramite HTTPS significa che la connessione tra il tuo computer e il server del sito web è crittografata e sicura.

Cosa fa HTTPS

  • Crittografa i dati trasmessi sulla rete tra il tuo computer e il server del sito web per impedire a terzi di intercettarli.
  • Prevenire gli attacchi man in the middle.

Cosa non fa HTTPS

  • HTTPS no eseguire la scansione del contenuto servito dal sito Web alla ricerca di virus o elementi dannosi

Pertanto è ancora possibile per gli autori del sito Web (o qualcuno che ha ottenuto l'accesso non autorizzato al sito Web) che il sito Web stesso serva contenuti dannosi nel tuo browser.

Probabilmente è più accurato dire che * mitiga * la possibilità di un attacco MITM. Dato l'accesso alla macchina degli utenti, potrei installare il mio certificato radice CA, ecc. Oppure l'utente potrebbe essere stupido e fare clic sul pulsante "Capisco i rischi" in Chrome, ecc.
Diego Queiroz
2014-08-29 23:59:24 UTC
view on stackexchange narkive permalink

La protezione da https non è correlata al contenuto di un sito Web / servizio.

Si chiama "sicura" perché teoricamente i protocolli di sicurezza (ssl / tsl e alcuni altri) non consentono di comprendere facilmente le informazioni scambiate (crittografa il flusso di dati), quindi, anche se qualcuno catturasse i tuoi pacchetti, dovrebbe decrittarlo per comprendere il messaggio.

Ora questo è utile perché alcune informazioni come password, numero di previdenza sociale, numero di carta di credito e così via possono causare molti problemi se vengono scoperte da qualcuno intento a causare danni.

In questo senso, https aiuta rendendo difficile per una terza parte sapere quali informazioni abbiamo scambiato con un sito Web (ed è per questo che la maggior parte delle banche utilizza almeno https sui propri servizi), ma ciò non impedisce a un sito Web o servizio di essere infettato da software dannoso o un utente malintenzionato per raggiungerti indirettamente infettando un server.

Ora, ho dedotto dalla tua domanda che quando usi d il termine "sicuro" lo intendevi in ​​modo diverso (nel senso di sicurezza contro contenuti dannosi), in questo senso, https non ti protegge affatto perché non presta attenzione al contenuto (ciò che viene trasmessa tramite la connessione) stessa .

h22
2014-08-29 12:53:41 UTC
view on stackexchange narkive permalink

Sì, può essere facilmente: JavaScript o virus dannosi possono essere trasferiti su HTTPS con la stessa facilità con cui su HTTP, nessun problema. Potrebbe essere un po 'meno probabile poiché la fonte del messaggio HTTPS verificato valido è nota.

Tuttavia può ancora accadere se il sito HTTPS ha avuto un buco di sicurezza, è stato attaccato, è stato compromesso e sono stati installati contenuti dannosi esso. Non passerà molto tempo, presto l'amministratore conoscerà l'uno o l'altro modo e rimuoverà il malware. Tuttavia, preferirei evitare di fidarmi del contenuto solo perché è stato fornito tramite HTTPS.

Edheldil
2014-08-29 10:59:22 UTC
view on stackexchange narkive permalink

Aggiungi all'elenco che la CA stessa potrebbe essere stata compromessa (ad esempio DigiNotar) e utilizzata per emettere certificati falsi, oppure il tuo browser potrebbe essere costretto a utilizzare CA false in modo specifico in modo che la tua connessione possa essere intercettata e manomessa, così com'è a volte utilizzato su reti aziendali.

Oh, anche il certificato potrebbe essere stato falsificato perché utilizzava MD5. Come è già stato detto, l'icona del lucchetto nel tuo browser significa qualcos'altro rispetto a quello che pensi :) .

Il tuo browser non dovrebbe considerare attendibili i certificati firmati con MD5. Ad esempio Firefox ha smesso di fidarsi di loro nel 2012: https://wiki.mozilla.org/CA:MD5and1024
Hutch
2014-08-29 22:50:10 UTC
view on stackexchange narkive permalink

Oltre agli altri punti sollevati, vale la pena ricordare che anche un sito attendibile (ad esempio la tua banca), potrebbe comunque essere infettato da un virus che lo fa comportare in modo malizioso. Quindi, anche se ti fidi dell'organizzazione, https continua a non garantire che il sito web non faccia cose dannose.

SilverlightFox
2015-08-14 20:21:44 UTC
view on stackexchange narkive permalink

Tutto ciò che fa una connessione HTTPS autenticata è convalidare che se https://www.example.com viene visualizzato nella barra degli indirizzi, significa che sei effettivamente connesso a www.example. com .

Il certificato non certifica che www.example.com non sia dannoso in alcun modo. Un certificato di convalida esteso con un'evidenziazione verde mostrata intorno alla barra degli indirizzi ti consentirà di conoscere l'effettiva organizzazione dietro il sito, quindi se ti fidi di loro puoi fidarti del sito. Esistono anche certificati verificati dall'organizzazione, tuttavia è difficile per gli utenti regolari distinguerli dai certificati verificati dal dominio.

I certificati DV sono molto facili da ottenere, quindi a meno che tu non conosca e ti fidi del dominio del sito già, non dovresti permetterti alcuna fiducia aggiuntiva nel sito solo perché utilizza https.

It-Z
2014-08-29 21:16:32 UTC
view on stackexchange narkive permalink

Un attacco Pharming può essere utilizzato per reindirizzare il traffico a un server dannoso. Questo server si connetterà a quello legittimo e si autenticherà su di esso come se fossi tu. Quindi ti presenterà le informazioni o la pagina web dal server legittimo. Per te - apparirà come sei connesso in modo sicuro al server legittimo ma ora c'è un MITM che ha accesso al canale e può leggere tutto su di esso. Questo tipo di attacco è difficile da eseguire ma può rendere HTTPS inutile ...

Quindi la dose del sito non deve essere dannosa, può essere la tua banca. Tuttavia, utilizzando questo approccio, qualcuno può ottenere tutti i dati del tuo account, le credenziali, ecc. Anche se il sito è HTTPS.

SOLO se si ignorano gli avvisi (sempre più odiosi) sul certificato non corrispondente o se l'aggressore è in grado di ottenere un certificato fraudolento ingannando la CA (dovrebbe essere impossibile, soprattutto per EV) o sovvertendolo (è successo, ma raramente).
Come ho detto ... difficile da eseguire :)
sebastian nielsen
2014-08-31 05:57:07 UTC
view on stackexchange narkive permalink

Un'altra cosa da considerare con molta attenzione è che alcuni antivirus funzionano analizzando il traffico. Se il sito utilizza HTTPS, un virus può infatti passare inosservato oltre il radar.

Ciò è particolarmente importante se si dispone di un servizio antivirus fornito dal proprio ISP, dal proprio datore di lavoro o dalla propria scuola, che è basato su un "proxy". Questo è il motivo per cui alcuni proxy fingono di essere effettivamente MITM come BlueCoat Proxy, quindi decomprimere il traffico crittografato, leggerlo e quindi inviarlo insieme a un certificato falsificato (che tutti i computer client dietro questo proxy sono configurati per accettare, tramite un GPO o un dispositivo NAC).

Quindi, HTTPS è un'arma a doppio taglio. Può essere utilizzato dai bravi ragazzi per nascondere dati validi (numeri di carte di credito, password, ecc.) Ai cattivi (ad es. Truffatori, hacker), ma può anche essere utilizzato dai malintenzionati per nascondere dati dannosi (ad es. Virus, illegali file ecc.) dai bravi ragazzi (scanner antivirus, forze dell'ordine ecc.)

Quindi, nel "gergo della protezione antivirus", dovresti EVITARE di utilizzare HTTPS.

La solita configurazione antivirus prevede che il browser chieda all'antivirus locale di scansionare i file scaricati prima che l'utente possa accedervi, funziona bene con HTTPS. Per quanto riguarda gli scanner di virus proxy, sì, devono giocare a MITM. Basare il tuo (non) uso di HTTPS sulla possibile esistenza di uno scanner antivirus mal configurato non sembra molto intelligente. Non farebbe nulla che uno scanner locale non possa fare e un utente normale non ha comunque alcuna scelta per quanto riguarda HTTPS.
Quello che intendevo è quando hai la scelta di utilizzare una variante HTTPS o una variante HTTP, dove SSL non è obbligatorio. Non è una configurazione scadente avere un proxy che analizza i file alla ricerca di virus. È abbastanza intelligente per alcuni ISP, aziende o scuole fornire servizi AV ai propri utenti senza che debbano installare nulla (ad eccezione di un certificato radice se non possono inviarlo tramite NAC / GPO). Tuttavia, quando non c'è MITM, dovresti evitare di usare HTTPS quando HTTP è disponibile se il sito non è affidabile.
Capisco quello che vuoi dire, ti ho quasi votato male ma quando ho letto l'ultima riga non l'ho fatto perché devi valutare quanti rischi avremmo in più se non usassimo HTTPS a differenza della situazione estrema che hai descritto (anche se è uno scenario intelligente e fattibile). Saluti
@begueradj Dipende da cosa vuoi proteggerti. Se il tuo intento principale non è quello di ottenere virus nel computer, è meglio non utilizzare HTTPS per consentire ai proxy centrali di scansionare il traffico. Ma se il tuo intento è proteggere i dati dalla lettura da parte di terzi, è meglio usare HTTPS. Una buona linea di mezzo quando si progetta una politica di sicurezza aziendale sulla scansione antivirus è abilitare (forzare) HTTPS su siti importanti come banche e simili e disabilitare forzatamente HTTPS su tutti gli altri siti non importanti.


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...