it-swarm.dev

Perché alcuni siti Web impongono la mancanza di SSL?

Quando ho provato a visitare https://www.ebay.com , ho notato che venivo reindirizzato immediatamente a HTTP. Ecco cosa dice cURL al riguardo:

$ curl --max-redirs 0 -v -L https://www.ebay.com
* Rebuilt URL to: https://www.ebay.com/
* Adding handle: conn: 0x6c8cc0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x6c8cc0) send_pipe: 1, recv_pipe: 0
* About to connect() to www.ebay.com port 443 (#0)
*   Trying 66.135.210.61...
* Connected to www.ebay.com (66.135.210.61) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_MD5
* Server certificate:
*       subject: CN=www.ebay.com,OU=Site Operations,O=eBay Inc.,L=San Jose,ST=California,C=US
*       start date: Jun 06 00:00:00 2013 GMT
*       expire date: Jun 07 23:59:59 2014 GMT
*       common name: www.ebay.com
*       issuer: CN=VeriSign Class 3 Secure Server CA - G3,OU=Terms of use at https://www.verisign.com/rpa (c)10,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
> GET / HTTP/1.1
> User-Agent: curl/7.32.0
> Host: www.ebay.com
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Location: http://www.ebay.com/
* no chunk, no close, no size. Assume close to signal end
< 
* Closing connection 0
* Maximum (0) redirects followed
curl: (47) Maximum (0) redirects followed

Perché i siti Web dovrebbero imporre HTTP in chiaro mentre il loro supporto SSL, esponendo così le abitudini di navigazione dell'utente a intercettazioni?

41
d33tah

Ci sono alcuni motivi (non necessariamente buoni motivi, ma comunque motivi) per preferire HTTP su HTTPS. Se si applicano questi motivi, ha senso applicare l'utilizzo HTTP anche quando il client sembra voler usare HTTPS.

Una (solitamente) cattiva ragione per preferire l'HTTP è quella che viene comunemente pronunciata in un tale dibattito: SSL viene spesso considerato pesante, sia per il costo computazionale della crittografia, sia per le sue conseguenze sulla memorizzazione nella cache (sebbene sia possibile memorizzare nella cache pagine pubblicate su HTTPS, il livello SSL impedisce alcuni trucchi come proxy trasparenti , che sono comunemente applicati dall'ISP). Il costo computazionale è sopravvalutato (era un collo di bottiglia ai tempi delle macchine 3DES e Pentium a 90 MHz con Ethernet veloce, ma da allora le cose sono cambiate). Per quanto riguarda la memorizzazione nella cache, un punto da sottolineare è che è sempre più irrilevante quando le pagine diventano più dinamiche.

Possiamo immaginare, tuttavia, che Ebay voglia incoraggiare il proxy diffuso basato su ISP per tutte le immagini degli articoli che servono. Posso facilmente immaginare che queste immagini assorbano una parte sostanziale della larghezza di banda della rete di Ebay. L'applicazione del semplice HTTP massimizza la probabilità che si verifichi la memorizzazione nella cache, risparmiando così denaro da parte di Ebay.

Un motivo meno negativo per preferire l'HTTP è consentire una più facile scansione automatica dei dati per il contenuto indesiderato e il rilevamento delle intrusioni. SSL è end-to-end, quindi se tale scansione viene applicata in un mondo HTTPS, allora deve avvenire a una delle estremità, il che può essere scomodo in una data architettura di grandi dimensioni.


Per quanto riguarda la privacy delle tue abitudini di navigazione, non credo che Ebay ne abbia fottuto. In effetti, per costruzione, sono piuttosto desiderosi di apprendere, analizzare, profilare e possibilmente vendere le tue abitudini di navigazione (gli inserzionisti pagano per tali informazioni). Quindi non sembra ragionevole aspettarsi davvero che Ebay protegga attivamente la tua privacy, poiché parte del loro modello di business è esattamente l'opposto.

40
Thomas Pornin

Parlando per esperienza personale: ho gestito un sito Web che voleva inviare tutti i dati dei moduli tramite una connessione https sicura. Tuttavia, a causa di una serie di motivi, altre pagine hanno visualizzato contenuti non sicuri che non siamo riusciti a gestire su https.

Ciò ha portato a grandi segnali di avvertimento in Firefox e Chrome (QUESTO SITO CONTIENE ELEMENTI NON SICURI con grida di punti esclamativi nella barra degli indirizzi e simili) che ai non iniziati sembravano spaventosi anche se nulla di sospetto era accadendo.

