Si ves este video a las 52:05, dice,
"Nunca, nunca, nunca, alguna vez envíe el recibo directamente desde su aplicación en un dispositivo al servicio de validación".
Él va a decir,
"Es demasiado fácil para que alguien se siente en el medio y devuelva un falso positivo, y también estará exponiendo su secreto compartido"
¿Por qué alguien no puede sentarse en medio de su propio servidor y el servicio? ¿Y cómo podría exponerse el secreto compartido si se usa SSL?
Lo importante es que no debe tomar la decisión de permitir o rechazar el acceso al contenido en el dispositivo.
Por ejemplo, digamos que tienes un juego, con mapas que puedes comprar. Si incluye todos los mapas con el juego y se comunica directamente con el servicio de validación, alguien podría simplemente configurar un "servidor de validación de Apple" falso y hacer que el servidor falso siempre devuelva "Comprado" para todo. Y esto también significa que necesita incrustar el secreto compartido dentro de la aplicación, por lo que se puede descompilar y exponer el secreto compartido.
Sin embargo, digamos que ahora pone su propio servidor en la mezcla. Ahora, en su lugar, lo hace para que su aplicación en el dispositivo, contacte a su servidor y solicite un mapa, enviando el recibo como prueba de compra. Luego, su servidor usa el "servidor de validación de manzanas" para asegurarse de que el recibo sea genuino y luego devuelve el mapa. Si la validación falla, su servidor simplemente se niega a proporcionar el mapa. ¿Entiendes ahora por qué es mucho más difícil falsificar o piratear? El propietario del dispositivo no puede simplemente falsificar la respuesta de su servidor, ya que necesitarían tener el mapa para eso.
Esto también significa que el secreto compartido se almacena en su servidor y se utiliza para autenticar las solicitudes del servidor de Apple. Esta es una de las razones por las que ningún MITM podría ponerse allí. También MITMing una conexión entre su servidor y el servidor de Apple, es mucho más difícil, que MITMing la conexión entre EL PROPIO DISPOSITIVO y el servidor de Apple. Es bastante obvio. Su propio dispositivo podría modificarse para aceptar los certificados no válidos que genera su software MITM.
Igual que aquí si ejecutas algún servicio de juego en línea con "monedas" que se pueden comprar u otra moneda del juego. Luego, su servidor solo recibirá el recibo de su dispositivo y el trabajo de su servidor es validar este recibo y luego agregar las monedas a la cuenta del usuario. Pero si permite que el dispositivo valide el recibo y luego le diga a su servidor "Oye, compré algunas monedas y validé bien con Apple", entonces el dispositivo obviamente podría mentir.
Sí, obviamente, por supuesto, un pirata informático podría distribuir sus mapas con su propia forma de software de servidor falso como forma de piratería. Es por eso que debería implementar la mayor parte posible de cualquier aplicación o lógica de juego en el servidor, y simplemente hacer que la aplicación cliente sea tan "tonta" como sea posible, simplemente transmitir la entrada del usuario a su servidor y recibir la salida del usuario.
Lo que no ha entendido, es que SSL no está diseñado para proteger ninguna comunicación si alguna de las partes es deshonesta. Lo mismo ocurre con la gente que piensa que "las tiendas web con SSL no lo estafarán porque son de confianza". SSL solo está diseñado para proteger la comunicación entre 2 partes honestas, de cualquier tercero deshonesto. Y si ejecuta la validación directamente con el servicio de manzanas, una de las partes (dispositivo del usuario) se considera deshonesta y, por lo tanto, el modelo de seguridad completo fallará.