Utilisation de HTTPS pour la communication client-serveur

Question

Je souhaite utiliser le protocole HTTPS pour sécuriser la communication entre mon client et le serveur. La première communication cryptée sera utilisée pour authentifier l'utilisateur - c'est-à-dire vérifier son nom d'utilisateur et son mot de passe. Après que les informations d'identification de l'utilisateur seront vérifiées avec succès par le serveur, je voudrais commencer à obtenir des données dans les demandes suivantes. MAIS comment le serveur déterminera que la requête suivante est envoyée par l'utilisateur, dont les informations d'identification ont déjà été vérifiées? Comme la connexion TCP peut être fermée entre la connexion et les requêtes HTTPS suivantes, cela signifie que le contexte SSL doit être libéré par le serveur, donc avec la nouvelle requête GET, la nouvelle connexion TCP doit être établie et la nouvelle négociation SSL (TLS) doit être faite (ie nouveau mot de passe partagé pour le cryptage doit être échangé par les deux côtés, etc.)

Pour cela je pense que le serveur doit renvoyer au client en 200 réponse OK pour le l'authentification initiale demande un nonce généré aléatoirement (qui est valide pour un certain temps), que j'inclurai dans chaque requête suivante, afin que le serveur puisse détecter, sur la base de ce nonce généré aléatoirement, quel nom d'utilisateur est derrière la requête et vérifiez que cet utilisateur est déjà connecté. s ma compréhension est-elle correcte?

Merci beaucoup pour la réponse BR Sten

Answer 1

La méthode la plus simple consiste à exiger toutes les communications à passer par HTTPS (afin que les données sont confidentielles, personne autre que le client et le serveur peut le voir) et utiliser un nom d'utilisateur et un mot de passe simples à chaque demande dans cette connexion sécurisée. C'est très simple à faire en pratique (le nom d'utilisateur et le mot de passe passent par la connexion comme un entête HTTP, ce qui est correct ici parce que nous utilisons HTTPS) et le serveur peut vérifier chaque fois que l'utilisateur est autorisé. Vous n'avez pas besoin de vous inquiéter des poignées de main SSL; c'est la responsabilité de la couche SSL/HTTPS (et c'est pourquoi HTTPS/SSL est nice). En variante, la connexion peut être effectuée avec n'importe quelle méthode et générer un certain type de nombre magique (par exemple, un UUID ou un hachage cryptographique d'un nombre aléatoire et le nom de l'utilisateur) qui est stocké dans un cookie de session. Les requêtes suivantes peuvent simplement vérifier que le nombre magique est celui qu'il reconnaît depuis le début de la session (et qu'il ne s'est pas passé trop de temps depuis qu'il a été émis); La déconnexion devient juste l'oubli du nombre magique côté serveur (et demande au client d'oublier aussi). C'est un peu plus de travail pour implémenter ceci, mais ce n'est pas encore difficile et il y a des bibliothèques pour le côté serveur pour gérer le travail d'âne.

La première option est particulièrement utile lorsque vous écrivez quelque chose à utiliser par d'autres programmes, car elle est vraiment facile à mettre en œuvre. La deuxième option est préférable lorsque le client est un navigateur Web, car il donne aux utilisateurs plus de contrôle sur le moment où leur navigateur est autorisé (les API de programme n'ont pas besoin de ce genre de chose). Chaque fois que le client doit être un navigateur, vous devez prendre soin de l'armure contre d'autres types d'attaque (par exemple, divers types de falsification de requête), mais cela est pratiquement indépendant de tout le reste.

Answer 2

Inventer un mécanisme d'authentification personnalisé dans votre cas est très risqué - il est facile de faire une erreur qui laissera beaucoup de mal faire. Donc, la bonne approche, pour moi, serait d'utiliser HTTPS et de transmettre les informations d'identification de l'utilisateur à chaque demande.