Che cosa sta succedendo con il mio download del recente aggiornamento della sicurezza di Apple?

Question

Che cosa sta succedendo con il mio download del recente aggiornamento della sicurezza di Apple?

#1 da (1 voti)

12

L'aggiornamento in questione è l'aggiornamento combinato Mavericks che, tra le altre cose, afferma di correggere la recente vulnerabilità SSL / buco aperto.

Questo problema mi ha davvero infastidito, quindi ho deciso di procurarmi la chiave PGP di Apple e di verificarla al meglio. E ho spiato il mio traffico con Wireshark durante i download. Ecco i miei risultati:

Ottenere e verificare la chiave PGP di Apple è stata una perdita di tempo, perché per quanto posso dire che non emettono firme per gli aggiornamenti software
Il download downloader si collega su HTTPS al loro dominio di localizzazione download software, che reindirizza all'effettivo aggiornamento su un CDN (nel mio caso apple.vo.llnwd.net)
Ogni singolo bit del pacchetto di aggiornamento arriva sul semplice vecchio HTTP dal CDN
Ogni singolo pacchetto dell'aggiornamento è seguito da un ACK duplicato (questo accade solo con l'aggiornamento, tutti i miei altri download vanno bene, quindi non penso che sia la mia infrastruttura)
Il download manuale dell'archivio dmg da qui è HTTP per impostazione predefinita. L'applicazione di HTTPS causa un reindirizzamento all'URI del file (HTTP) effettivo, HTTPS non è abilitato per questo URI.

Apple (presumibilmente rispondendo alle critiche di un tempo) afferma specificamente che gli aggiornamenti vengono forniti tramite HTTPS, tranne nei casi in cui "complicate configurazioni di proxy" lo rendono impossibile. Ho provato a scaricare tramite la mia connessione vaniglia e 2 VPN offshore, e per amore o denaro posso ottenere un link HTTPS a quel file (aggiornamento software o tramite sito Web).

Le mie domande sono:

Secondo te sono loro - o qualcuno in mezzo - a giocare a buggers divertenti?
C'è il sospetto di essere tratto da tutti questi ACK duplicati? (Non ne so abbastanza per speculare)

Sono sospettoso perché se fossi l'NSA / GCHQ e avessi un avvertimento di settimane per intercettare e sostituire i blob di binario su endpoint HTTP prevedibili che verranno eseguiti automaticamente perché firmano il codice su milioni di le macchine bersaglio sono completamente rotte, probabilmente penserei che il Natale sia arrivato due volte. Non vedo alcuna circostanza in cui potrebbero perdere questa opportunità se fossero in grado di farlo, e da tutto ciò che ho letto sono più che capaci di una cosa del genere.

tls updates man-in-the-middle macosx surveillance

posta CHT 27.02.2014 - 05:01

fonte

1 risposta

Leggi altre domande sui tag tls updates man-in-the-middle macosx surveillance

Smart card + GnuPG: cosa viene memorizzato nel mio portachiavi / come adottare la smart card? NoScript è errato? [chiuso]

score 1 · Answer 1

(Il sotto è tutto speculazione, non so come funziona l'aggiornamento di Apple internamente.)

Ci sono sicuramente architetture che possono eseguire un aggiornamento sicuro su HTTP. Quasi tutte le distribuzioni Linux distribuiscono pacchetti in testo semplice e li verificano verificando gli hash (SHA-1, SHA-256, ecc.) Dai metadati del repository. I metadati del repository, a loro volta, sono firmati con una chiave GPG verificata dall'host e sono stati installati con il supporto di installazione originale. (Se il tuo supporto di installazione originale era backdoor, tutte le puntate sono disattivate per sempre.)

Quindi cosa c'entra questo con il tuo aggiornamento Apple? Apple potrebbe utilizzare uno schema simile: inviare un hash su HTTPS, scaricare tramite HTTP, quindi verificare l'hash. Gli aggiornamenti software come questo sono un caso in cui tutto ciò di cui hai veramente bisogno è l'integrità (so che alcune persone vorrebbero la riservatezza, ma siamo onesti, se un utente malintenzionato ti vede scaricare X byte su HTTPS da apple.com e l'ultimo aggiornamento di Apple è X byte, hai già perso la riservatezza) e l'integrità può essere raggiunta senza inviare il file stesso su HTTPS.

In effetti, questa tecnica potrebbe essere preferibile - Apple potrebbe avere un piccolo numero di server che servono i metadati di aggiornamento sotto il loro controllo diretto (cioè URL e hash dell'aggiornamento) e quindi utilizzare un CDN di terze parti per distribuire l'aggiornamento, riducendo costi di larghezza di banda, latenza, ecc. Se l'aggiornamento fosse servito dal CDN direttamente su HTTPS senza la fase di verifica (cioè, tutta l'integrità proviene da HTTPS), allora il CDN (o qualcuno che compromette il CDN) potrebbe sostituire l'aggiornamento con una modifica versione.

Se gli ACK duplicati sono qualcosa di cui preoccuparsi è in gran parte una domanda separata. Il mio livello di preoccupazione dipenderebbe da un certo numero di cose: sono ACK in uscita o in entrata? Quali sono i TTL? Quali sono i numeri di sequenza? È davvero difficile da dire, ma sospetto che gli ACK duplicati siano molto più probabilmente causati da una configurazione errata della rete da qualche parte (anche se non dalla rete) piuttosto che da un utente malintenzionato.