Non ha https moot questo intero sito?

I miei 2 centesimi, non proprio da un punto di vista della sicurezza IT:

Idealmente dovresti correlare e verificare le informazioni trovate su questo sito. Generalmente, le risposte si dividono in due categorie:

• Riassunto o spiegazione delle informazioni pertinenti.

• Fornire pensieri o analisi originali.

Il primo alla fine si riduce a qualcuno che riscrive la conoscenza umana esistente. In questi casi, probabilmente dovresti verificare le risposte e verificarle altrove se hai bisogno di informazioni per qualcosa di importante. Ad esempio, "Qualcuno di SE ha detto così" non è un buon dittatore di una politica IT cooperativa, dovresti capire e concordare con quanto è stato detto prima di seguirlo.

In questi casi, dovresti perseguire le informazioni menzionate su IT.SE e prenderle da altre fonti nella tua ricerca. Dovresti vedere gli stessi fatti e le stesse spiegazioni da qualche altra parte. Chiunque esegua un MITM contro di te e IT.SE sarebbe costretto a eseguire anche un MITM contro tutte le altre fonti che si guardano. Anche se non impossibile da fare, solleva la difficoltà di attacco in modo tale da dover filtrare l'intera esperienza di navigazione su Internet. A quel punto, il problema riguarda più la mancanza di HTTPS universale e se la connessione Internet è sicura.

Per il post occasionale che contiene informazioni originali che sono molto difficili o quasi impossibili da verificare in altro modo, questo è un punto valido. Un utente malintenzionato potrebbe sovvertire la tua fonte di tali informazioni. Ma sfortunatamente, molti altri luoghi non ospitano tali contenuti su HTTPS; questo non è univoco per IT.SE.

Se gli aggressori stanno facendo un MitM per iniettare buone risposte nello stream, non mi dispiacerà certo ...

Più seriamente, StackExchange conta sulla maggior parte delle persone che sono fondamentalmente oneste, e la maggior parte degli aggressori sono fondamentalmente persone, cioè pigri . Ci vuole un po 'di sforzo e risorse per mantenere un attacco Man-in-the-Middle a> quindi possiamo semplicemente presumere che la stragrande maggioranza delle connessioni ai siti di SE non sarà manomessa. Non è molto rassicurante, ma l'intero concetto di Civilization si basa su fondamenta ancora più scarse e abbiamo imparato a conviverci (e, occasionalmente ma non raramente, a morire per questo).

Dal punto di vista dei gestori SE, questo è un compromesso: cosa otterrebbero con SSL a livello di sito e cosa perderebbero? SSL a livello di sito aumenta il carico della CPU, ma non di molto: secondo Google , un solo + 1% di CPU e + 2% di larghezza di banda della rete. Questo era nel contesto di Gmail; un sito SE ha diversi schemi di utilizzo, e in particolare serve un sacco di "dati pubblici e per lo più statici" che potrebbero essere memorizzati nella cache (ad esempio, da proxy trasparenti installati dall'ISP). Il costo maggiore potrebbe essere il riferimento: anche se i motori di ricerca ora indicizzano il contenuto HTTPS, si può immaginare che lo gestiscano in modo diverso da quello che fanno con il contenuto HTTP. Ottimizzazione dei motori di ricerca è la forza vitale di siti Web gratuiti. Per riassorbire, sembrano esserci alcuni costi o rischi (che sono, economicamente, la stessa cosa) passare a HTTPS a pieno sito.

D'altra parte, che cosa otterrebbe da HTTPS a pieno sito? Non garantiscono nulla sulla veridicità dei dati, ed è pubblico. Che senso avrebbe fare per garantire la riservatezza e l'integrità dei dati in transito , mentre non era riservato e non era verosimilmente vero per cominciare? E, cosa ancor più importante, SE potrebbe ricavarne più denaro, per recuperare il costo aggiuntivo? Ricorda che StackExchange è un'azienda privata. Non sono Madre Teresa. Vogliono, in un modo o nell'altro, fare soldi.

Quindi logicamente , i manager di SE considereranno l'HTTPS completo solo quando ritengono che porterà un numero sufficiente di lettori in più. Questo mi sembra dubbio. Non dico che non voglio più SSL in generale; ma non posso incolpare i manutentori di SE per aver scelto diversamente.

Non dovresti mai credere, senza conferma, a qualsiasi cosa tu abbia letto su Internet.

Questo sito fornisce una risorsa e una discussione utili con alcune persone che realmente sottovalutano la sicurezza. Ma tutto ciò che leggi qui (e ovunque) deve essere confermato in modo indipendente.

Mentre le pagine trasmesse senza SSL potrebbero in effetti essere manomesse, è molto più probabile che le informazioni che leggi siano semplicemente sbagliate - qui e altrove. Come Wikipedia, StackExchange non dovrebbe essere considerato una "fonte primaria" di informazioni. È un'aggregazione di informazioni che deve essere confermata indipendentemente.

Davvero, non puoi. Non c'è autenticazione sulle informazioni. Detto questo, le probabilità di un attacco significativo in quel vettore sono probabilmente abbastanza minime in generale, quindi la banca probabilmente ha deciso che non valeva il costo di avere SSL sulla pagina (ci vuole più risorse del server per fare HTTPS). Il punto di equilibrio tra ciò che è un buon compromesso e ciò che non lo è è sempre una linea sfocata, ma per esempio, se un attaccante ha pubblicato un numero di telefono, dovrebbe essere effettivamente registrato a una persona e sarebbe più facile rintracciare chi è responsabile, dove semplicemente attaccare le credenziali di accesso per farle entrare in un sito di phishing è in genere più semplice di MitMing sul sito stesso.

Ma no, non c'è modo di dimostrare che il numero è corretto.

Inoltre, per riferimenti futuri, se ti trovi sul sito perché ritieni che il tuo computer sia infetto da un virus e il sito dice che non lo fai nuotare dall'orbita, allora chiaramente il tuo virus sta attaccando il contenuto che viene servito e quindi dovresti bombardarlo dall'orbita. :)

