J'ai lu que SSL est une bonne solution pour la sécurité "point à point", mais pas pour la sécurité "bout à bout". Par exemple, en cet article à JavaWorld, il est dit
SSL/TLS n'est tout simplement pas conçu pour un tel scénario ; SSL/TLS ne gère que la sécurité point à point... SSL/TLS peut sécuriser le chemin entre deux [intermédiaires], mais pas d'un bout à l'autre.
Je construis un service web pour fournir des données à des clients distincts, comme décrit dans le document suivant cette question de Programmers.SE . Si je comprends bien la mise en œuvre de SSL dans ce contexte, je pourrais ajouter une sorte de clé API à tous mes appels de service web et imposer HTTPS uniquement au service, et je serais aussi sûr que nécessaire (je ne transmets rien de spécifique à l'utilisateur, à l'exception d'une adresse électronique dans certaines circonstances qui sont clairement indiquées à l'utilisateur et initiées par lui). Mais cette déclaration et cet article semblent contester cela. Suggère-t-il qu'une attaque de type "man-in-the-middle" est toujours possible sur une connexion SSL ? Le guide OAuth indique aquí (deuxième paragraphe sous "Au-delà de l'essentiel") que :
HTTPS est la solution recommandée pour éviter un attaque de l'homme du milieu (MITM) Les données sur la sécurité sont souvent difficiles à obtenir, car elles ne permettent pas d'obtenir des informations sur la sécurité, les écoutes et d'autres risques de sécurité.
Comment concilier cela ?