C'è qualche motivo per non applicare HTTPS su un sito Web?

Un sito Web che frequento alla fine ha deciso di abilitare TLS sui propri server, solo per non imporlo come fanno molti siti Web. Il manutentore afferma che TLS deve essere facoltativo. Perché?

Sul mio sito Web ho impostato a lungo TLS e HSTS obbligatori con lunghi periodi e le suite di crittografia più deboli sono disabilitate. L'accesso al testo in chiaro è garantito per essere murato con un HTTP 301 alla versione protetta da TLS. Ciò influisce negativamente sul mio sito Web?

Esistono diversi buoni motivi per utilizzare TLS

(e solo pochi motivi marginali per non farlo).

• Se il sito ha un'autenticazione, l'utilizzo di HTTP expose per rubare sessioni e password.

• Anche su siti statici, puramente informativi, l'utilizzo di TLS garantisce che nessuno abbia manomesso i dati.

• Da Google I / O 2014 , Google ha adottato diverse misure per incoraggiare tutti i siti a utilizzare HTTPS:

  • Google ha aiutato i webmaster a configurare i propri server in modo più sicuro, ma ha anche usato HTTPS come segnale di classifica .
  • Più recentemente, Google Chrome ha iniziato a contrassegnare i siti HTTP come non sicuri , come parte di un piano a lungo termine per contrassegnare tutti i siti HTTP come non sicuri .
  • La conferenza Mythbusting HTTPS del team di sviluppatori di Google Chrome indica chiaramente il loro atteggiamento.

• Il blog sulla sicurezza di Mozilla ha inoltre annunciato la deprecazione dell'HTTP non sicuro rendendo disponibili tutte le nuove funzionalità solo per proteggere i siti Web e gradualmente eliminando l'accesso alle funzionalità del browser per i siti Web non sicuri, in particolare quelle che comportano rischi per la sicurezza e la privacy degli utenti .

Ci sono anche diversi buoni motivi per applicare TLS

Se hai già un certificato ampiamente attendibile, perché non utilizzarlo sempre? Praticamente tutti i browser attuali supportano TLS e hanno i certificati root installati. L'unico problema di compatibilità che ho visto negli anni sono stati i dispositivi Android e l' autorità di certificazione intermedia mancante poiché Android si fida solo delle CA principali. Ciò può essere facilmente evitato configurando il server per inviare la catena di certificati alla CA principale.

Se il tuo manutentore desidera ancora consentire connessioni HTTP senza dirette 301 Moved Permanently, per esempio per garantire l'accesso da alcuni browser o dispositivi mobili molto vecchi, non c'è modo per il browser di sapere che hai persino configurato HTTPS . Inoltre, non è necessario distribuire HTTP Strict Transport Security (HSTS) senza 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

Il problema dei vari siti configurati per entrambi i protocolli è riconosciuto da The Tor Project e dalla Electronic Frontier Foundation e affrontato da un'estensione multi-browser HTTPS Everywhere :

Molti siti Web offrono un supporto limitato per la crittografia su HTTPS, ma ne rendono difficile l'utilizzo. Ad esempio, potrebbero essere predefiniti in HTTP non crittografato o riempire pagine crittografate con collegamenti che risalgono al sito non crittografato.

Anche il contenuto misto era un grosso problema a causa di possibili attacchi XSS ai siti HTTPS attraverso la modifica di JavaScript o CSS caricati tramite una connessione HTTP non sicura. Pertanto al giorno d'oggi tutti i browser tradizionali avvertono gli utenti di pagine con contenuti misti e si rifiutano di caricarli automaticamente. Ciò rende difficile mantenere un sito senza i 301reindirizzamenti su HTTP: è necessario assicurarsi che ogni pagina HTTP carichi solo contect HTTP (CSS, JS, immagini ecc.) E che ogni pagina HTTPS carichi solo contenuto HTTPS. È estremamente difficile da ottenere con lo stesso contenuto su entrambi.

Al giorno d'oggi, TLS + HSTS indicano che il tuo sito è gestito da professionisti di cui ci si può fidare per sapere cosa stanno facendo. Questo è uno standard minimo emergente per la tracciabilità, come dimostrato da Google che fornirà un posizionamento positivo per i siti che lo fanno.

All'altra estremità c'è la massima compatibilità. Ci sono ancora clienti più anziani là fuori, specialmente in parti del mondo che non sono gli Stati Uniti, l'Europa o la Cina. Il semplice HTTP funzionerà sempre (anche se non sempre funziona bene ; questa è un'altra storia).

TLS + HSTS: ottimizza per il posizionamento nei motori di ricerca
Plain HTTP: ottimizza per la compatibilità

Dipende da ciò che conta di più per te.

C'è un buon motivo per cui i siti Web di sola lettura non utilizzano HTTPS.

