Vous avez raison, la régression vers HTTP est inutile.

Notez que tous vos points s'appliquent à un type d'attaque particulier, où l'adversaire peut accéder aux données transport entre client et serveur. Il peut s'agir du propriétaire d'un hotspot Wi-Fi ou de votre FAI agissant en tant qu ' homme du milieu , qui se trouve entre vous et le serveur. Cela peut être difficile à accomplir pour un attaquant distant, mais c'est particulièrement facile sur un réseau Wi-Fi public.

Ce que HTTPS ajoute à HTTP, c'est transport sécurisé des données . L'application Web elle-même peut tout à fait convenir - si vous communiquez sur un canal non chiffré, l'attaquant pourra lire, modifier et injecter des données arbitraires dans vos requêtes et les réponses du serveur. Avec un cookie de session capturé, il sera également possible de se faire passer pour vous aussi longtemps que le cookie est valide.

Ce que l'attaquant ne peut faire, c'est prendre le contrôle de votre compte Google ou se réauthentifier avec Google ultérieurement. En effet, l'authentification avec Google se produit toujours via SSL et le jeton accordé expire après un certain temps.

La situation est donc un peu meilleure que la capture immédiate de vos informations d'identification. Cependant, comme vous l'avez dit, un attaquant serait toujours en mesure de reprendre la session et d'effectuer toute action en votre nom.

Je voudrais poser la question suivante:

Quel est l'intérêt d'avoir une authentification dans l'application?

Si toute la page contient est du contenu public et vérifiable d'une manière extérieure (par exemple un miroir Debian, où les paquets sont avec PGP) et vos utilisateurs ne craignent pas qu'un tiers examine ce qu'ils visitent, la page peut ne pas avoir besoin de https. Mais pas non plus une connexion.

Les raisons courantes pour lesquelles une authentification est requise sont:

• Il y a certaines données que l'utilisateur ne peut lire que lorsqu'il est connecté

• Un utilisateur enregistré peut envoyer des messages à d'autres personnes

• Cela permet à l'utilisateur de gagner en réputation, en conservant une identité qui n'est utilisée que par lui

• Le compte peut bénéficier de certains avantages obtenus à l'extérieur (comme l'accès à du contenu payant)

Tous sont annulés par en utilisant http au lieu de https dans la communication, ainsi que presque toute autre raison d'insérer un identifiant. Indépendamment du fait que le mot de passe ne soit pas exposé (ce qui serait certes encore pire).

Il y a quelque temps, le prix d'achat des certificats a été discuté, mais de nos jours, plusieurs CA fournissent des certificats gratuitement.

† Le coin de Nitpicker, il y a quelques cas extrêmement rares où la sécurité n'est pas compromise par cela. Un exemple est Mega, qui a chargé certains javascripts courants via http, mais un script chargé en https a vérifié leurs hachages avant de les exécuter. Fragile et plus complexe que la mise en place de https partout. N'essayez pas ça à la maison, les enfants.

Vos informations d'identification sont en sécurité, mais un piratage de session pourrait se produire

Une possibilité aurait pu être qu'un attaquant aurait pu effectuer une attaque SSL Strip en agissant en tant qu'homme au milieu, si cela se produit, le site Web HTTPS sera servi de HTTP à la victime. Mais comme vous l'avez confirmé avec le site Web qu'ils l'ont fait intentionnellement, cette possibilité est supprimée.

Maintenant, Google utilise oAuth2, donc la poignée de main avec Google se fera via HTTPS &, vous serez redirigé vers votre site Web via HTTP après cela (cela se passe de la même manière avec https://security.stackexchange.com/ lorsque vous utilisez votre compte Google). Votre site Web aurait généré un jeton de session après oAuth. Le risque que présente HTTP dans ce cas est qu'un attacheur peut très facilement détourner votre session et surfer sur le site Web en faisant semblant d'être vous

Vous avez tout à fait raison. En excluant les identifiants de connexion Google, un attaquant peut effectuer une attaque MITM et intercepter toutes les demandes de la victime. Je vous propose de leur communiquer les risques d'une réimplémentation du protocole SSL.

"Qu'est-ce qui peut mal se passer": si vous faites cela avec une API, toutes les applications iOS conçues pour iOS 9 et exécutées sur iOS 9 à l'aide de cette API cesseront de fonctionner.

Cela s'appelle "App Transport Security", et à moins que le développeur ne crée une exception pour votre domaine, http n'est pas accepté et https avec des connexions pas suffisamment sécurisées n'est pas accepté. Étant donné que votre API utilisait auparavant https, les applications existantes n'auront pas d'exception pour votre domaine, elles cesseront donc de fonctionner.