Perché i browser hanno l'impostazione predefinita per http: e non https: per gli URL digitati? [duplicare]

Bene, posso presumere che esistano alcune ragioni:

1. Il supporto HTTPS non viene automaticamente configurato sui siti web. Pertanto, perché i browser dovrebbero supporre che sia?
2. Dicendo che un sito Web non è accessibile a meno che l'utilizzo di uno schema specifico non sia superiore a un numero significativo di utenti.
3. Passare a HTTPS non è così semplice come sembra in alcuni casi. Take Stack Exchange ad esempio.

Per quanto riguarda la visualizzazione di siti Web insicuri in rosso, già in corso .

Google Chrome ha la seguente cronologia per dare errori su siti web non sicuri:

1. Chrome 46

   Chrome will mark the “HTTPS with Minor Errors” state using the same neutral page icon as HTTP pages.

2. Chrome 56

   mark HTTP pages that collect passwords or credit cards as non-secure

3. Chrome 62

   Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode.

4. Chrome 68

   the omnibox will display “Not secure” for all HTTP pages.

I browser sono applicazioni per gli utenti finali. Sebbene la maggior parte dei siti sia disponibile tramite http (anche se si limitano a reindirizzare a https), una parte significativa non è disponibile da https. Pertanto la tua proposta interromperà la navigazione in Internet per una parte molto ampia degli utenti. Si romperà in un modo che non capiscono. Declassare automaticamente su http se fallisce https non avrebbe senso perché un utente malintenzionato potrebbe quindi semplicemente causare il caos con le connessioni alla porta 443 per imporre il downgrade.

Una volta che solo pochi siti insignificanti sono passati a https, è possibile passare a un valore predefinito più sicuro, ma non ancora. Gli utenti finali non capiscono cosa è successo e probabilmente passano a un browser alternativo o ottengono alcuni suggerimenti da qualche parte su Internet per riprendere il vecchio comportamento.

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

C'è un problema più grande in gioco che impedirebbe il tuo suggerimento. Il modo in cui molti web server sono attualmente configurati, si potrebbe effettivamente finire sul sito sbagliato se si è impostato su https. Questo non è vero se si imposta automaticamente http.

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

http://site.a.com
http://site.b.com
https://site.c.com

Su molti server, se dovessi tentare di andare a https://site.a.com , (invece di http), in effetti guarderai al sito C, ma con un errore di certificato.

Penso che ci sia il vero pericolo di confondere un sacco di utenti, il che renderebbe la situazione ancora peggiore. Provare HTTPS ovunque non è necessariamente una cattiva idea, ma deve esserci una sorta di piano di fallback per l'utente quando HTTPS non è disponibile.

Molti utenti non sono interessati ai segnali di pericolo, vogliono solo il loro contenuto. In molti casi, la protezione del traffico derivante da intercettazioni o attacchi MITM non è strettamente necessaria, o almeno il rischio e le conseguenze sono molto inferiori a un certificato errato sulla tua banca.

In sostanza, se gli utenti ricevono un segnale di avvertimento quando cercano di raggiungere il loro sito preferito HTTP (ad esempio un giornale o qualche blog), devi insegnargli a ignorare l'avviso , perché può ancora essere OK in questo caso. Dire agli utenti di ignorare gli avvertimenti è in genere una pessima idea, a meno che non si accerti davvero che capiscano davvero di ignorare che l'avviso è OK, ma ignorare gli altri non lo è.

Le avvertenze sono buone, ma numerosi avvisi per problemi relativamente a basso rischio sono contro-efficaci, perché è probabile che gli utenti ignorino tutti gli avvertimenti (specialmente se non li capiscono completamente).

Non molti utenti non tecnologici cercano di capire le implicazioni dell'avviso di Firefox per un certificato errato, ad esempio:

This Connection is Untrusted

You have asked Firefox to connect securely to some.site.example, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified. What Should I Do?

If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

Questo è di tre paragrafi molti utenti non si preoccuperanno di leggere, almeno non ogni volta che lo incontrano, se succede troppo spesso.

La principale differenza 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 utilizzano reindirizzamenti http:// a https:// , a volte con codice di stato 301 (permanente) o con HSTS. L'HST precaricata è ottima ma rara, l'HSTS sulla prima connessione è un compromesso ragionevolmente buono.

Alla fine della giornata, sarà sempre l'utente a prevedere che la connessione sia sicura quando appropriato. Il browser può fare così tanto, ma spetta all'utente controllare che HTTPS sia in uso quando ha senso farlo e con il sito che si aspettano. Non è particolarmente diverso dalla vita reale: non devi controllare il passaporto di tutti quelli con cui parli mai, ma quando le cose sono importanti, lo fai.

C'è un problema di bootstrap che non può essere trasmesso nell'ambito della tecnologia. Se gli utenti vanno a http://www.gmail.com/ , devono 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 out-of-band che dice loro che esiste anche HTTPS ...)

Se non vengono reindirizzati, su un sito HTTPS gestito da Google (Gmail o login), questo è ciò che dovrebbe suonare con loro i campanelli d'allarme. 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 usato e (c) verificare che siano effettivamente sul sito che desiderano. (Sfortunatamente, alcuni browser, specialmente su dispositivi mobili, rendono le informazioni un po 'meno visibili.)

A mio parere, è più facile insegnare a un utente questi tre punti piuttosto che insegnare loro a leggere i dettagli degli avvertimenti che potrebbero scegliere di ignorare comunque.

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

Cercare di insegnare che il semplice HTTP è "non normale" sta semplicemente spingendo il problema al livello successivo. Un web all-HTTPS può essere un onere per i fornitori di servizi, pur non offrendo necessariamente i vantaggi che ci si aspetta.

Il EFF ha un plugin per Firefox (incluso Android), Chrome e Opera. Si chiama HTTPS Everywhere e utilizza le regole per assicurarsi di finire nel sito giusto. Ad esempio, riscriverà example.com al link se sa che la versione https vive solo su secure.example.com. Sostituisce anche gli URL all'interno dei link ecc.

link

In questo momento i browser usano HTTP di default perché è ciò che è stato fatto per decenni. Non è responsabilità del browser assicurarsi che il sito Web sia sicuro. Si affida al sito Web per effettuare il reindirizzamento appropriato e supportare HTTPS. Digitando google.com verrà reindirizzato alla versione HTTPS bene. Se un sito Web supporta HTTPS, dovrebbe presentare il reindirizzamento appropriato. Il browser deve essere robusto.

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

Poiché i computer erano deboli e la crittografia era cpu e affamata di larghezza di banda Internet e considerata come non all'altezza nell'infanzia di Internet. Fondamentalmente impacchetta http in un altro livello e la infili sopra il tubo. Questo strato in più deve fare il proprio tango cerimoniale per funzionare, il che significa cpu extra, viaggi round extra, bandi aggiuntivi. Ma le cose stanno cambiando, ad esempio le versioni recenti di Chrome di default proveranno https al giorno d'oggi. Sul lato server, tuttavia, è necessario impostare un reindirizzamento come unico contenuto Web pubblicato su detto dominio che indirizza il browser al gusto https del sito.

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

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