• Le cache Web non possono memorizzare nella cache le immagini trasportate su HTTPS.
• Alcune parti del mondo hanno connessioni internazionali a bassissima velocità, quindi dipendono dalle cache.
• L'hosting di immagini da un altro dominio richiede competenze che non puoi aspettarti dagli operatori di siti Web di sola lettura .

Il manutentore afferma che TLS deve essere facoltativo. Perché?

Per conoscere veramente la risposta a questa domanda, è necessario chiedere loro. Possiamo, tuttavia, fare alcune ipotesi.

Negli ambienti aziendali, è comune che l'IT installi un firewall che ispeziona il traffico in entrata e in uscita alla ricerca di malware, attività sospette simili a CnC, contenuti ritenuti inappropriati per il lavoro (ad es. Pornografia), ecc. Questo diventa molto più difficile quando il traffico è crittografato. Esistono essenzialmente tre possibili risposte:

1. Rinuncia al monitoraggio di questo traffico.
2. Installare una CA principale sui computer degli utenti in modo da poter eseguire la decrittazione e l'ispezione di MitM.
3. Blocco all'ingrosso del traffico crittografato.

Per un amministratore di sistema interessato, nessuna di queste opzioni è particolarmente allettante. Esistono molte minacce che attaccano una rete aziendale ed è loro compito proteggere l'azienda da esse. Tuttavia, il blocco di molti siti aumenta completamente l'ira degli utenti e l'installazione di una CA principale può sembrare un po 'scadente, poiché introduce considerazioni sulla privacy e sulla sicurezza per gli utenti. Ricordo di aver visto (scusate, non riesco a trovare la discussione) una petizione sysadmin reddit quando stavano accendendo HSTS per la prima volta perché si trovava esattamente in questa situazione e non voleva bloccare tutto reddit semplicemente perché era costretto dal business per bloccare i subreddit incentrati sul porno.

Le ruote della tecnologia continuano a ribollire e troverete molti che sostengono che questo tipo di protezione è vecchio stile e dovrebbe essere gradualmente eliminato. Ma ci sono ancora molti che lo praticano, e forse sono loro quelli a cui si preoccupa il tuo misterioso manutentore.

Tutto dipende dai requisiti di sicurezza, dalla scelta dell'utente e dal rischio di downgrade implicito. La disabilitazione delle vecchie cifrature lato server è in gran parte necessaria perché i browser passeranno felicemente a cifrature assolutamente orribili lato client in nome dell'esperienza / convenienza dell'utente. Accertarsi che nulla del tuo che dipenda da un canale sicuro per l'utente non possa essere raggiunto con un metodo insicuro è, ovviamente, anche molto valido.

Non permettermi di effettuare il downgrade esplicito a HTTP non sicuro quando ho ritenuto che il tuo post sul blog sul perché ti piaccia Python più di Ruby (non dico che lo fai, solo un esempio generico) non è qualcosa che mi preoccupa gli spettri o il pubblico che lo sa Ho avuto modo di accedermi senza motivo, supponendo che HTTPS sarà banale per me.

Esistono, oggi, sistemi embedded che non hanno la possibilità di usare TLS out of the box, o quelli che sono bloccati su vecchie implementazioni (penso che sia terribilmente male che sia così, ma come un potente utente di [insert embedded dispositivo qui], a volte non posso cambiarlo).

Ecco un esperimento divertente: prova a scaricare una versione recente di LibreSSL dal sito OpenBSD upstream su HTTPS con un'implementazione TLS / SSL sufficientemente vecchia. Non sarai in grado di farlo. Ho provato l'altro giorno su un dispositivo con una build OpenSSL precedente a partire dal 2012 o giù di lì, perché volevo aggiornare questo sistema incorporato a roba più sicura e nuova dalla fonte - non ho il lusso di un pacchetto predefinito. I messaggi di errore quando ho provato non erano esattamente intuitivi, ma presumo fosse perché il mio vecchio OpenSSL non supportava le cose giuste.

Questo è un esempio in cui la mossa che l'unico-HTTPS può effettivamente danneggiare le persone: se non hai il lusso dei recenti pacchetti pre-costruiti e vuoi risolvere tu stesso il problema costruendo dal sorgente, sei bloccato. Per fortuna, nel caso di LibreSSL, puoi tornare indietro a richiedere esplicitamente HTTP. Certo, questo non ti salverà da un utente malintenzionato che sta già riscrivendo il tuo traffico, in grado di sostituire i pacchetti sorgente con versioni compromesse e riscrivere tutti i checksum nei corpi HTTP descrivendo i pacchetti disponibili per il download sulle pagine Web che navighi, ma è ancora utile in molti caso più comune.

