Perché un sito web pubblica versioni diverse di un file su HTTP e HTTPS?

18

Ecco un link fornito sul sito web ufficiale di curl:

(prefisso omesso) bintray.com/artifact/download/vszakats/generic/curl-7.46.0-win64-mingw.7z

Quando l'ho scaricato con i prefissi http: // e https: // ho ricevuto due file diversi.

La mia domanda è: perché questo sito serve due file diversi: uno su HTTP e uno su HTTPS? Gli hash SHA256 non corrispondono.

Ecco un diff degli URL finali dopo il reindirizzamento. L'URL a sinistra è quello a cui l'HTTP reindirizza e l'URL a destra è quello a cui reindirizza HTTPS:

Aggiornamento:

Iduefilenonsonostatiscaricaticontemporaneamente,maavevanolostessonumerodiversione,quindihopensatochedovesseroessereuguali.Questononèilcaso.L'autoremihadettochealcunerevisioninonricevonounnuovonumerodiversione.Irisultatidellascansioneperifilepubblicatidalsitoindatediverse( 12/05/15 era la data di scansione per il download su HTTP e 28/12/15 era la data di scansione per il download su HTTPS) ha portato a confusione perché il numero di versione non è cambiato ma l'hash SHA256 lo ha fatto.

    
posta solarflare97 28.12.2015 - 05:28
fonte

4 risposte

24

La semplice risposta è: perché vuole! Il web server può servire qualsiasi cosa voglia, sia per configurazione che per coincidenza.

In questo momento, ottengo lo stesso file 75916c7b su HTTP e HTTPS e non posso confermare la tua teoria secondo cui il server web offre contenuti diversi per HTTPS rispetto a HTTP. Tuttavia, se si è riusciti ad accedere al sito in prossimità dell'ora in cui il file è stato aggiornato, è possibile che diversi server stessero servendo i diversi protocolli e che l'aggiornamento del file non si fosse ancora propagato al server che serviva il vecchio file.

Ricorda che un URL può essere servito da qualsiasi numero di server - il fatto che tu ottenga un file da un URL non esclude che ci siano 20 copie di questo file su 20 server / cache, alcune delle quali potrebbero non essere aggiornate .

Questa è una certezza in questo caso, dal momento che il sito sembra utilizzare Cloudfront, che è una Content Delivery Network, un'infrastruttura progettata in modo esplicito per memorizzare nella cache i file su molti server distribuiti da consegnare su scala globale.

    
risposta data 28.12.2015 - 08:16
fonte
13

Autore dei file sopra citati qui.

Il checksum di tali file allo stato corrente delle cose è normale da cambiare quando gli script di compilazione vengono modificati e una nuova build viene automaticamente attivata e caricata. In caso di curl 7.46.0, gli script di compilazione (e di conseguenza i pacchetti scaricabili) sono cambiati tre volte al momento della scrittura:

  • Il supporto HTTP / 2 è stato abilitato, creando e collegando staticamente la dipendenza nghttp2: commit , < a href="https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.211"> log
  • La dipendenza
  • nghttp2 è stata aggiornata dalla versione 1.5.0 alla 1.6.0: commit , login
  • un errore di build libcurl.dll è stato identificato e risolto, causato da un'opzione di build nghttp2 mancante: commit , log
  • il compilatore C MinGW sottostante è stato aggiornato alla versione 5.3.0, oltre a più correzioni e aggiornamenti interni: commit , registro
  • È stato corretto il falso positivo di VirusTotal eliminando un file .vbs facoltativo che era stato precedentemente copiato dal pacchetto originale di ricciolo originale: commit , registro

Qualsiasi commit qui (reso al ramo master ), attiverà una nuova build:

  • tranne quando escluso esplicitamente usando il testo di commit: [ci skip]
  • il processo di compilazione è progettato per essere riproducibile / deterministico, quindi il checksum cambierà solo se il codice sorgente sottostante o le opzioni del compilatore sono alterati. (Una build ripetuta con le stesse opzioni non la modifica.)

Per quanto riguarda il download dei file binari tramite protocolli diversi, HTTP e HTTPS dovrebbero risultare nello stesso identico contenuto binario (se i download sono fatti nello stesso momento) - sebbene sia altamente raccomandato HTTPS.

Per quanto riguarda il potenziale malware, vedi le mie opinioni su GitHub: link

In breve: sono quasi certamente dei falsi positivi, improbabili che possano essere influenzati dal protocollo di trasferimento, più probabilmente influenzati dai problemi del motore dello scanner. Il processo di compilazione completo è pubblico e controllabile così come tutto il codice sorgente che viene incorporato in esso.)

UPDATE [2015-12-28]: come risposta generale al problema HTTP vs. HTTPS: quest'ultimo, il protocollo sicuro garantisce che il contenuto proviene dalla parte giusta e che non sia manomesso nel suo percorso verso il altra estremità del filo. Per questi motivi, ci si può fidare di più e quindi il mio consiglio è nella risposta originale. Una garanzia ancora migliore è quella di verificare gli hash SHA256 dei contenuti scaricati rispetto a quelli generati sul build server stesso (visibili alla fine dei log di build collegati sopra). Una garanzia ancora più strong è quella di avere il contenuto firmato digitalmente (ad es. Usando PGP o minisign) e quella firma verificata dal ricevitore. (I miei download di arricciatura non dispongono di una firma digitale in questo momento.)

AGGIORNAMENTO [2016-01-06]: aggiornato l'elenco degli aggiornamenti del pacchetto. La correzione del falso positivo di VirusTotal era uno di questi.

    
risposta data 28.12.2015 - 11:54
fonte
3

Guarda i timestamp delle scansioni, la versione "Clean" era settimane fa. Quando fai clic sul link per una nuova data di scansione, vedi sia http che https sono infetti.

Fondamentalmente non ci sono differenze nei file, solo le scansioni sono state eseguite in due momenti diversi (pre-infezione e post-infezione)

    
risposta data 28.12.2015 - 06:35
fonte
2

Servire file diversi con HTTP e HTTPS è in realtà una routine. Ad esempio, supponi di essere una banca. Se qualcuno fornisce l'URL link , la banca non vuole utilizzare HTTP e non vuole complicarti, quindi emette solo problemi una risposta con un reindirizzamento 301 o 302 al link . Questo è il più trasparente possibile.

    
risposta data 28.12.2015 - 20:58
fonte

Leggi altre domande sui tag