Salut,
Contexte :
Je suis en train de bosser sur une bibliothèque réseau basée sur Qt, dont le but est de fournir un protocole IPC (communication inter-processus) / RPC (appel de procédure distante) relativement simple à utiliser tout en étant le plus complet possible, asynchrone (exploitant les signaux / slots de Qt), et dont les communications sont chiffrables grâce à SSL si nécessaire (par exemple un logiciel client / serveur pour une entreprise dont le serveur va se retrouver ouvert sur internet, et qui a besoin d’un minimum de confidentialité de ses données).
Là où c’est le plus compliqué (pour moi en tous cas), c’est concernant l’authentification SSL : les possibilités sont tellement nombreuses que je m’y perds, d’autant que c’est la première fois que j’attaque ce problème donné. Et le fait que différentes possibilités se traitent à différents moments (avant la connexion ou pendant la négociation SSL suivant les usages) n’arrange pas vraiment les choses.
Je ne souhaite pas exposer les classes Qt de gestion SSL directement aux utilisateurs de ma bibliothèque, car ma couche IPC / RPC est assez complexe (multi-threading pour ne citer que ça) et a besoin d’un contrôle assez fin sur les classes réseau, ce qui est incompatible avec les formes d’authentification qui se gèrent durant la négociation SSL.
Je me suis donc résolu à écrire également une surcouche de gestion de l’authentification SSL, totalement découplée, permettant de gérer tout ça sans interférer avec mon bazar, et qui prenne en charge les usages les plus courants quitte à compléter après quand de nouveaux besoins se feront sentir.
[size=75]Pour ceux qui n’auraient pas tout compris c’est pas grave, ce n’était que pour expliquer le contexte de ma question. De toutes façons ce n’est pas un problème de programmation, mais juste de compréhension du protocole SSL et de son écosystème.[/size]
Question :
Mon problème est que, étant débutant en ce qui concerne le SSL, je n’ai qu’une idée très vague des différentes possibilités d’authentification.
Pour le moment j’ai recensé quelques cas, mais je ne suis pas certain que ça soit exhaustif, ou que toutes ces options soient réellement nécessaires.
Authentification du serveur :
[ul][li] Certificat serveur auto-signé : le client accepte n’importe quel certificat auto-signé, ou une liste bien précise de certificats connus répondant à ce même critère.[/li]
[li] Certificat serveur délivré par une Autorité de Certification (CA) publique (VeriSign et compagnie) : le client accepte n’importe quel certificat authentifié par n’importe quelle CA publique, ou une liste bien précise de certificats connus répondant à ce même critère.[/li]
[li] Certificat serveur délivré par une CA privée (par exemple interne à une entreprise) : le client accepte n’importe quel certificat authentifié par une des CA privées connues, ou une liste bien précise de certificats connus répondant à ce même critère.[/li][/ul]
Authentification du client :
[ul][li] Le client n’est pas authentifié (anonymes du point de vue SSL).[/li]
[li] Certificat client délivré par une CA publique : le serveur accepte n’importe quel certificat authentifié par n’importe quelle CA publique, ou une liste bien précise de certificats connus répondant à ce même critère.[/li]
[li] Certificat client délivré par une CA privée : le serveur accepte n’importe quel certificat authentifié par une des CA privées connues, ou une liste bien précise de certificats connus répondant à ce même critère.[/li][/ul]
Ai-je oublié quelque chose ? Quels cas sont absolument nécessaires ou absolument inutiles ? Quels cas sont rares et peuvent donc être gérés plus tard ?
J’aimerais avoir l’avis de personnes plus compétentes que moi dans ce domaine. 
