encryption - que - ssl wikipedia

Seguridad y Autenticación: SSL vs SASL

Question

Tengo entendido que SSL combina un algoritmo de cifrado (como AES, DES, etc.) con un método de intercambio de claves (como Diffier-Hellman) para proporcionar servicios seguros de cifrado e identificación entre dos puntos finales en una red no segura (como Internet) .

Tengo entendido que SASL es un protocolo MD5 / Kerberos que hace prácticamente lo mismo.

Entonces mi pregunta: ¿cuáles son los pros / contras para elegir ambos y qué escenarios hacen que sea más preferible? Básicamente, estoy buscando algunas pautas a seguir al elegir SSL o ir con SASL. ¡Gracias por adelantado!

Answer 1

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, mencionas 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 usa o no Kerberos uno de los principales subproblemas que debe elegir primero.

SASL es esencialmente una capa indirecta para permitir sistemas de autenticación conectables y seguridad de datos en protocolos de aplicaciones existentes (por ejemplo, LDAP, SMTP, Subversion, ...), aunque estos protocolos deben conocer esta extensión (por ejemplo, autenticación SMTP ). Si y cómo proporciona autenticación segura y cifrado de datos depende en gran medida de qué mecanismo subyacente se utiliza dentro de este marco. Aquí hay un ejemplo de la documentación de svnserve : " El mecanismo integrado CRAM-MD5 no es compatible con el cifrado, pero DIGEST-MD5 sí lo hace ". Si desea usar Kerberos con SASL, necesitará otro nivel de GSS-API indirecto: GSS-API (que se usa con mayor frecuencia 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 sucesor GS2 ).

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 verifique también 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 pueden configurarse para solicitar al cliente que use un certificado para identificarse (autenticación de certificado de cliente). Sin embargo, si desea usar Kerberos, puede usar conjuntos de cifrado TLS Kerberos . Esto es mucho menos común, pero se implementan en el JSSE .

Sus implementaciones generalmente proporcionan APIs similares a las que obtienes con conexiones TCP simples: en Java, una vez configurado, puedes usar un SSLSocket más o menos como lo harías con un Socket simple. Esto no requiere 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 ( Implicit vs Explicit SSL / TLS ). También puede proporcionar autenticación. En Java, JSSE es la implementación SSL / TLS predeterminada, que le da acceso a SSLSocket (o SSLEngine si es lo suficientemente valiente).

Es posible que desee leer " Cuándo usar Java GSS-API vs. JSSE ", que es similar a "SASL vs. SSL / TLS" (aunque parece que no se ha actualizado durante un tiempo, ya que JSSE no admite Conjuntos de cifrado Kerberos ahora, al menos desde Oracle Java 6).

Admitiré que sé menos sobre SASL que sobre SSL / TLS, pero al hacer un cifrado de datos a través de SASL parece que va a haber más trabajo. No parece tener ciertas características de SSL / TLS, como Perfect Forward Secrecy, ofrecidas por EDH Cipher Suites . Hay un ejemplo que usa SASL con GSSAPI (Kerberos aquí) en el tutorial de JGSS : necesita envolver / desenvolver los datos explícitamente, lo que no tendría que hacer cuando use SSLSocket .

Creo que su principal preocupación debería ser decidir qué mecanismo de autenticación desea usar en primer lugar: Kerberos, certificados X.509 u otra cosa. Esto tendrá un mayor impacto en su arquitectura general, y ambos se pueden usar con SASL y SSL / TLS (más aún si usa SASL con un mecanismo EXTERNAL , cuando está encima de una conexión SSL / TLS).

• Kerberos está muy centralizado. El cliente deberá poder ponerse en contacto con el KDC para autenticarse, además de poder ponerse en contacto con su servidor de aplicaciones. Los clientes también deberán estar configurados para usar ese KDC. Desde el punto de vista de un usuario, pueden usar contraseñas.
• X.509 está más descentralizado. Sin embargo, puede necesitar implementar una Autoridad de Certificación (o usar una comercial) para sus certificados de usuario. Los usuarios necesitarán recibir certificados y claves privadas, que algunos pueden considerar demasiado complejos.

JAAS entra en esto porque es el marco general de Java para tratar con autenticación y autorización. Está muy relacionado con la noción de gerentes 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 da un conjunto estándar de clases para hacerlo).

(En general, sugiero revisar los documentos de referencia de Java que mencionan las palabras que buscas: JGSS, SASL, ..., aunque no necesariamente son fáciles de leer).

Answer 2

SASL no es un protocolo sino una capa de abstracción de algunos mecanismos de autenticación. Si utiliza Digest-MD5 o GSS-API como su mecanismo SASL, puede solicitar SASL para encriptar por completo su tráfico de datos. Esto es, por ejemplo, lo que hago para hablar con sus servidores de Active Directory. No necesitarás SSL. ¿Cuál es tu caso de uso? ¡Por favor elabora!

Answer 3

SSL vs SASL

Es cierto que SASL no es un protocolo sino una capa de abstracción. También es cierto que SSL y SASL están proporcionando características similares. Ambos proporcionan autenticación, firma de datos y encriptación.

SSL se realiza en la capa de transporte y normalmente es transparente para el protocolo subyacente. Por ejemplo, puede usar SSL en LDAP o HTTP. Sin embargo, en algunos casos, la modificación de los protocolos existentes es necesaria para pasar al modo seguro. Por ejemplo, POP3 e IMAP se extienden para tener un comando STARTTLS para iniciar el uso de SSL. Desde ese ángulo, esto es similar a lo que hace SASL.

Por otro lado, muchos protocolos también se extienden para proporcionar capacidad SASL. Here 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 es un tipo de enlace para realizar la autenticación basada en el certificado. En SASL, puede elegir usar GSSAPI, Kerberos, NTLM, etc.

Debido a esta diferencia, existen algunas situaciones, es más intuitivo usar SASL pero no SSL. Por ejemplo, su aplicación cliente está utilizando Kerberos para autenticar al usuario final. Tu servidor necesita autenticar al cliente. Dado que su aplicación cliente ya tiene una credencial de Kerberos (en la 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 hacer lo mismo. Sin embargo, eso significa que, además de la infraestructura de Kerberos existente, debe configurar el infracurso de la Autoridad de certificación y correlacionar de alguna manera el certificado del cliente con las credenciales de Kerberos. Es factible pero mucho trabajo.

Además, a veces, necesita usar algunas características que están disponibles solo en el mecanismo SASL pero no en el 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 característica, pero Kerberos lo admite. Entonces, en ese caso, debe elegir usar SASL.

En algunos casos, desea usar SSL pero no SASL. Por ejemplo, extender el protocolo no es una opción o si desea encriptar cada paquete intercambiado utilizando el protocolo subyacente.

¿Cómo se relaciona GSSAPI con Kerberos y SASL?

De acuerdo con esta Here , tanto GSSAPI como Kerberos son compatibles mechansim en SASL. GSSAPI es una interfaz de programación genérica. La idea es permitir que el escritor de la aplicación use una única API común para realizar la autenticación, el cifrado, etc. independientemente del protocolo que se utilice debajo. GSSAPI implementa Kerberos. Entonces, puedes usar GSSAPI para hacer la autenticación de Kerberos.

¿Cómo se relaciona JAAS con SASL?

Para ser sincero, no soy un experto en Java. Según 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 de qué método de autenticación está utilizando. Mientras que GSSAPI se centra en la autenticación y el intercambio de mensajes seguros, JAAS se está centrando 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 Java que te ayuden a implementar mecanismos SASL personalizados. Al implementar el mecanismo SASL personalizado, puede tener sentido utilizar JAAS.