In realtà, non è male reindirizzare http a https? [duplicare]

Il reindirizzamento da HTTP a HTTPS non è una cosa negativa. Ciò che è male si basa su di esso come se fosse una funzionalità di sicurezza.

Questo reindirizzamento è un faro, pensato per consentire alle navi disperse in mare nella tempesta di capire dove si trovano e, con un po 'di fortuna, dare loro una migliore possibilità di raggiungere un rifugio sicuro. Nessuno sostiene che i fari facciano scomparire la tempesta; semplicemente migliorano le probabilità di un lieto fine per cattive condizioni.

L'unica cosa negativa che si può dire su un reindirizzamento automatico da HTTP a HTTPS è che genera compiacenza . Se un utente sbaglia, ad es. tentando di accedere al sito Web come HTTP anziché HTTPS, il reindirizzamento automatico gli consente di persistere nei suoi modi errati, nascondendo il fatto che il suo URL inappropriato lo ha esposto alla vendicatività degli abitanti di Internet, alcuni a volte piuttosto proattivamente malvagi. Disabilitare questo reindirizzamento potrebbe essere interpretato come più pedagogico . Tuttavia, questo punto di vista è alquanto irrealistico; la maggior parte dei proprietari di siti Web non è in grado di educare gli utenti . Quello che vogliono è attirare l'attenzione dei potenziali clienti . Se inizi a rendere più difficile l'accesso al tuo sito Web, allora se ne andranno; non saranno educati nel minimo modo, e gli affari ne soffriranno.

"Ciò che non ci uccide ci rende più forti." Una frase orecchiabile di un filosofo pazzo più della metà; ma non necessariamente applicabile al pubblico come politica educativa. Il problema di rendere le persone più forti cercando di ucciderli è che a volte riesci - per ucciderle, intendo.

Come spiega mr spuratic, per rendere le cose davvero migliori, il browser dovrebbe usare HTTPS di default; idealmente, l'intero Web sarebbe solo HTTPS: se i browser provano prima HTTPS ma ricadono su HTTP in caso di errori, un utente malintenzionato attivo può simulare l'errore e forzare un fallback. DNSSEC accoppiato con i record SRV appropriati potrebbe pubblicizzare, in modo sicuro, che un determinato server dovrebbe essere usato solo con HTTPS, ma funzionerà in modo affidabile solo quando ... funzionerà ovunque (lo stesso problema di bootstrap di IPv6).

Nel frattempo, un reindirizzamento porterà pecore randagi alla stalla anche quando le pecore sono completamente all'oscuro delle bestie selvagge che vagano nelle campagne notturne. Questo è generalmente considerato un metodo più efficiente rispetto al cercare di insegnare alle pecore a non allontanarsi.

Il problema è duplice:

• Oggi, non esiste un modo per un sito Web (o un altro servizio) per lo stato definitivamente (ad esempio tramite DNS autenticato) che offra solo un servizio HTTPS (sicuro) , mai HTTP. I record di servizio ( _srv ) non fanno il lavoro (anche se il problema non è stato ignorato del tutto, vedi la voce https qui ), e HSTS ha un problema inevitabile . Il reindirizzamento iniziale da HTTP a HTTPS è un male necessario oggi. HTTPS Everywhere (prova prima HTTPS) è tecnicamente una soluzione migliore, sebbene qualsiasi soluzione che richieda l'attivazione da parte dell'utente e / o un livello non banale di competenza dell'utente sia criticamente limitata. sslstrip rimarrà attivo fino a quando non viene risolto. (DNSSEC ha un problema di bootstrap simile e farà fino al 99% dei domini firmati e il 100% dei risolutori si aspetta che il DNS sia spesso l'elefante nella stanza.)
• Oltre al problema del reindirizzamento (efficace) non autenticato, il reindirizzamento trasparente incondizionato a HTTPS può nascondere potenziali problemi (ad es. generazione di applicazioni di URL assoluti con il protocollo errato: // prefisso quando un HTTPS chiude il bilanciamento del carico / reverse-proxy è in uso). Gli attributi di sicurezza dei cookie come "sicuro" sono di tipo cerotto. Le funzionalità per mantenere una sessione HTTPS rigorosamente HTTPS sono imperfette.

Per mezzo di un esperimento mentale: immagina se un client SSH è utile e silenzioso, prima ha provato Telnet. Cosa accadrebbe se una connessione SSH potesse trasformarsi in modo quasi invisibile nella connessione telnet a metà? Quanto è popolare questo cliente tra i responsabili della sicurezza? Se ha sempre "funzionato" (e ha avuto plugin / temi, ecc.), Quanto sarebbe popolare tra l'agnostico della sicurezza? In che modo questo ^† è diverso da un browser moderno?

_{^† Oltre ai requisiti di memoria improbabili, incongruenze UI gratuite e incessanti aggiornamenti in background; questi dovrebbero essere ovvi.}

Is it bad to redirect http to https?

HTTPS è buono, ma basarsi sul reindirizzamento per passare attraverso un trasporto non autenticato, non crittografato e non verificabile indica un grado di ottimismo solitamente associato ai clienti delle lotterie nazionali.

redirecting HTTP to HTTPS is a terrible idea[...]?

Non completamente vero. Un utente che osserva sempre gli indicatori dell'interfaccia utente HTTPS ha ragionevoli motivi per credere di essere nel posto giusto e di avere alcune protezioni. Sospetto tuttavia che questo non sia l'utente modale.

Ciò che è cattivo è un amministratore che conclude in modo ingenuo che l'abilitazione di HTTPS in qualche modo risolve tutti i problemi di sicurezza più comuni.

Quella fastidiosa triade di autenticazione , integrità , confidenzialmente è davvero tutto o niente ...

TL; DR: non è un'idea terribile , quasi certamente non risolve i problemi che si potrebbero sperare, ma non ci sono alternative valide che li risolvano. Appoggiare semplicemente questo sui tuoi utenti probabilmente avrà solo un impatto su una frazione insignificante di loro; condurre una campagna e istruire i tuoi utenti ti porterà molto ulteriormente.