Ci sono una serie di altre domande che affrontano elementi di questo problema di sicurezza, ma nessuno che sembra (a un non esperto) affrontare il nucleo sostanziale dei problemi sollevati in questo articolo:
Da un punto di vista mobile, quali sono i passi corretti che l'azienda avrebbe dovuto intraprendere per prevenire, oltre all'uso di un certificato SSL rilasciato dalla CA?
Risposta relativa a SSL generale: Per fare SSL (HTTPS) in modo sicuro, il punto veramente importante è che il sistema client (smartphone, PC ... non lo fa importa) può fare in modo che la chiave pubblica del server che sta usando per l'handshake SSL sia realmente quella originale dal server previsto. I certificati emessi dalla CA riguardano proprio questo. Senza una convalida della chiave pubblica del server di qualche tipo, sono possibili attacchi MitM . Altrimenti, non lo sono (a meno che l'implementazione del client e / o del server non accada, ma questa è un'altra questione).
Con i certificati, l'attacco MitM può funzionare solo se l'autore dell'attacco può ottenere un certificato falso, con il nome del server effettivo ma la chiave pubblica dell'attacker, al suo interno, da una CA attendibile dal client. Gli incidenti con certificati falsi emessi sono rari (sentiamo parlare di uno di questi incidenti all'anno). Molto più spesso, un utente credulone decide di ignorare l'avviso spaventoso dal suo browser e fa clic attraverso di esso. Se presti attenzione agli avvisi del browser, dovresti stare bene.
Sfortunatamente, molte connessioni SSL non sono tra un browser Web e un server, ma tra una applicazione e un server, ed è compito dell'applicazione non fare lo stupido click-through-warning (metaforicamente). Ci sono stati un sacco di rapporti di applicazione che non controllano il certificato del server correttamente, o del tutto. Questo è specifico per le app e, come utente, è difficile da controllare.
Informazioni su Tinder: nessuno dei precedenti si applica ai problemi descritti nell'articolo a cui ti colleghi. Apparentemente, Tinder gestisce un servizio di appuntamenti, con il cliente che esegue un'app specifica sul proprio telefono; l'app parla con un server centrale. Il server centrale calcola quindi "possibili incontri", ad esempio avvisa i clienti della presenza vicina di altri clienti con cui la stima romantica è euristicamente stimata superiore alla media.
Accade così che la finestra di dialogo tra l'app e il server coinvolga il server che dice all'app molto di altri clienti - in realtà molto più di quanto sarebbe necessario per il servizio descritto, tra cui la perdita di ID di Facebook e altre informazioni simili. L'interfaccia utente dell'app non lo mostrerà, ma un'applicazione personalizzata potrebbe ottenere tali dati dal server e registrarli.
SSL non avrebbe fatto nulla a favore o contro questo problema di privacy. Forse loro stanno usando SSL; non importa. Il problema è che il server perde troppe informazioni private a chiunque lo richieda. Un attacco MitM è rilevante solo quando l'utente malintenzionato tenta di intercettare una trasmissione di dati contenente dati che un cliente autorizzato può ottenere legittimamente, ma che gli autori di attacchi non dovrebbero; qui, il client non dovrebbe essere in grado di ottenere le informazioni in primo luogo, e che è il problema di cui parla l'articolo.
L'articolo che menzioni non ha nulla a che fare con HTTPS. Se viene utilizzata una connessione HTTPS, indipendentemente dal desktop o dal cellulare, la connessione viene protetta tra il sistema client e il server che contiene la chiave privata per il certificato utilizzato.
In questo caso, sembra che l'API abbia funzionato su un collegamento non crittografato. Sarebbe stato sufficiente crittografare il link e / o non includere le informazioni personali non necessarie nelle richieste API.
Leggi altre domande sui tag mobile tls certificates man-in-the-middle