Le protocole HTTPS est-il un moyen sûr de sécuriser la communication client/serveur?

Application Je développe une sorte d'autorisation côté serveur. La communication se fait via un canal sécurisé (HTTPS dans mon cas, avec un certificat SSL valide). Je prévois d'implémenter quelque chose qui permettra de vérifier si le serveur distant est exactement ce qu'il prétend être.Le protocole HTTPS est-il un moyen sûr de sécuriser la communication client/serveur?

Je sais qu'aucune protection côté client n'est incassable, surtout si on a assez de temps et de connaissances. Mais, si j'implémente ce que j'ai décrit ci-dessus, cette approche de sécurité est-elle suffisamment sécurisée pour protéger les données contre le piratage, pendant le transit, ou pour empêcher les attaques de l'intercepteur et assurer sa validité? J'envisage d'ajouter une autre couche de sécurité autour des données transférées (en utilisant une paire de clés privée/publique), mais je soupçonne qu'il pourrait être suffisant de compter sur SSL, sans réinventer la roue.

Source

2010-06-23 mr.b

SSL est assez sécurisé avec un certificat valide, mais ...

Beaucoup de gens ne savent pas que l'obtention d'une erreur de certificat non valide est quelque chose qui signifie « Vos données sont peut-être va intercepter par quelqu'un autre". Ils vont juste ignorer l'avertissement et l'attaque de l'homme dans le milieu fonctionnera toujours. En outre, certains navigateurs plus anciens comme IE6 pourraient même ne pas vous avertir si le certificat est invalide. Le problème dans ce cas serait l'utilisateur, pas la technologie utilisée. Cela signifie qu'au lieu d'essayer de construire une autre couche de sécurité, vous devriez enseigner aux utilisateurs de votre application ce que cela signifie d'obtenir une erreur de certificat invalide et pourquoi ils devraient utiliser un navigateur moderne.

Source

2010-06-23 12:45:05 HoLyVieR

Dans mon scénario spécifique, les utilisateurs ne font pas partie du processus (et ignorent presque automatiquement les avertissements liés aux certificats), mais la validité du certificat doit être déterminée automatiquement par le programme client. Bien sûr, un utilisateur mal intentionné peut détourner ce processus du côté du client, mais il est beaucoup plus difficile à tirer que MITM-attaque. Est-ce que cela change l'histoire en faveur de la sécurité? –

L'utilisation de SSL avec des certificats «réels» permet au client de faire confiance au serveur. Mais si vous avez besoin d'établir une confiance serveur/client (contrôlez quel client peut accéder au serveur), vous devez utiliser une sorte d'authentification. Une approche consiste à installer des certificats côté client SSL dans chaque client/navigateur ou à utiliser le cryptage SSL avec l'ID utilisateur/mot de passe. –

Quand je dis que les gens ignorent l'avertissement, c'est parce que la plupart des gens réagissent à "Un message d'erreur de certificat invalide" est simplement de cliquer sur "Ignorer" ou "Continuer". Cela n'a rien à voir avec les logiciels malveillants, mais plutôt le comportement des gens envers ce type d'avertissement. Le logiciel reconnaît correctement le certificat invalide, mais l'utilisateur choisit simplement d'ignorer l'erreur et de continuer. C'est le seul problème possible avec SSL, il n'a rien à voir avec le logiciel, tout dépend des gens qui l'utilisent. – HoLyVieR

Monsieur B, Comme vous avez mentionné que le client va valider le certificat SSL du serveur et que les utilisateurs ne font pas partie du processus, je pense que vous serez en train de valider le certificat SSL du serveur. Cependant, vous devez prendre soin du processus de vérification. J'ai vu plusieurs applications client qui ne vérifient pas assez le certificat. Par "assez bien", je veux dire que le client doit vérifier - 1) Autorité de certification 2) Durée 3) Site délivré à Une des applications que j'ai été test de stylo avait le bug qu'il vérifiait le "CN" du certificat - qui peut être spoofé (on pourrait créer un faux certificat avec CN arbitraire).

Source

2010-06-25 03:29:52 gauravphoenix

Merci pour votre contribution précieuse à ma question! Pouvez-vous me dire pourquoi vérifier la durée? Cela m'empêcherait d'étendre le certificat côté serveur, sans intervention du côté client, n'est-ce pas? –

Supposons que le certificat de serveur est valide pour 2 ans (disons 2010 à 2012). Supposons pour l'instant que dans l'année 2013, il y ait eu une compromission de clé privée de ce certificat et que le propriétaire du serveur ait révoqué le certificat SSL. Le logiciel client, s'il ne valide pas la durée du certificat, fera confiance à un certificat SSL compromis.Le facteur de durée d'un certificat aide à réduire l'exposition aux certificats compromis. – gauravphoenix

Bon point. Mais, cela complique également la transition de l'ancien au nouveau certificat du côté client, n'est-ce pas? Fondamentalement, cela améliore la sécurité mais complique le déploiement, qui est un compromis classique entre sécurité et simplicité. Serait-ce une bonne idée de limiter la validité du certificat à une année seulement? Cela diminuerait encore le risque de compromis, non? –

Le protocole HTTPS est-il un moyen sûr de sécuriser la communication client/serveur?

Répondre

Questions connexes