Per evitare di inviare il messaggio sbagliato, abbiamo semplicemente reindirizzato il traffico su http per le pagine che non hanno inviato alcun dato del cliente.

Ebay sembra fare la stessa cosa: quando i dati vengono effettivamente immessi in un modulo e trasmessi sono sempre https.

Per essere onesti: nel nostro caso mancava il budget per andare su tutte le pagine e correggere gli elementi insicuri che avrebbero dovuto essere davvero la strada da percorrere.

L'unica ragione per cui mi viene in mente potrebbe essere la prestazione: a rigor di termini SSL è più lento.

In breve: posso immaginare ragioni per reindirizzare il traffico su http, ma nel mio caso sicuramente non era la migliore pratica.

22
user3244085

È difficile dare una risposta buona , poiché probabilmente non c'è buona motivo per farlo.

Se dovessi elencare pro e non contro, direi questo:

Se un sito non desidera che gli utenti che provano a visitare il sito tramite https pensino che è inattivo e ha il supporto SSL per alcune funzionalità, come l'accesso, ma pensa che non abbia o non voglia supportare l'infrastruttura che consente a tutti contenuti da passare tramite SSL, quindi potrebbe provare a farlo.

Per molto tempo, era un mito comunemente creduto che SSL richiedesse molto più hardware rispetto al normale HTTP. Una vecchia decisione non può essere rivisitata.

I siti ampiamente memorizzati nella cache avranno un carico minore se i proxy di cache possono sostenere parte del carico, il che è impossibile quando SSL è attivo.

Strumenti di conservazione della larghezza di banda come la compressione facoltativa in Opera e Chrome non funziona con i contenuti pubblicati su SSL.

14
Matthew Elvey

Molto probabilmente manterrà l'utilità della memorizzazione nella cache e ridurrà il carico coinvolto nelle enormi quantità di scansione del ragno necessarie per mantenere aggiornate le ricerche esterne.

La parte negativa non è tanto che una terza parte può vedere quale pagina hai guardato (la rete di utility di analisi installata in tutto il luogo che riporta a Google già garantisce che sei rintracciato quasi ovunque), ma che rimbalza tra HTTP e HTTPS fornisce più punti per indirizzare erroneamente da un sito HTTP non autenticato a un sito HTTPS falso con un certificato falso. Il rischio non è il monitoraggio e la sua non reale esposizione del contenuto sulle pagine HTTP, è che questo tipo di rimbalzo avanti e indietro indebolisce il senso di consapevolezza dell'utente delle minacce.

È molto più difficile per l'utente medio capire che c'è un'apertura spaventosa ogni volta che si verifica HTTPS-> HTTP-> HTTPS, soprattutto perché ciò si verifica per la maggior parte delle persone dopo aver effettuato l'accesso e autenticato se stessi sul server.

"Oh, guarda, è comparso un avviso sul certificato. Strano. Ma sono stato firmato per tutto questo tempo (preme immediatamente il pulsante 'ignora/aggiungi permanentemente eccezione')"

Una soluzione migliore sarebbe quella di rendere tutte le parti del sito pubbliche (visibili agli utenti anonimi) disponibili sia tramite HTTP che HTTPS per rendere felici i motori di ricerca e gli spider che strisciano pagine a basso carico, senza mai reindirizzare nessuno una volta che passano su HTTPS. Se si preoccupassero davvero della sicurezza, tuttavia, non reindirizzerebbero mai automaticamente da HTTP a HTTPS: quel tipo di reindirizzamento automatico è un'opportunità per impostare un attacco MITM ogni volta e anche le banche lo fanno.

1
zxq9

Dal punto di vista dell'esperienza utente, se un utente vede SSL e visualizza la sicurezza, tende a diventare inutilmente cauto.

Ad esempio, se nella pagina iniziale è presente un sito Web con l'immagine di un lucchetto che dice "Siamo sicuri", i tassi di conversione drop. Mantenere quel meccanismo nascosto all'utente non è sempre una cattiva idea e se lo scambio e l'autenticazione della password sono implementati correttamente di quanto non sia in realtà un problema di sicurezza.

Possiamo anche immaginare come potrebbe effettivamente impiegare un utente malintenzionato ad attaccare eBay più a lungo se eBay oscura i loro protocolli di sicurezza, perché sembrano essere deboli quando in realtà devono avere delle linee di sicurezza abbastanza formidabili.

Appare debole quando sei forte e forte quando sei debole

- Sun Tzu, The Art of War

1
OneChillDude