Se guardi questo video alle 52:05 dice,
"Mai, mai, mai, mai invia la ricevuta direttamente dalla tua app su un dispositivo al servizio di convalida."
Continua a dire
"È troppo facile per qualcuno sedersi nel mezzo e restituire un falso positivo, e esporrerai anche il tuo segreto condiviso"
Perché qualcuno non può sedersi nel bel mezzo del proprio server e del servizio? E come potrebbe essere esposto il segreto condiviso se si utilizza SSL?
Il fatto è che non devi prendere la decisione di autorizzare o disabilitare l'accesso ai contenuti, sul dispositivo.
Ad esempio, diciamo che hai un gioco, con mappe acquistabili. Se includi tutte le mappe del gioco e comunichi direttamente con il servizio di convalida, qualcuno potrebbe semplicemente impostare un falso "server di convalida della mela" e fare in modo che il server falso restituisca sempre "Acquistato" per tutto. Questo significa anche che è necessario incorporare il segreto condiviso all'interno dell'app, in modo che possa essere decompilato e esposto al segreto condiviso.
Tuttavia, diciamo che ora metti il tuo server nel mix. Ora, invece, rendi la tua app sul dispositivo, contatta il tuo server e chiedi una mappa, inviando la ricevuta come prova di acquisto. Il server utilizza quindi "server di convalida mele" per garantire che la ricevuta sia autentica, quindi restituisce la mappa. Se la convalida fallisce, il tuo server si rifiuta semplicemente di fornire la mappa. Adesso capisci perché è molto più difficile spoofare o hackerare? Il proprietario del dispositivo non può semplicemente falsificare la risposta dal tuo server, dal momento che avrebbe bisogno di avere la mappa per questo.
Questo significa anche che il segreto condiviso è memorizzato sul tuo server e utilizzato per autenticare le richieste dal server Apple. Questo è uno dei motivi per cui nessun MITM potrebbe mettersi lì. Anche MITMing una connessione tra il server e il server di Apple, è molto più difficile, rispetto a MITMing la connessione tra THE PRO PROPRIO DEVICE e il server di apple. È piuttosto ovvio. Il proprio dispositivo potrebbe essere modificato per accettare i certificati non validi generati dal software MITM.
Stessa cosa qui se si esegue un servizio di gioco online con "monete" o altre monete in-game acquistabili. Quindi il tuo server riceverà la ricevuta dal loro dispositivo e il lavoro del tuo server per convalidare questa ricevuta e quindi aggiungere le monete all'account dell'utente. Ma se permetti al dispositivo di convalidare la ricevuta e poi di dire al tuo server "Ehi, ho acquistato delle monete e ha convalidato ok con la mela", quindi il dispositivo potrebbe ovviamente mentire.
Sì, ovviamente, ovviamente, un hacker potrebbe distribuire le tue mappe con la propria forma di software server falso come forma di pirateria. Ecco perché dovresti implementare il più possibile qualsiasi app o logica di gioco sul server, e rendere l'app client più "stupida" possibile, semplicemente inoltrando l'input dell'utente al tuo server e ricevendo l'output dell'utente.
Ciò che non hai capito, è che SSL non è progettato per proteggere alcuna comunicazione se una delle parti è disonesta. Lo stesso vale per le persone che pensano che "i negozi online con SSL non ti truffano perché sono affidabili". SSL è progettato solo per proteggere le comunicazioni tra 2 parti oneste, da qualsiasi terza parte disonesta. E se esegui la convalida direttamente con il servizio mele, una delle parti (il dispositivo dell'utente) è considerata disonesta e quindi l'intero modello di sicurezza fallirà.