Solución:
Es bastante difícil comparar SSL / TLS y SASL, porque SSL / TLS es un protocolo de comunicación, mientras que SASL es un marco, integrado con otros protocolos. (De hecho, puede usar ambos al mismo tiempo en algunas circunstancias).
Además, está mencionando Kerberos, que de hecho es un protocolo de autenticación (que se puede usar con SSL / TLS o SASL o ambos de forma independiente). Su pregunta parece sugerir que si desea utilizar Kerberos o no, uno de los principales subproblemas debe elegir primero.
SASL es esencialmente una capa indirecta para permitir sistemas de autenticación conectables y seguridad de datos en protocolos de aplicación existentes (por ejemplo, LDAP, SMTP, Subversion, …), aunque estos protocolos deben conocer esta extensión (por ejemplo, autenticación SMTP). El hecho de que proporcione autenticación y cifrado de datos seguros y cómo hacerlo dependerá en gran medida del mecanismo subyacente que se utilice dentro de este marco. Aquí hay un ejemplo del svnserve documentación: “El mecanismo integrado CRAM-MD5 no admite el cifrado, pero DIGEST-MD5 sí“. Si desea usar Kerberos con SASL, necesitará otro nivel de direccionamiento indirecto: GSS-API (que se usa más comúnmente con Kerberos, pero también puede permitir otros mecanismos). (Tenga en cuenta que GSSAPI en el contexto de SASL parece implicar Kerberos de todos modos, a diferencia de su GS2 sucesor.)
El objetivo general de SSL / TLS es asegurar la comunicación (integridad y confidencialidad) entre un cliente y un servidor. El cliente siempre debe verificar la identidad del servidor SSL / TLS, y proporciona mecanismos para que el servidor también verifique la identidad del cliente. Lo que puede hacer también depende de cómo esté configurado. SSL / TLS se usa más comúnmente con certificados X.509: así es como un navegador puede verificar la identidad de un servidor HTTPS. Los servidores también se pueden configurar para solicitar al cliente que utilice un certificado para identificarse (autenticación de certificado de cliente). Sin embargo, si desea utilizar Kerberos, puede utilizar conjuntos de cifrado TLS Kerberos. Esto es mucho menos común, pero se implementan en JSSE.
Sus implementaciones suelen proporcionar API similares a las que se obtienen con las conexiones TCP simples: en Java, una vez configurado, puede utilizar más o menos un SSLSocket como usarías un llano Socket. Esto no requiere un conocimiento específico por parte del protocolo en la parte superior del socket, aunque algunos protocolos tienen comandos explícitos para cambiar a SSL / TLS desde una conexión simple (SSL / TLS implícito o explícito). También puede proporcionar autenticación. En Java, JSSE es la implementación predeterminada de SSL / TLS, que le da acceso a SSLSocket (o SSLEngine si eres lo suficientemente valiente).
Es posible que desee leer “Cuándo usar Java GSS-API frente a JSSE“, que es similar a” SASL vs. SSL / TLS “(aunque no parece que se haya actualizado por un tiempo, ya que JSSE lo hace ahora es compatible con los conjuntos de cifrado Kerberos, al menos desde Oracle Java 6).
Admito que sé menos sobre SASL que sobre SSL / TLS, pero hacer el cifrado de datos a través de SASL parece que va a ser más trabajo. No parece tener ciertas características de SSL / TLS, como Perfect Forward Secrecy que ofrecen las suites de cifrado EDH. Hay un ejemplo que usa SASL con GSSAPI (Kerberos aquí) en el tutorial de JGSS: debe envolver / desenvolver los datos explícitamente, lo que no tendría que hacer al usar SSLSockets.
Creo que su principal preocupación debería ser decidir qué mecanismo de autenticación desea utilizar en primer lugar: Kerberos, certificados X.509 u otra cosa. Esto tendrá más impacto en su arquitectura general, y ambos se pueden usar con SASL y SSL / TLS (más si usa SASL con un EXTERNAL mecanismo, cuando está encima de una conexión SSL / TLS).
- Kerberos está muy centralizado. El cliente deberá poder comunicarse con el KDC para autenticarse, además de poder comunicarse con su servidor de aplicaciones. Los clientes también deberán configurarse para usar ese KDC. Desde el punto de vista de un usuario, puede utilizar contraseñas.
- X.509 está más descentralizado. Sin embargo, es posible que deba implementar una autoridad de certificación (o utilizar una comercial) para sus certificados de usuario. Los usuarios deberán recibir certificados y claves privadas, que algunos pueden encontrar demasiado complejas.
JAAS entra en juego porque es el marco general de Java para lidiar con la autenticación y la autorización. Está muy relacionado con la noción de administradores de seguridad. Te da la noción de Subject y Principal. Esto no está directamente relacionado con los protocolos o la comunicación, sino con la forma en que modela la autenticación y la autorización dentro de su aplicación. (Le brinda un conjunto estándar de clases para hacerlo).
(En general, sugeriría revisar los documentos de referencia de Java que mencionan las palabras que busca: JGSS, SASL, …, aunque no son necesariamente fáciles de leer).
SSL frente a SASL
Es cierto que SASL no es un protocolo sino una capa de abstracción. También es cierto que SSL y SASL brindan características similares. Ambos proporcionan autenticación, firma de datos y cifrado.
SSL se realiza en la capa de transporte y es normalmente transparente al protocolo de abajo. Por ejemplo, puede utilizar SSL en LDAP o HTTP. Sin embargo, en algunos casos, es necesario modificar los protocolos existentes para cambiar al modo seguro. Por ejemplo, POP3 e IMAP se amplían para tener un comando STARTTLS para iniciar el uso de SSL. Desde ese ángulo, esto es algo similar a lo que hace SASL.
Por otro lado, muchos protocolos también se amplían para proporcionar capacidad SASL. Aquí está la lista de protocolos. Nuevamente, POP3 e IMAP son dos de ellos y están usando diferentes comandos para iniciar la autenticación.
Entonces, ¿cuándo deberíamos usar SSL y cuándo deberíamos usar SASL?
Una diferencia obvia entre SSL y SASL es que SASL le permite seleccionar diferentes mecanismos para autenticar al cliente, mientras que SSL está vinculado para realizar la autenticación basada en el certificado. En SASL, puede optar por utilizar GSSAPI, Kerberos, NTLM, etc.
Debido a esta diferencia, hay algunas situaciones, simplemente es más intuitivo usar SASL pero no SSL. Por ejemplo, su aplicación cliente utiliza Kerberos para autenticar al usuario final. Su servidor necesita autenticar al cliente. Dado que su aplicación cliente ya tiene credenciales de Kerberos (en terminología de Kerberos, un ticket), tiene sentido usar las credenciales de Kerberos para autenticarse con el servidor. Por supuesto, siempre puede configurar SSL para que haga lo mismo. Sin embargo, eso significa que, además de la infraestructura Kerberos existente, debe configurar la infraestructura de la Autoridad de certificación y de alguna manera correlacionar el certificado del cliente con las credenciales de Kerberos. Es factible pero requiere mucho trabajo.
Además, a veces, es necesario utilizar algunas funciones que solo están disponibles en el mecanismo SASL pero no en SSL. Por ejemplo, Kerberos le permite reenviar el ticket del cliente al servidor para que el servidor pueda usar el ticket para consultar algunos recursos en nombre del cliente. Un ejemplo común es que tiene un servidor de aplicaciones y una base de datos. La aplicación cliente se autentica con el servidor de aplicaciones y el servidor de aplicaciones necesita consultar la base de datos en nombre del cliente utilizando las credenciales del cliente. SSL no puede proporcionarle esta función, pero Kerberos la admite. Entonces, en ese caso, debe elegir usar SASL.
En algunos casos, desea utilizar SSL pero no SASL. Por ejemplo, extender el protocolo no es una opción o desea encriptar cada paquete intercambiado usando el protocolo subyacente.
¿Cómo se relaciona GSSAPI con Kerberos y SASL?
Según esta página wiki, tanto GSSAPI como Kerberos son mecanismos compatibles en SASL. GSSAPI es una interfaz de programación genérica. La idea es permitir que el escritor de aplicaciones use una única API común para realizar autenticación, cifrado, etc., independientemente del protocolo que se use debajo. GSSAPI implementa Kerberos. Entonces, puede usar GSSAPI para realizar la autenticación Kerberos.
¿Cómo se relaciona JAAS con SASL?
Para ser honesto, no soy un experto en Java. Por lo que leí, parece que JAAS es solo un marco de autenticación conectable. Creo que la idea es similar a GSSAPI. Es para proporcionar una única interfaz de programación independientemente del método de autenticación que se utilice. Mientras que GSSAPI se centra en la autenticación y el intercambio seguro de mensajes, JAAS se centra en la autenticación y la autorización. No encuentro ninguna evidencia de que JAAS sea también uno de los mecanismos SASL. Creo que debería haber algunas clases auxiliares de la biblioteca de Java que le ayuden a implementar mecanismos SASL personalizados. Al implementar el mecanismo SASL personalizado, puede tener sentido simplemente usar JAAS.
SASL no es un protocolo, sino una capa de abstracción para algún mecanismo de autenticación. Si utiliza Digest-MD5 o GSS-API como mecanismo SASL, puede solicitar que SASL cifre completamente su tráfico de datos. Esto es, por ejemplo, lo que hago para hablar con sus servidores de Active Directory. No necesitará SSL. ¿Cuál es tu caso de uso? ¡Por favor elabora!