La maggior parte di noi non è un download non protetto lontano da essere di proprietà di un APT (Advanced Persistent Thread: gergo di sicurezza per agenzie di intelligence nazionali e altre minacce informatiche estremamente ben fornite). A volte voglio solo wgetuna semplice documentazione di testo o un piccolo programma la cui fonte posso controllare rapidamente (le mie piccole utilità / script su GitHub, per esempio) su una scatola che non supporta le suite di crittografia più recenti.

Personalmente, lo chiederei: i tuoi contenuti sono tali che una persona possa legittimamente decidere "Sono d'accordo con me accedendo come conoscenza pubblica"? Esiste una plausibile possibilità di rischio reale per le persone non tecniche che effettuano il downgrade accidentale a HTTP per i tuoi contenuti? Valutare i requisiti di sicurezza, i requisiti di privacy obbligatoria per i propri utenti e il rischio di downgrade impliciti rispetto alla capacità degli utenti che comprendono i rischi di effettuare una scelta informata caso per caso per non essere garantiti. È del tutto legittimo affermare che per il tuo sito non ci sono buoni motivi per non applicare HTTPS, ma penso sia giusto dire che ci sono ancora buoni casi d'uso per il semplice HTTP.

C'è un sacco di discussioni qui sul perché tls è buono - ma questo non è mai stato chiesto come nel post originale.

Maxthon ha fatto 2 domande:

1) perché ha un sito casuale, senza nome, deciso di mantenere presenze sia http che https

2) C'è un impatto negativo su Maxthon che serve solo 301 risposte a richieste http

Per quanto riguarda la prima domanda, non sappiamo perché i provider abbiano scelto di conservare sia i siti http che https. Potrebbero esserci molte ragioni. Oltre ai punti sulla compatibilità, la memorizzazione nella cache distribuita e alcuni suggerimenti sull'accessibilità geo-politica, c'è anche una considerazione sull'integrazione dei contenuti ed evitare brutti messaggi del browser sul contenuto non sicuro. Come ha sottolineato Alvaro, TLS è solo la punta dell'iceberg in termini di sicurezza.

La seconda domanda, tuttavia, è responsabile. Esporre qualsiasi parte del tuo sito Web tramite http quando in realtà richiede https per un funzionamento sicuro fornisce un vettore sfruttabile per gli attacchi. Tuttavia ha senso mantenerlo al fine di identificare dove il traffico viene indirizzato in modo errato alla porta 80 sul tuo sito e correggere la causa. Cioè c'è sia un impatto negativo sia l'opportunità di un impatto positivo, il risultato netto dipende dal fatto che tu stia facendo il tuo lavoro come amministratore.

Sysadmin1138 afferma che https influisce sulle classifiche seo. Mentre Google ha affermato che influenza le classifiche, gli unici studi affidabili che ho visto suggeriscono che la differenza è piccola. Ciò non è aiutato dalle persone che dovrebbero sapere meglio sostenendo che, poiché i siti più quotati hanno maggiori probabilità di avere una presenza https, una presenza https migliora quindi le classifiche.

In passato, ho dovuto usare HTTP piuttosto che HTTPS perché volevo <embed>pagine da altrove che sono state servite su HTTP e non funzionerebbero diversamente.

Questo non è un buon motivo, in quanto significa che hai client danneggiati / rotti / insicuri, ma se ci sono processi automatizzati che accedono alle risorse tramite gli http://URL esistenti , è possibile che alcuni di essi non supportino nemmeno https (es. Busybox wget, che non non ha il supporto TLS internamente e lo ha aggiunto solo più recentemente tramite un processo figlio di openssl) e si interromperebbe se gli fosse stato assegnato un reindirizzamento a un URL https che non potevano seguire.

Sarei tentato di affrontare questa possibilità scrivendo la regola di reindirizzamento per escludere le stringhe User-Agent sconosciute (o note legacy) dal reindirizzamento e consentire loro di accedere al contenuto tramite http se lo desiderano, in modo che tutti i browser effettivi possano trarre vantaggio da https / hsts forzato.

Esistono pochissimi buoni motivi per utilizzare HTTP anziché HTTPS su un sito Web. Se il tuo sito web gestisce transazioni di qualsiasi tipo o memorizza qualsiasi tipo di dati sensibili o personali, devi assolutamente utilizzare HTTPS se vuoi che tali dati siano sicuri. L'unica ragione decente che vedrei per non applicare HTTPS è se il tuo sito Web si basa sulla memorizzazione nella cache in quanto HTTPS non funziona con la memorizzazione nella cache. Tuttavia, spesso vale la pena sacrificare un po 'di prestazioni al fine di garantire la sicurezza del tuo sito Web. È anche possibile che i tuoi clienti non supportino HTTPS, ma in realtà, nel 2017, dovrebbero.