Domanda:
Perché i browser utilizzano per impostazione predefinita http: e non https: per gli URL digitati?
Beni Cherniavsky-Paskin
2015-02-17 01:40:55 UTC
view on stackexchange narkive permalink

Quando digito example.com senza alcuno schema nella barra del browser e premo Invio, viene interpretato come HTTP://example.com , non HTTPS : //example.com . Perché? E dove sono i piani per risolvere questo problema?

(Per essere chiari, sto parlando solo di indirizzi digitati / incollati provenienti da un utente "pigro", non di software- azioni definite come i seguenti URL relativi allo schema, window.location = "url" ecc. E ovviamente digitare / incollare HTTP://example.com deve comunque funzionare.)

MODIFICA : come alcune risposte sottolineano, i siti possono già per lo più raggiungere questo obiettivo con i reindirizzamenti + HSTS. Il vantaggio tecnico centrale sarebbe restringere il problema della prima connessione (risolto anche dal precarico HSTS ma che non può essere adattato a tutti i siti). Posso vedere come questa sia una debole giustificazione per rompere le cose adesso ; quello che mi interessa di più è se sarà un finale ovvio tra 5 anni? 10? 20?

Vedo diversi problemi durante il passaggio all'interpretazione predefinita di https:

  1. Esperienza utente con siti che funzionano solo su http. L'impostazione predefinita di https mostrerebbe un errore, ma l'utente di solito non ha idea se dovrebbe funzionare, cioè se questo sito semplicemente non ha mai funzionato su https o si tratta di un attacco di downgrade.

    Se la pagina di errore per questa situazione conterrà un semplice "intendevi http: ...?" link (*), gli utenti si abitueranno a cliccarlo su qualsiasi sito che non funziona e non abbiamo guadagnato molto (?). E se non è facile (ad es. L'utente deve modificare https-> http , gli utenti non utilizzeranno tale browser.

    EDIT : avrei dovuto chiarire che l'indicazione di errore deve essere diversa dall'andare esplicitamente a un indirizzo HTTPS che non è riuscito - questo scenario non è tanto "fallito" quanto "l'interpretazione sicura non ha funzionato". E per cominciare, anche " un errore soft "automaticamente su HTTP con una barra di avviso in alto sarebbe OK.

    Ma penso che otteniamo ancora 3 cose: andare su un sito non protetto è un'azione consapevole, istruiamo gli utenti che HTTP non protetto è non normale e facciamo pressione sui siti per implementare https.

  2. Inconveniente di dover digitare http: // in alcuni casi. IMO è stato completamente superato dalla comodità di non dover digitare https: // in più casi.

  3. "Compatibilità" con l'impostazione predefinita storica. Non sono sicuro che sia racchiuso in uno standard, ma IMO è chiaro che dovremo cambiarlo un giorno , quindi non è uno spettacolo.

  4. Politica / economia: il sistema CA ha i suoi problemi e i browser potrebbero essere riluttanti a fare pressioni sugli amministratori del sito perché li paghino (se altrimenti non vedono valore in questo). Ignoriamo i soldi per un momento e fingiamo che Let's Encrypt CA gratuito sia arrivato.

Capisco perché apportare la modifica in questo momento può essere controversa; quello che mi sconcerta è il motivo per cui non è ampiamente discusso come l'ovvio obiettivo a lungo termine, con qualche piano in scena a-la deprivazione dei certificati SHA-2 anche se forse più lento. Quello che vedo sembra presumere che http rimarrà predefinito praticamente per sempre:

  • La mossa di Chrome per nascondere http: // nella barra degli URL è un passo indietro. Il primo passo verso l'impostazione predefinita di https avrebbe dovuto essere la visualizzazione di http in rosso; in un secondo momento eventualmente passare a nascondere https: // (mostrando solo il lucchetto verde) ...

  • HSTS si muove nella giusta direzione ma con prudente attivazione per sito. È sia più debole che più forte: i siti scelgono di forzare https anche per URL http espliciti, senza che l'utente possa ricorrere per errori, ma l'RFC non menziona nemmeno l'idea che https potrebbe essere un valore predefinito globale , o che lo schema predefinito del browser sia la causa del problema bootsrap MITM.

  • Ho visto DNSSEC menzionato come futuro vettore per l'attivazione di tipo HSTS ma ancora una volta non ho mai visto proposte di rinuncia ...

Inoltre, ci sono browser (o estensioni) che offrono questa opzione?

Un buon sito web implementerebbe reindirizzamenti automatici alla versione SSL.
@ps2goat: ... e un sito web migliore utilizzerebbe (anche) [HSTS] (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). Tuttavia, anche questo non protegge completamente la prima richiesta.
C'è un difetto fondamentale nella logica di preferire `https` a` http`: da dove prendi l'idea che `https` sia migliore? L'unica cosa che guadagna `https` è la sicurezza dei dati trasmessi dal client al server. Ma questo, di per sé, non è sempre necessario. Né il tuo sito è magicamente sicuro perché stai usando `https`; ad esempio un sito WordPress "sicuro" che utilizza "https" è abbastanza vulnerabile agli attacchi se la versione di WordPress ha una falla di sicurezza e un amministratore non la applica. Non esiste un valore reale per l'impostazione predefinita di "https". Se pensi che ci sia, devi saperne di più.
@IlmariKaronen, +1 per HSTS. Non è buono come HTTPS ovunque, ma è il più vicino che ci sia.
@JakeGould https protegge molto di più della semplice comunicazione da client a server. In molti casi, tutto ciò che devi proteggere è l'integrità dei dati inviati dal server al client, anche https fa questo.
Il reindirizzamento automatico di @ps2goat: da http a https non è una situazione ideale. Un utente malintenzionato potrebbe eseguire un attacco man-in-the-middle e non reindirizzare e visualizzare invece un sito di phishing
Sono sorpreso che nessuno abbia menzionato i portali prigionieri. Non è possibile reindirizzare a una schermata di accesso da https perché il captive portal non avrebbe il certificato per il sito con cui si sta tentando di parlare e i reindirizzamenti da esso verrebbero rifiutati. Ciò è nel contesto di luoghi più piccoli tipo coffee shop che offrono Internet gratuito e rilevamento inaffidabile captive portal.
Hai fatto alcune ipotesi errate. Con programmi come SPDY e HTTP / 2 non sceglierai se crittografare menzionando il protocollo. Quindi la fine del gioco è probabilmente che tutto è crittografato ma non c'è http: // mostrato nel browser
@JamesRyan punto molto interessante. Farne una risposta?
Un punto critico è che gli attacchi MitM non sono comuni come percentuale di attacchi. In particolare con gli attori statali, l'approccio tipico è quello di aspirare * tutto * il testo in chiaro e di entrare nei sistemi per afferrare il resto una volta che è stato decifrato. MitM è un'ultima risorsa molto scarsa se si sta monitorando l'intero Internet all'ingrosso. Il vecchio canard "se non possiamo ottenere la sicurezza al 100% non dovremmo preoccuparci della crittografia" è morto: anche la crittografia non firmata senza fiducia o identificazione è ora nota essere un deterrente infinitamente migliore del testo in chiaro.
** Vota per riaprire **. Gli altri post chiedono dell'adozione "perché https non è più popolare?". Questa domanda chiede specificamente "perché i browser assumono http anziché https?" una domanda importante con un'interessante risposta sulla sicurezza.
OP chiede perché i browser presumono http, invece di provare prima https e poi eseguire il fallback su http? È importante sottolineare che perché non sarebbe sicuro. Un man-in-the-middle potrebbe bloccare https e causare un downgrade a http e dirottarlo. Per essere sicuri, i browser devono fallire. Questo è lo scopo dell'intestazione Strict-Transport-Security (HSTS) e dell'elenco di precaricamento.
Per lo più ho chiesto informazioni sull'hard fail: supponi https, consenti all'utente di eseguire il downgrade * manualmente *, ma ho menzionato il soft fail con una barra di avviso in alto come opzione "per principianti". Se tale barra di avvertimento avrebbe un impatto nella pratica è una questione di UX; Sospetto di no (le barre di avvertimento sono passate di moda per un motivo) ma potrebbero istruire alcuni utenti a passare a una modalità di errore difficile più sicura.
Non sto cercando di discutere la crittografia opportunistica invisibile qui; potrebbe essere una buona cosa (Dewi Morgan ha fornito una buona argomentazione sopra) ma quella logica probabilmente si applica a qualsiasi indirizzo http:, non solo a quelli senza schema digitati manualmente.
Tieni presente che questo comportamento può essere modificato utilizzando un'estensione per Firefox.
@SargeBorsch Sto usando HTTPS ovunque, ma ciò influisce anche sui collegamenti HTTP incollati / seguiti.Ce n'è uno che influenza solo `foobar.com` quando viene digitato senza protocollo?Sarò felice di modificare un collegamento nella domanda.
@BeniCherniavsky-Paskin è un'estensione diversa.
@SargeBorsch puoi dare un link (o almeno il nome dell'estensione) per favore?
@BeniCherniavsky-Paskin non ricorda esattamente e non sono vicino al mio computer di casa ora, ma è qualcosa come "https per impostazione predefinita".e il comportamento è quello di fallire duramente se la versione https non è disponibile, non tornerà silenziosamente al testo in chiaro
@BeniCherniavsky-Paskin https: // github.com / Rob - W / https per impostazione predefinita
Otto risposte:
Steffen Ullrich
2015-02-17 01:48:59 UTC
view on stackexchange narkive permalink

I browser sono applicazioni per gli utenti finali. Sebbene la maggior parte dei siti sia disponibile tramite http (anche se si limita a reindirizzare a https), una parte significativa non è disponibile da https. degli utenti. Si spezzerebbe in un modo che loro non capiscono. Il downgrade automatico a http se https fallisce non avrebbe senso perché un utente malintenzionato potrebbe semplicemente causare il caos con le connessioni alla porta 443 per imporre il downgrade.

Una volta che tutti i siti, tranne pochi insignificanti, sono passati a https, si potrebbe fare il passare a un valore predefinito più sicuro, ma non ancora. Gli utenti finali non capirebbero cosa è successo e probabilmente passerebbero semplicemente a un browser alternativo o riceverebbero alcuni suggerimenti da qualche parte su Internet per ripristinare il vecchio comportamento.

Le decisioni sulla sicurezza devono essere prese con e non contro utenti.

I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/21261/discussion-on-answer-by-steffen-ullrich-why-do-browsers-default-to-http-and- non).
Anonymous
2015-02-17 01:50:26 UTC
view on stackexchange narkive permalink

Bene, posso presumere che esistano alcuni motivi:

  1. Il supporto HTTPS non è configurato automaticamente sui siti web. Pertanto, perché i browser dovrebbero presumere che lo sia?
  2. Dire che un sito web non è accessibile a meno che l'utilizzo di uno schema specifico non sia sulla testa di un numero significativo di utenti.
  3. Passaggio a HTTPS non è così semplice come sembra in alcuni casi. Prendi Stack Exchange per esempio.

Queste sono le tempistiche di alcuni browser popolari per risolvere questo problema:

Google Chrome

  1. Chrome 46

    Chrome contrassegna lo stato "HTTPS con errori minori" utilizzando la stessa icona di pagina neutra delle pagine HTTP.

  2. Chrome 56

    contrassegna le pagine HTTP che raccolgono password o carte di credito come non sicure

  3. Chrome 62

    Chrome mostrerà l'avviso "Non sicuro" in altre due situazioni: quando gli utenti inseriscono dati su una pagina HTTP e su tutte le pagine HTTP visitate in modalità di navigazione in incognito.

  4. Chrome 68

    nella omnibox verrà visualizzato "Non protetto" per tutte le pagine HTTP.

  5. Chrome 79

    Chrome passerà gradualmente al blocco di tutti i contenuti misti per impostazione predefinita. Per ridurre al minimo le interruzioni, aggiorneremo automaticamente le risorse miste a https: //, quindi i siti continueranno a funzionare se le loro sottorisorse sono già disponibili su https: //.

  6. Chrome 81

    Chrome stamperà un messaggio di console di avviso su tutti i download di contenuti misti.

  7. Chrome 84

    Chrome avvisa in caso di download di contenuti misti di eseguibili (ad esempio .exe).

  8. Chrome 85

    Chrome bloccherà gli eseguibili di contenuti misti

    Chrome avviserà della presenza di archivi di contenuti misti (.zip) e immagini del disco (.iso).

  9. Chrome 86

    Chrome bloccherà file eseguibili di contenuti misti, archivi e immagini disco

    Chrome avviserà su tutti gli altri download di contenuti misti ad eccezione dei formati immagine, audio, video e testo.

  10. Chrome 87

    Chrome avvisa in caso di download di contenuti misti di immagini, audio, video e testo

    Chrome bloccherà tutti gli altri download di contenuti misti

  11. Chrome 88

    Chrome bloccherà tutti i download di contenuti misti.

Firefox

  1. Firefox 51

    le pagine web che raccolgono password ma non utilizzano HTTPS visualizzeranno un'icona a forma di lucchetto grigio con una barratura rossa nella barra degli indirizzi.

  2. Firefox 70

    inizieremo a mostrare un'icona di blocco barrata come indicatore permanente per i siti forniti tramite i protocolli non sicuri HTTP e FTP.

Accettato come unica risposta con (inizio di) un piano e buon esempio per (3). [Steffen Ullrich] (http://security.stackexchange.com/a/81802/31246) e [Bruno] (http://security.stackexchange.com/a/81982/31246) fanno un buon lavoro nell'elaborare (2 ). [Commento di JamesRyan] (https://security.stackexchange.com/questions/81801/why-do-browsers-default-to-http-and-not-https-for-typed-in-urls?lq=1#comment134795_81801 ) ha sottolineato che nel momento in cui questo potrebbe essere accettabile per gli utenti, il panorama dei protocolli sarà diverso.
Ci sono piani per passare a HTTPS, la prima fase è la creazione di nuove funzionalità solo HTTPS.https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ Anche se da allora non so se sono stati fatti progressi.
Vorrei commentare, continuando la progressiva lotta di Google contro http non crittografati, che mi aspetto che in pochissimi anni i browser proveranno prima https automaticamente, o addirittura preferirei evitare del tutto il semplice http.Come ha sottolineato @Anonymous nella seconda parte della risposta, il processo è ** in corso **.Quanti sono * pochi * anni?Qualcuno di Mozilla, Google & Co dovrebbe provare a rispondere
Post di Firefox del 2017 sulla visualizzazione dell'icona del lucchetto barrata in rosso per http: https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
@BeniCherniavsky-Paskin Grazie, l'ho aggiunto alla lista.
TTT
2015-02-17 04:25:59 UTC
view on stackexchange narkive permalink

È in gioco un problema più grande che impedirebbe il tuo suggerimento. Il modo in cui molti server Web sono attualmente configurati, potresti effettivamente finire sul sito Web sbagliato se imposti https per impostazione predefinita. Questo non è vero se si utilizza per impostazione predefinita http.

Ad esempio, supponiamo di avere 3 siti tutti sullo stesso indirizzo IP: 

  http: //site.a. comhttp: //site.b.comhttps: //site.c.com

Su molti server, se si dovesse tentare di accedere a https: //site.a .com , (invece di http), guarderai effettivamente al sito C, ma con un errore di certificato.

Sì, questo è il problema più grande. Di solito è causato dal fatto che SNI non è configurato per un determinato sito, quindi il server utilizza per impostazione predefinita un altro sito. Inoltre, non tutti i siti su un host condiviso avranno un certificato: come può il browser rilevare il caso "il server è in ascolto su 443 ma non esiste un sito valido per questo host"? Risposta semplice: non può. Non affidabile. Lo stesso si potrebbe dire per 80, ma è più raro per ragioni storiche menzionate in altre risposte.
@Bob Se l'agente utente compatibile con SNI si connette con un nome di server che non è tra i siti su quell'IP con un certificato, il server invierà semplicemente il certificato predefinito dell'IP. Una mancata corrispondenza del nome del soggetto IMO indicherebbe in modo affidabile "nessun sito valido per questo host".
@tepples Questo ti aprirebbe a un MitM. Un utente malintenzionato MitM potrebbe semplicemente sostituire un certificato con un SN o SAN errato e far tornare il browser a HTTP - ** molto molto male **.
@Bob Se HTTPS è specificamente richiesto (UA ha un precaricamento HSTS per questo nome host, UA ha visto l'intestazione HSTS in una visita precedente, o l'utente ha inserito "https: //"), l'UA mostrerà la pagina di mancata corrispondenza del nome. L'opportunità MITM si presenterebbe solo alla prima visita a un sito non nella lista di precaricamento quando l'utente rifiuta di specificare uno schema, e non sarebbe peggiore di oggi quando HTTP è già assunto.
@tepples Buon punto. L'altro problema rimanente (relativamente raro, ma non inaudito) è un certificato con caratteri jolly in cui alcuni sottodomini non sono effettivamente accessibili tramite HTTPS ma hanno ancora una corrispondenza nell'elenco SAN. C'è anche un'abbondanza di server in cui funziona la connessione HTTPS, ma interrompe il sito (ho eseguito l'addon HTTPS Anywhere in passato, che testerà e si connetterà a HTTPS quando possibile [al contrario di Everywhere che utilizza whitelist], e questo è diventato ovvio abbastanza rapidamente) - ciò risale ai webmaster che presumevano HTTP e non testavano mai HTTPS.
Bruno
2015-02-19 04:25:24 UTC
view on stackexchange narkive permalink

Penso che ci sia un reale pericolo di confondere molti utenti, il che peggiorerebbe ulteriormente la situazione. Provare HTTPS ovunque non è necessariamente una cattiva idea, ma deve esserci una sorta di piano di riserva per l'utente quando HTTPS non è disponibile.

Molti utenti non sono interessati ai segnali di avvertimento, semplicemente vogliono il loro contenuto. In molti casi, proteggere il traffico che ricevi da intercettazioni o attacchi MITM non è strettamente necessario, o almeno il rischio e le conseguenze sono molto inferiori rispetto a un certificato errato sulla tua banca.

Essenzialmente, se gli utenti ricevono un segnale di avvertimento quando cercano di accedere al loro sito solo HTTP preferito (ad esempio un giornale o qualche blog), dovresti insegnargli a ignorare l'avviso, perché può ancora essere OK in questo caso. Dire agli utenti di ignorare gli avvisi è generalmente un'idea pessima, a meno che tu non sia veramente sicuro che capiscano davvero ignorare quell'avviso è OK, ma ignorare gli altri no.

Gli avvisi sono buoni, ma numerosi avvisi per relativamente bassi- i problemi di rischio sono contro-efficaci, perché è probabile che gli utenti ignorino tutti gli avvisi (soprattutto se non li comprendono appieno).

Non molti utenti non tecnologici cercano di comprendere le implicazioni di Firefox avviso per un certificato non valido, ad esempio:

Questa connessione non è affidabile

Hai chiesto a Firefox di connettersi in modo sicuro a some.site.example, ma non possiamo confermare che la tua connessione è sicura.

Normalmente, quando provi a connetterti in modo sicuro, i siti presenteranno un'identificazione affidabile per dimostrare che stai andando nel posto giusto. Tuttavia, l'identità di questo sito non può essere verificata. Cosa devo fare?

Se di solito ti connetti a questo sito senza problemi, questo errore potrebbe significare che qualcuno sta cercando di impersonare il sito e tu non dovresti continuare.

Sono tre paragrafi che molti utenti non si prenderanno la briga di leggere, almeno non ogni volta che lo incontrano, se succede troppo spesso.

La differenza principale con un semplice sito HTTP è che il semplice sito HTTP non pretende di offrire una connessione sicura. Supponendo che tu possa spiegarlo in un altro messaggio di tre paragrafi in modo simile. Sarebbe abbastanza comune, anche per gli utenti esperti di tecnologia, essere distratti e non leggere queste spiegazioni per intero prima di scegliere di procedere.

Molti siti usano http: // per https: // reindirizzamenti, a volte con codice di stato 301 (permanente) o con HSTS. HSTS precaricato è ottimo ma raro, HSTS alla prima connessione è un compromesso ragionevolmente buono.

Alla fine della giornata, spetterà sempre all'utente aspettarsi che la connessione sia sicura quando appropriato . Il browser può fare solo così tanto, ma spetta all'utente controllare che HTTPS sia in uso quando ha senso farlo e con il sito che si aspetta. Non è particolarmente diverso dalla vita reale: non hai bisogno di controllare il passaporto di tutti quelli con cui parli, ma quando le cose contano, lo fai.

C'è un problema di bootstrap che non può essere comunicato all'interno del regno della tecnologia. Se gli utenti accedono a http://www.gmail.com/ , dovrebbero essere reindirizzati a https://www.gmail.com/ o forse https://mail.google.com/ o https://accounts.google.com/ . È una conoscenza fuori banda che dice loro che dovrebbero aspettarsi HTTPS su Gmail e che Gmail è gestito da Google. (La stessa conoscenza fuori banda che dice loro che HTTPS esiste anche ...)

Se non vengono reindirizzati, a un sito HTTPS gestito da Google (Gmail o login), questo è ciò che dovrebbe suonare il campanello d'allarme con loro. Mentre un meccanismo automatizzato potrebbe funzionare per un numero limitato di siti noti, è difficile immaginare un sistema che funzioni in generale. In caso contrario, è comunque necessario che l'utente abbia la responsabilità di: (a) sapere quando aspettarsi HTTPS, (b) controllare che HTTPS sia utilizzato e (c) verificare che si trovino effettivamente sul sito che desidera. (Sfortunatamente, alcuni browser, specialmente sui dispositivi mobili, rendono queste informazioni un po 'meno visibili.)

A mio parere, è più facile insegnare a un utente questi tre punti che insegnargli a leggere i dettagli del avvisi che potrebbero comunque scegliere di ignorare.

Naturalmente, potresti immaginare in futuro un mondo in cui tutti i siti utilizzino HTTPS. Non sono ancora del tutto convinto che sia necessario. Anche i siti dannosi possono ottenere il certificato, quindi gli utenti dovranno comunque assumersi la responsabilità di controllare che si trovino comunque sul sito che intendevano visitare.

Cercare di insegnare che HTTP semplice "non è normale" è semplicemente spingendo il problema al livello successivo. Un Web interamente HTTPS può essere un peso per i fornitori di servizi, pur non fornendo necessariamente i vantaggi che ti aspetti.

Nvidiot
2015-02-18 20:58:01 UTC
view on stackexchange narkive permalink

L'EFF ha un plugin per Firefox (incluso Android), Chrome e Opera. Si chiama HTTPS Everywhere e utilizza regole per assicurarti di finire sul sito giusto. Ad esempio, riscriverà example.com in https://secure.example.com/ se sa che la versione https risiede solo su secure.example.com. Sostituisce anche gli URL all'interno dei link, ecc.

https://www.eff.org/Https-everywhere

In effetti, ma è un po 'gratuito: forza HTTPS su tutte le richieste ma solo su un insieme di siti elencati. L'effetto è simile a HSTS (con precarico) tranne per il fatto che non è stato approvato dal webmaster. Sto parlando di influenzare tutti gli URL ma solo quando digitato senza uno schema. Il plug-in "[KB SSL Enforcer] (https://code.google.com/p/kbsslenforcer/wiki/FAQ)" è più simile: prova HTTPS (con soft fail su HTTP) al primo accesso e se ha successo "blocca" il sito su HTTPS sempre forzato.
Esiste inoltre un plug-in che prova i siti Web con HTTPS, vede se funzionano e, in tal caso, li aggiunge di regola al browser. https://code.google.com/p/https-finder/ - entrambi insieme significheranno che per qualsiasi sito Web che supporta HTTPS, utilizzerai HTTPS.
RoraΖ
2015-02-17 01:54:34 UTC
view on stackexchange narkive permalink

In questo momento i browser utilizzano HTTP per impostazione predefinita perché è ciò che è stato fatto per decenni. Non è responsabilità del browser assicurarsi che il sito Web sia sicuro. Si basa sul sito Web per eseguire il reindirizzamento appropriato e supportare HTTPS. Digitando google.com verrà reindirizzato alla versione HTTPS senza problemi. Se un sito Web supporta HTTPS, dovrebbe eseguire il reindirizzamento appropriato. Il browser deve essere robusto.

Se il sito supporta entrambi, è come dire che la tua backdoor è lasciata aperta, ma la tua porta principale è chiusa a chiave.

Non sono d'accordo con la tua ultima frase. https non protegge il sito, protegge il visitatore. Forse un'analogia migliore sarebbe: "Entra nel nostro ufficio polveroso. Ecco una maschera per la respirazione che puoi indossare se hai allergie, asma o sei solo sensibile alla polvere. Ma se entri nella stanza X, le maschere per la respirazione sono necessarie per tutti , poiché abbiamo fumi tossici lì dentro. "
Ma quel reindirizzamento non protegge dagli attacchi mitm, perché l'attaccante può semplicemente sostituire il reindirizzamento con una risposta dall'aspetto legittimo senza sicurezza.
Non chiamerei qualcosa che è vulnerabile a SslStrip "benissimo". I siti web non possono reindirizzare in modo sicuro da http a https. HSTS tenta di migliorare un po 'la situazione, ma funziona in modo affidabile solo per i siti che sono stati inclusi in un elenco fornito con il browser (precaricato).
user283885
2015-02-17 07:55:55 UTC
view on stackexchange narkive permalink

Perché i computer erano deboli e la crittografia era affamata di CPU e larghezza di banda Internet e considerata come superflua nell'infanzia di Internet. Fondamentalmente impacchettate http in un altro strato e lo spingete oltre il tubo. Questo livello extra deve fare il suo tango cerimoniale per funzionare, il che significa CPU extra, viaggi di andata e ritorno extra, bandiwdth extra .. Ma le cose stanno cambiando, ad esempio le versioni recenti di Chrome per impostazione predefinita proveranno https al giorno d'oggi. , tuttavia, dovresti impostare un reindirizzamento come unico contenuto web servito su detto dominio che indirizza il browser al sapore https del sito.

"le versioni recenti di Chrome per impostazione predefinita proveranno https al giorno d'oggi" - hai altri dettagli in merito? Forse intendi provare SPDY per impostazione predefinita (che AFAIK accade solo su un URL HTTPS)?
Il tentativo di utilizzare https non aiuta contro un utente malintenzionato attivo se il browser torna silenziosamente a un http non sicuro se https non ha funzionato.
No, voglio dire ho appena scaricato google chrome da windows, vai nella barra e digita www.google.com/www.facebook.com e così via .. poi il browser si connette automaticamente su https. Il motivo per cui penso che sia il browser a farlo è perché ho siti locali su cui lavoro, senza https abilitato, e se vado semplicemente su ip, mi darà una pagina non trovata. Se voglio http, devo specificarlo esclusivamente come `http: // 192.168.X.X`. Non sto parlando di sicurezza qui o di protezione dagli attacchi. Questa non era la sua domanda. Stavo precisando rigorosamente che https non è stato utilizzato a causa del sovraccarico che impone.
Vorrei anche aggiungere che https costa più soldi. Un buon certificato SSL (che abilita https) può superare un paio di centinaia di $$ all'anno. Questo e il fatto che devi pagare per più larghezza di banda, più potenza della CPU e più ram per ospitare HTTPS solleva la questione del perché preoccuparsi di un sito web come stackexchange o wikipedia per quella materia. La maggior parte delle informazioni sono comunque pubbliche e non guadagnano nemmeno molti soldi dal sito web. Chi pagherà per la maggiore sicurezza?
@user283885 Per la maggior parte dei siti Web è sufficiente un semplice certificato convalidato dal dominio e in genere costano meno di $ 10 all'anno. Anche i certificati jolly non sono "ben oltre un paio di centinaia di $$". Anche l'impatto sulle prestazioni non è così grande. Per la maggior parte dei siti Web, il costo di gran lunga maggiore è il tempo impiegato per configurare SSL.
@user283885 Questo non è più vero: https://letsencrypt.org/
colmde
2015-02-17 15:07:10 UTC
view on stackexchange narkive permalink

Qualsiasi sito web che richiede sicurezza dovrebbe reindirizzare automaticamente da http: // a https: //. Ciò renderebbe ridondante il requisito per il browser di visualizzare automaticamente https: // ed è una soluzione più semplice rispetto al reindirizzamento da https a http per i siti senza certificati.

Questo è qualcosa che non dovrebbe essere fatto comunque, il che significa che il browser dovrebbe inserire avvisi di sicurezza, disturbando inutilmente l'utente come quei fastidiosi avvisi sui cookie, ecc.

Il reindirizzamento da http a https perde la maggior parte dei vantaggi di sicurezza di https.
Veramente? Come mai? (BTW intendo reindirizzarli non appena arrivano sul sito, quindi quando arrivano alla schermata della carta di credito o qualunque cosa sia, sono ben all'interno di https)
Un utente malintenzionato MitM può semplicemente rispondere a quella prima richiesta non protetta e omettere il reindirizzamento. A meno che l'utente non si accorga di non essere stato reindirizzato (la maggior parte non lo farà), l'aggressore sarà in grado di mostrargli quello che vuole.
@CodesInChaos - Non sono d'accordo sul fatto che "LA MAGGIOR PARTE dei vantaggi per la sicurezza di https" è prevenire gli attacchi MITM. Penso che il vantaggio principale di https sia evitare il traffico rilevato, non lo scenario che hai descritto. Inoltre, nel tuo scenario il MITM può bypassare completamente il sito reale e HTTPS non farebbe nulla per impedirlo. Se stai sostenendo che l'utente non si accorgerebbe di non essere passato a https, probabilmente non noterebbe nemmeno che l'ingresso iniziale al sito non era https.


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