L'authentification via HTTPS ralentira-t-elle mon application?

Je crée une application Web et un service Web RESTful.

J'ai lu divers articles sur la meilleure façon d'authentifier les demandes au service Web.

La meilleure option pour moi semble être d'utiliser l'authentification de base HTTP. Presque tous les articles que j'ai lus disent que l'authentification doit être cryptée via SSL ou équivalent.

Je ne suis pas totalement sûr de ce que cela implique. Est-ce à dire que tout mon service Web devra être sur un serveur sécurisé? Est-ce que cela ralentira les choses?

Tout d'abord, essayez de comprendre le fonctionnement de l'authentification SSL (HTTPS) et HTTP.

Les méthodes d' authentification HTTP habituelles (Digest, Basic et tous les schémas d'authentification par formulaires + cookies que vous pouvez implémenter par-dessus HTTP) sont toutes précaires en elles-mêmes, car elles envoient plus ou moins les informations d'authentification en texte clair. Que les données se trouvent dans des champs ou des en-têtes POST et que le codage base64 soit appliqué, peu importe à cet égard, le mot de passe est clairement visible par toute personne ayant accès au trafic réseau. Cela signifie que l'authentification HTTP sur un canal non approuvé est sans valeur: tout ce qu'il faut à un attaquant pour lire votre mot de passe est un petit reniflement de réseau.

SSL implémente un canal de communication sécurisé sur un canal intrinsèquement non sécurisé. Cela fonctionne, grosso modo, comme suit:

1. Le serveur envoie un certificat signé
2. Le client valide le certificat par rapport à une liste de clés de signature reconnues; les signatures de certificats peuvent être enchaînées, de sorte que chaque nœud indique "si la signature qui me signe est bonne, alors moi aussi", mais en fin de compte, la chaîne doit se résoudre à l'une des rares autorités de confiance préconfigurées sur le client.
3. Le client utilise la clé de chiffrement publique du serveur pour envoyer un secret partagé
4. Le serveur déchiffre le secret partagé à l'aide de la clé privée (car seul le serveur légitime possède la clé privée, les autres serveurs ne pourront pas déchiffrer le secret partagé)
5. Le client envoie les données de demande réelles, cryptées à l'aide du secret partagé
6. Le serveur déchiffre les données de la demande, puis envoie une réponse chiffrée
7. Le client déchiffre la réponse et la présente à l'utilisateur.

Notez ici quelques points importants:

• La chaîne de certificats permet aux clients de s'assurer que le serveur avec lequel ils parlent est le vrai, et non quelqu'un interceptant leurs demandes. C'est pourquoi vous devriez acheter un vrai certificat SSL et pourquoi les navigateurs vous lancent des avertissements effrayants lorsque vous visitez un site qui utilise un certificat invalide, expiré ou autrement incorrect: tout le cryptage dans le monde n'aide pas si vous êtes parler à la mauvaise personne.
• Le cryptage public / privé utilisé pour échanger le secret garantit que la communication réussie ne fonctionnera qu'entre cette paire particulière de client et de serveur: les paquets réseau reniflés seront cryptés et ils nécessiteront la clé privée du serveur pour accéder aux données.
• Le chiffrement symétrique est utilisé pour la majeure partie de la demande, car il a un surdébit de performances beaucoup plus faible que le chiffrement à clé privée / publique. La clé (secret partagé) est cependant échangée en utilisant un cryptage à clé privée / publique, car c'est la seule façon de le faire de manière sécurisée (sauf le transport sur un canal séparé, comme un service de messagerie).

Donc, évidemment, il y a des frais généraux impliqués, mais ce n'est pas aussi mauvais que vous le pensez - c'est surtout à l'échelle où "jeter plus de matériel" est la réponse appropriée, à moins que vous ne vous prépariez à des quantités de trafic absolument massives ( pensez à Google ou Facebook). Dans des circonstances normales, c'est-à-dire une utilisation typique d'une application Web, la surcharge SSL est négligeable et, par conséquent, dès que vous avez des données confidentielles, il est préférable de tout exécuter sur SSL, y compris les ressources. SSL est également le seul moyen viable de sécuriser le trafic HTTP; les autres méthodes ne sont tout simplement pas aussi standardisées et ne sont donc pas largement prises en charge, et vous ne voulez absolument pas implémenter ces choses vous-même, car honnêtement, il est trop facile de se tromper.

TL; DR: Oui, SSL + Authentification de base est une bonne idée, oui, vous avez besoin d'un serveur sécurisé (et d'un certificat valide ), oui, cela ralentira un peu les choses, mais non, ce n'est pas quelque chose à craindre maintenant.

HTTPS (SSL) n'est pas une authentification utilisateur FYI. Il fournit simplement le cryptage entre 2 points de terminaison.

Mais oui, il y a un tout petit peu de frais généraux (mais pas assez pour justifier un changement de plans / matériel). Vois ici :

/programming/548029/how-much-overhead-does-ssl-impose