Riguardo a quella banca che emette numeri di telefono senza HTTPS, sì, questo è stupido, e sì, anche tipico. Mette in discussione l'intero sito? Ovviamente non influisce direttamente sulla sicurezza della parte HTTPS del loro sito, ma è una riflessione sulla loro governance generale della sicurezza. Prova a inviare un'email con "security @ their-domain-name" sul problema. Vedi se ottieni una risposta. Vedi se l'email rimbalza. Questo ti dirà ancora di più sul loro atteggiamento.

Riguardo allo Stack Exchange e ad altri consigli IT trovati online, la risposta è semplice: non fare cose che non capisci. Soprattutto non seguire le istruzioni nel formato "scarica ed esegui questo script". Facendo cose che non capisci, non solo ti stai aprendo ad un attacco, ma ti stai perdendo l'apprendimento. Molto meglio imparare e stare al sicuro allo stesso tempo.

HTTPS non funziona in questo modo: non è un controllo o un saldo sulla qualità o la provenienza delle cose che ricevi tramite HTTPS.

Una connessione https è una connessione http criptata con un certificato server e significa che, per quella determinata connessione, solo il software e le organizzazioni che la tua fiducia possono leggere quei dati.

Un certificato server valido (ovvero una connessione https che non genera un errore nel browser) significa solo una cosa, in termini generali: qualcosa di cui ti fidi (il tuo browser) si fida di qualcos'altro (il tuo sistema operativo) si fida qualcos'altro (il tuo fornitore di sistemi operativi) si fida di qualcos'altro (un fornitore di certificati di root) che a sua volta manda 'trust' alla persona a cui ti stai connettendo.

Questa catena di fiducia di solito significa che le persone non possono fingere una sessione https: in genere, la catena della fiducia e il percorso di rete passano attraverso organizzazioni diverse (eccetto negli endpoint) e ciò significa che https è sicuro nella maggior parte degli scenari tipici (ed è il motivo per cui le organizzazioni possono curiosare sul traffico https sul server proxy - i tuoi amministratori possono iniettare il loro certificato al livello "la tua macchina").

Quindi, visto tutto ciò - a cosa serve davvero? Bene, una connessione https significa che hai la stragrande probabilità di parlare con l'entità che pensi di essere. Ciò non rende tuttavia più sicuri i propri server o reti: se qualcuno è in grado di accedere al sito della banca e modificare i dettagli dei contatti, beh, https non è d'aiuto poiché possono modificare i siti http e https.

Tornando indietro, cosa significa questo per i contenuti su Internet?

Beh, https è un'implementazione tecnica di una catena di fiducia - dal momento che non puoi verificare chi sono, anche se c'era una connessione https tra me e link , non hai ancora alcun motivo per fidarti di me o di qualsiasi informazione ti sto dimostrando.

Puoi, tuttavia, verificare che la tua banca sia quella che dicono di essere - sanno cose su di te che nessun altro sa (come un codice che ti hanno inviato tramite posta ordinaria o numeri di conto sulle tue dichiarazioni) - quindi il fatto che hai usato quel codice per accedere, o che i numeri di conto corrispondono ai tuoi estratti conto bancari vuol dire che ritieni che siano quelli che dicono di essere. https ti fornisce quindi un meccanismo per sfruttare tale fiducia: sei a tuo agio con chi dicono di essere, ti fidi di loro tramite una catena tecnica di fiducia e quella catena crittografa la tua comunicazione in modo che il tuo livello di rete non possa leggere nella conversazione.