Sécurité et authentification: SSL vs SASL
Ma compréhension est que SSL combine un algorithme de cryptage (comme AES, DES, etc.) avec une méthode d'échange de clés (comme Diffier-Hellman) pour fournir des services de cryptage et d'identification sécurisés entre deux points d'extrémité sur un réseau non sécurisé (comme Internet) .
Ma compréhension est que SASL est un protocole MD5/Kerberos qui fait à peu près la même chose.
Donc ma question: quels sont les avantages/inconvénients de choisir les deux et quels scénarios rendent l'un ou l'autre plus préférable? Fondamentalement, je recherche des directives à suivre lors du choix de SSL ou pour utiliser SASL à la place. Merci d'avance!
Il est assez difficile de comparer SSL/TLS et SASL, car SSL/TLS est un protocole de communication, tandis que SASL est un framework, intégré à d'autres protocoles. (En fait, vous pouvez utiliser les deux en même temps dans certaines circonstances.)
De plus, vous mentionnez Kerberos, qui est en effet un protocole d'authentification (qui peut être utilisé avec SSL/TLS ou SASL ou indépendamment les deux). Votre question semble suggérer que l'utilisation ou non de Kerberos est l'un des principaux sous-problèmes que vous devez choisir en premier.
SASL est essentiellement une couche d'indirection pour permettre des systèmes d'authentification enfichables et la sécurité des données dans les protocoles d'application existants (par exemple LDAP, SMTP, Subversion, ...), bien que ces protocoles doivent être conscients de cette extension (par exemple SMTP auth ). Que ce soit et comment il fournit une authentification sécurisée et un cryptage des données dépend fortement de ce que mécanisme sous-jacent est utilisé dans ce cadre. Voici un exemple tiré de la documentation svnserve : " Le mécanisme CRAM-MD5 intégré ne prend pas en charge le chiffrement, mais DIGEST-MD5 le fait ". Si vous souhaitez utiliser Kerberos avec SASL, vous aurez besoin d'un autre niveau d'indirection: GSS-API (qui est le plus couramment utilisé avec Kerberos, mais peut également autoriser d'autres mécanismes). (Notez que GSSAPI dans le contexte de SASL semble impliquer de toute façon Kerberos, contrairement à son GS2 successeur .)
L'objectif général de SSL/TLS est de sécuriser la communication (intégrité et confidentialité) entre un client et un serveur. Le client doit toujours vérifier l'identité du serveur SSL/TLS, et il fournit également des mécanismes pour que le serveur vérifie également l'identité du client. Ce qu'il peut faire dépend également de sa configuration. SSL/TLS est le plus couramment utilisé avec les certificats X.509: c'est ainsi qu'un navigateur peut vérifier l'identité d'un serveur HTTPS. Les serveurs peuvent également être configurés pour demander au client d'utiliser un certificat pour s'identifier (authentification par certificat client). Cependant, si vous souhaitez utiliser Kerberos, vous pouvez utiliser TLS suites de chiffrement Kerberos . C'est beaucoup moins courant, mais ils sont implémentés dans le JSSE .
Ses implémentations fournissent généralement des API similaires à celles que vous obtenez avec les connexions plain TCP: en Java, une fois configuré, vous pouvez plus ou moins utiliser un SSLSocket comme vous le feriez avec un plain Socket. Cela ne nécessite pas de prise de conscience spécifique par le protocole en haut du socket, bien que certains protocoles aient des commandes explicites pour basculer vers SSL/TLS à partir d'une connexion simple ( Implicit vs SSL/TLS explicite ). Il peut également fournir une authentification. En Java, le JSSE est l'implémentation SSL/TLS par défaut, qui vous donne accès à SSLSocket (ou SSLEngine si vous êtes assez courageux).
Vous voudrez peut-être lire " Quand utiliser Java GSS-API vs JSSE ", qui est similaire à" SASL vs SSL/TLS "(bien qu'il ne semble pas avoir été mis à jour depuis un certain temps, puisque le JSSE le fait prennent désormais en charge les suites de chiffrement Kerberos, au moins depuis Oracle Java 6).
J'admets que je connais moins SASL que SSL/TLS, mais le cryptage des données via SASL semble être plus difficile. Il ne semble pas avoir certaines fonctionnalités SSL/TLS telles que Perfect Forward Secrecy offert par les suites de chiffrement EDH . Il y a un exemple qui utilise SASL avec GSSAPI (Kerberos ici) dans le tutoriel JGSS : vous devez envelopper/dérouler les données explicitement, ce que vous n'auriez pas à faire lorsque vous utilisez SSLSockets.
Je pense que votre principale préoccupation devrait être de décider quel mécanisme d'authentification vous souhaitez utiliser en premier lieu: Kerberos, certificats X.509 ou autre chose. Cela aura plus d'impact sur votre architecture globale, et les deux peuvent être utilisés avec SASL et SSL/TLS (plus encore si vous utilisez SASL avec un mécanisme EXTERNAL, en plus d'une connexion SSL/TLS).
- Kerberos est très centralisé. Le client devra pouvoir contacter le KDC pour s'authentifier, en plus de pouvoir contacter votre serveur d'applications. Les clients devront également être configurés pour utiliser ce KDC. Du point de vue d'un utilisateur, il peut utiliser des mots de passe.
- X.509 est plus décentralisé. Cependant, vous devrez peut-être déployer une autorité de certification (ou en utiliser une commerciale) pour vos certificats d'utilisateur. Les utilisateurs devront recevoir des certificats et des clés privées, que certains pourraient trouver trop complexes.
JAAS entre en jeu parce que c'est le cadre général Java pour gérer l'authentification et l'autorisation. Il est très étroitement lié à la notion de gestionnaires de sécurité. Il vous donne la notion de Subject et Principal . Ce n'est pas directement lié aux protocoles ou à la communication, mais plutôt à la façon dont vous modélisez l'authentification et l'autorisation au sein de votre application. (Cela vous donne un ensemble standard de classes faire cela.)
(Je suggère généralement de parcourir les documents de référence Java qui mentionnent les mots que vous recherchez: JGSS, SASL, ..., bien qu'ils ne soient pas nécessairement faciles à lire.)
SSL contre SASL
Il est vrai que SASL n'est pas un protocole mais une couche d'abstraction. Il est également vrai que SSL et SASL fournissent en quelque sorte des fonctionnalités similaires. Les deux fournissent l'authentification, la signature des données et le cryptage.
SSL est fait au niveau de la couche transport et il est normalement transparent pour le protocole ci-dessous. Par exemple, vous pouvez utiliser SSL sur LDAP ou HTTP. Cependant, dans certains cas, une modification des protocoles existants est nécessaire pour passer en mode sécurisé. Par exemple, POP3 et IMAP sont étendus pour avoir une commande STARTTLS pour initier l'utilisation de SSL. Sous cet angle, cela ressemble à ce que fait SASL.
De l'autre côté, de nombreux protocoles sont également étendus pour fournir une capacité SASL. Ici est la liste des protocoles. Encore une fois, POP3 et IMAP sont deux d'entre eux et utilisent des commandes différentes pour lancer l'authentification.
Alors, quand devrions-nous utiliser SSL et quand devrions-nous utiliser SASL?
Une différence évidente entre SSL et SASL est que SASL vous permet de sélectionner différents mécanismes pour authentifier le client tandis que SSL est en quelque sorte lié pour faire l'authentification basée sur le certificat. En SASL, vous pouvez choisir d'utiliser GSSAPI, Kerberos, NTLM, etc.
En raison de cette différence, il existe certaines situations, il est juste plus intuitif d'utiliser SASL mais pas SSL. Par exemple, votre application cliente utilise Kerberos pour authentifier l'utilisateur final. Votre serveur doit authentifier le client. Étant donné que votre application cliente possède déjà des informations d'identification Kerberos (dans la terminologie Kerberos, un ticket), il est logique d'utiliser les informations d'identification Kerberos pour s'authentifier auprès du serveur. Bien sûr, vous pouvez toujours configurer SSL pour faire la même chose. Cependant, cela signifie qu'au-dessus de l'infrastructure Kerberos existante, vous devez configurer l'infrastructure de l'autorité de certification et corréler le certificat client avec les informations d'identification Kerberos. C'est faisable mais beaucoup de travail.
De plus, parfois, vous devez utiliser certaines fonctionnalités disponibles uniquement dans le mécanisme SASL mais pas SSL. Par exemple, Kerberos vous permet de transférer le ticket du client vers le serveur afin que le serveur puisse utiliser le ticket pour interroger certaines ressources au nom du client. Un exemple courant est que vous disposez d'un serveur d'applications et d'une base de données. L'application cliente s'authentifie auprès du serveur d'applications et le serveur d'applications doit interroger la base de données au nom du client à l'aide des informations d'identification du client. SSL ne peut pas vous fournir cette fonctionnalité, mais Kerberos la prend en charge. Donc, dans ce cas, vous devez choisir d'utiliser SASL.
Dans certains cas, vous souhaitez utiliser SSL mais pas SASL. Par exemple, l'extension du protocole n'est pas une option ou vous souhaitez crypter chaque paquet unique échangé à l'aide du protocole ci-dessous.
Quel est le lien entre GSSAPI et Kerberos et SASL
Selon cela page wiki , GSSAPI et Kerberos sont tous deux supportés mécaniquement dans SASL. GSSAPI est une interface de programmation générique. L'idée est de permettre au rédacteur d'application d'utiliser une seule API commune pour effectuer l'authentification, le chiffrement, etc. quel que soit le protocole utilisé en dessous. GSSAPI implémente Kerberos. Vous pouvez donc utiliser GSSAPI pour effectuer l'authentification Kerberos.
Comment JAAS est-il lié à SASL
Pour être honnête, je ne suis pas un Java. D'après ce que j'ai lu, il semble que JAAS soit juste un cadre d'authentification enfichable. Je crois que l'idée est similaire à GSSAPI. C'est pour fournir un seul interface de programmation quelle que soit la méthode d'authentification utilisée. Alors que GSSAPI se concentre sur l'authentification et l'échange de messages sécurisé, JAAS se concentre sur l'authentification et l'autorisation. Je ne trouve aucune preuve que JAAS est également l'un des mécanismes SASL. Je pense qu'il devrait être des classes d'assistance de Java vous aide à implémenter des mécanismes SASL personnalisés. Lors de l'implémentation du mécanisme SASL personnalisé, il peut être judicieux d'utiliser simplement JAAS.
SASL n'est pas un protocole mais une couche d'abstraction vers un mécanisme d'authentification. Si vous utilisez Digest-MD5 ou GSS-API comme mécanisme SASL, vous pouvez demander à SASL de chiffrer complètement votre trafic de données. C'est par exemple ce que je fais pour parler à vos serveurs Active Directory. Vous n'aurez pas besoin de SSL. Quel est votre cas d'utilisation. Veuillez élaborer!