Avec l'authentification de base HTTP, le nom d'utilisateur et le mot de passe fournis par l'utilisateur sont envoyés avec chaque demande au serveur. Cela signifie qu'ils sont en texte brut, même dans les zones de votre site qui n'ont pas nécessairement besoin d'être sécurisées. Évidemment, vous voudrez ici que SSL protège vos utilisateurs.

En théorie, vous pouvez utiliser l'authentification par cookie et ne mettre SSL que sur la page de connexion (où le nom d'utilisateur et le mot de passe sont envoyés). Si vos cookies sont décemment sécurisés et protégés contre les attaques par rejeu, alors un attaquant ne pourrait rien faire avec eux même s'il a réussi à en obtenir un.

L'authentification de base consiste à définir un nom d'utilisateur et un mot de passe dans l'en-tête de la demande http. Si vous n'utilisez pas SSL ou équivalent, ce nom d'utilisateur et ce mot de passe sont envoyés en texte brut et sont triviaux à voler.

De nos jours, la plupart des serveurs Web prennent en charge HTTPS et bien qu'il ajoute une surcharge à chaque appel, cette surcharge est minime.

Vous pouvez sécuriser certains points d'extrémité et pas d'autres (c'est-à-dire avoir un point d'extrémité authentifié qui produit un jeton qui peut être utilisé pour d'autres appels). Je recommande fortement SSL pour l'ensemble du service, car il est beaucoup plus sécurisé. (si rien d'autre n'intercepte les données sensibles)

Il n'y a pas si longtemps, Jeff Atwood a écrit un bref article sur la question de savoir si le cryptage complet est la solution. Il décrit quelques exemples réels et a également quelques lignes sur les considérations de performance.

En outre, il fait référence à cet article sur une étude de cas Gmail, citant ce qui suit:

En janvier de cette année (2010), Gmail est passé à l'utilisation de HTTPS pour tout par défaut. Auparavant, il avait été introduit en option, mais maintenant, tous nos utilisateurs utilisent HTTPS pour sécuriser leur courrier électronique entre leur navigateur et Google, tout le temps. Pour ce faire, nous n'avons dû déployer aucune machine supplémentaire ni aucun matériel spécial. Sur nos machines frontales de production, SSL / TLS représente moins de 1% de la charge CPU, moins de 10 Ko de mémoire par connexion et moins de 2% de la surcharge du réseau. Beaucoup de gens croient que SSL prend beaucoup de temps CPU et nous espérons que les chiffres ci-dessus (publics pour la première fois) aideront à dissiper cela.

Il mentionne également certaines améliorations alors récentes de la mise en cache côté client des pages via HTTPS par le navigateur .

Malgré cela, souligne-t-il, il existe d'autres sanctions, la plupart n'étant pas des performances mais des coûts de mise en œuvre:

• Maintenir la qualité du logiciel tout en ajoutant une complexité supplémentaire pour les équipes déjà occupées,
• La mise en cache du proxy est beaucoup plus difficile à configurer correctement et nécessite également des modifications de code,
• Il est difficile de garantir la sécurité d'un mashup de contenu provenant de différentes sources,
• Les appareils mobiles bas de gamme peuvent avoir des difficultés avec le chiffrement.

L'authentification de base HTTP sans votre propre gestion de session vous laissera probablement ouvert aux attaques de contrefaçon de demande intersite. Vous pouvez probablement l'utiliser si vous vous associez à votre propre gestion de session, mais vous pouvez avoir du mal à fournir une fonction de "déconnexion" propre.

Peu importe ce que vous utilisez pour l'authentification, vous devrez utiliser HTTPS pour crypter la connexion (sauf si l'application Web n'est accessible que sur un réseau contrôlé et sécurisé). Cela peut ralentir un peu les choses (les établissements de connexion sont chers, mais les navigateurs ont tendance à garder les connexions pendant un certain temps), mais si vous voulez une application sécurisée, vous ne pourrez pas l'éviter de toute façon, donc vous n'avez pas vraiment besoin s'en inquiéter.

Remarque: «L'authentification HTTPS» (que vous avez mentionnée dans le titre) est trompeuse - elle pourrait faire référence à l'authentification par certificat client SSL, qui n'a pas grand-chose à voir avec le texte de votre question et a son propre ensemble d'avantages et de problèmes. Vous ne voulez probablement pas y toucher.

Comment allez-vous réaliser l'authentification de base?
S'il s'agit d'un nom d'utilisateur / mot de passe codé en dur et que vous utilisez la fonctionnalité intégrée de votre serveur Web pour le faire, cela aura probablement un impact presque nul. Si vous êtes en train de faire des choses folles dans une base de données ou quelque chose de similaire, alors oui, cela pourrait avoir un impact.

Comme d'autres l'ont noté ici, SSL et l'envoi des en-têtes supplémentaires ralentiront techniquement les choses, mais ce ne sera en aucune façon significatif.