Introducción técnica al SSP de SChannel

Artículo
09/02/2016

Publicado: agosto de 2016

Se aplica a: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

En este tema de referencia para profesionales de TI se explica lo que es el proveedor de compatibilidad para seguridad (SSP) del canal seguro (SChannel) y los servicios de autenticación que ofrece mediante los protocolos de Seguridad de la capa de transporte (TLS) y Capa de sockets seguros (SSL).

Este tema incluye las siguientes secciones:

¿Qué son TLS, SSL y SChannel?
Escenarios comunes de TLS y SSL
Schannel SSP Technical Overview
Dependencias de TLS y SSL

Nota

TLS se describe en el tema Protocolo de seguridad de la capa de transporte.

DTLS, que se incluye en el SSP de SChannel, se describe en el tema Protocolo de seguridad de capa de transporte de datagramas.

¿Qué son TLS, SSL y SChannel?

Uno de los problemas que se deben solventar al administrar una red es la protección de los datos que se envían entre las aplicaciones a través de una red que no es de confianza. Puede usar TLS/SSL para autenticar los servidores y los equipos cliente y, luego, usarlo para cifrar los mensajes entre las partes autenticadas.

Los protocolos TLS y SSL, el protocolo DTLS y el protocolo de transporte de comunicaciones privadas (PCT) se basan en la criptografía de clave pública. El conjunto de protocolos de autenticación de SChannel ofrece estos protocolos. Todos los protocolos de Schannel usan un modelo de cliente y servidor. Para ver una lista de protocolos admitidos, consulte Conjuntos y protocolos de cifrado compatibles de Schannel SSP.

En el proceso de autenticación, un equipo cliente TLS/SSL envía un mensaje a un servidor TLS/SSL, y el servidor responde con la información adecuada para autenticarse. El cliente y el servidor realizan un intercambio adicional de claves de sesión y el cuadro de diálogo de autenticación finaliza. Cuando se completa la autenticación, la comunicación SSL entre el servidor y el cliente puede comenzar mediante el uso de las claves de cifrado simétrico que se establecen durante el proceso de autenticación.

Para que los servidores autentiquen a los clientes, TLS/SSL no requiere que las claves de servidor se almacenen en los controladores de dominio o en una base de datos, como los Servicios de dominio de Active Directory. Los clientes confirman la validez de las credenciales de un servidor con certificados de entidad de certificación raíz de confianza (CA), que se cargan al instalar un sistema operativo Windows Server. Por tanto, a menos que el servidor requiera autenticación de usuario, los usuarios no necesitan establecer cuentas antes de crear una conexión segura con un servidor.

Historial y estándares de TLS y SSL

SSL fue desarrollado por Netscape Communications Corporation en 1994 para proteger las transacciones a través de la World Wide Web. Poco después, el Grupo de trabajo de ingeniería de Internet (IETF) empezó a desarrollar un protocolo estándar que ofrecía la misma funcionalidad. Usaron SSL 3.0 como base para ese trabajo, que evolucionó hasta convertirse en el protocolo TLS. La implementación del protocolo TLS, que comenzó con Windows Server 2003, sigue estrechamente la especificación definida en las especificaciones siguientes que aparecen en la base de datos RFC de IETF:

TLS y SSL tienen un reconocimiento mucho mayor como los protocolos que proporcionan HTTP seguro (HTTPS) para las transacciones de Internet entre exploradores y servidores web. TLS/SSL también puede usarse para otros protocolos de nivel de aplicación, como el protocolo de transferencia de archivos (FTP), el protocolo ligero de acceso a directorios (LDAP) y el Protocolo simple de transferencia de correo (SMTP). TLS/SSL permite la autenticación de servidor y de cliente, el cifrado de datos y la integridad de datos en redes como la World Wide Web.

Diferencias entre TLS y SSL

Aunque hay algunas pequeñas diferencias entre SSL 3.0 y las versiones de TLS, esta guía de referencia hace mención del protocolo como TLS/SSL.

Nota

TLS y SSL 3.0 no son intercambiables, aunque sus diferencias son ínfimas. Si el cliente y el servidor no admiten el mismo protocolo, deben negociar un protocolo común para comunicarse correctamente.

Dado que SSL era vulnerable frente a los cada vez mayores ataques de seguridad, IETF desarrolló estándares de Internet para un protocolo más seguro, que es TLS. En la lista siguiente se describen las mejoras de TLS, más allá de la capacidad de SSL para proteger la comunicación en redes que no son de confianza.

El algoritmo de código de autentificación de mensajes de hash con claves (HMAC) reemplaza el algoritmo de código de autentificación de mensajes (MAC) de SSL.
TLS está normalizado y es un estándar de Internet, mientras que SSL tiene numerosas variantes.
TLS contiene mensajes de alerta adicionales.
SSL requiere certificados que los emite (o se encadenan de vuelta a) la CA raíz. Cuando se utiliza TLS, no siempre es necesario incluir los certificados encadenados de vuelta a la CA raíz. Puede usar una entidad intermedia.
Los algoritmos de Fortezza no se incluyen en las RFC de TLS porque no están disponibles para su revisión pública.

Ventajas de TLS y SSL

TLS/SSL ofrece numerosas ventajas con respecto a otros métodos de autenticación de clientes y servidores. En la tabla siguiente se describen algunas de ellas:

Ventaja	Descripción
Autenticación sólida, privacidad de mensajes e integridad.	TLS/SSL puede ayudar a proteger los datos transmitidos mediante un cifrado. TLS/SSL autentica servidores y, de forma opcional, autentica a los clientes para comprobar las identidades de los sistemas que actúan en una comunicación segura. También proporciona integridad de los datos a través de un valor de comprobación de integridad. Además de proteger contra la divulgación de datos, el protocolo de seguridad TLS/SSL puede usarse para ayudar a protegerse contra ataques de enmascaramiento, ataques de tipo "Man-in-the-middle" o "Bucket-brigade", ataques de reversión y de reproducción.
Interoperabilidad	TLS/SSL funciona con la mayoría de exploradores web y en la mayoría de sistemas operativos y servidores web. A menudo se encuentra integrado en los lectores de noticias, servidores LDAP y una variedad de otras aplicaciones comercialmente disponibles.
Flexibilidad de algoritmo	TLS/SSL ofrece opciones para los mecanismos de autenticación, algoritmos de cifrado y algoritmos hash que se usan durante la sesión segura.
Facilidad de implementación	Muchas aplicaciones usan TLS/SSL de forma transparente en sistemas operativos Windows Server. Puede usar TLS para una exploración más segura cuando utiliza Internet Explorer e Internet Information Services (IIS). Si el servidor ya tiene instalado un certificado de servidor, basta con activar la casilla en Internet Explorer.
Facilidad de uso	Dado que TLS/SSL se implementa en el nivel de aplicación, la mayoría de sus operaciones son completamente invisibles para el equipo cliente. Esto permite que aunque el cliente tenga poco o ningún conocimiento sobre la seguridad de las comunicaciones, esté protegido frente a atacantes.

Limitaciones de TLS y SSL

Existen algunas limitaciones en el uso de TLS/SSL, como se describe en la tabla siguiente.

Limitación	Descripción
Mayor carga del procesador	Se trata de la limitación más importante al implementar TLS/SSL. La criptografía, específicamente en las operaciones de claves públicas, hace un uso intensivo de la CPU. Como resultado, el rendimiento varía cuando se utiliza SSL. Lamentablemente, no hay manera de saber cuánto rendimiento perderá. El rendimiento varía según la frecuencia con que se establecen las conexiones y sus duraciones. TLS usa la mayor parte de los recursos mientras está estableciendo conexiones.
Mayor sobrecarga administrativa	Un entorno de TLS/SSL es complejo y requiere mantenimiento. El administrador del sistema debe configurar el sistema y administrar los certificados.

Mayor carga del procesador

Se trata de la limitación más importante al implementar TLS/SSL. La criptografía, específicamente en las operaciones de claves públicas, hace un uso intensivo de la CPU. Como resultado, el rendimiento varía cuando se utiliza SSL. Lamentablemente, no hay manera de saber cuánto rendimiento perderá. El rendimiento varía según la frecuencia con que se establecen las conexiones y sus duraciones. TLS usa la mayor parte de los recursos mientras está estableciendo conexiones.

Mayor sobrecarga administrativa

Un entorno de TLS/SSL es complejo y requiere mantenimiento. El administrador del sistema debe configurar el sistema y administrar los certificados.

Escenarios comunes de TLS y SSL

Muchas personas consideran TLS y SSL como protocolos que se usan con los exploradores web para navegar por Internet de forma más segura. Sin embargo, también son protocolos de propósito general que se pueden usar cuando hay necesidades de autenticación y protección de datos. De hecho, la capacidad para tener acceso a estos protocolos a través de la interfaz del proveedor de servicios de seguridad (SSPI) implica que se pueden usar prácticamente con cualquier aplicación. Muchas aplicaciones se modifican para aprovechar las ventajas de las características de TLS/SSL. En la tabla siguiente se muestran ejemplos de cómo se puede usar TLS/SSL.

Escenario	Descripción
Transacciones de seguridad SSL con un sitio web de comercio electrónico	Esta situación representa un uso típico de SSL entre un explorador y un servidor web. Un ejemplo es un sitio de compras de comercio electrónico donde los clientes deban proporcionar sus números de tarjeta de crédito. En primer lugar, el protocolo confirma que el certificado del sitio web es válido y, después, envía la información de la tarjeta de crédito como texto cifrado. En este tipo de transacción, cuando el certificado del servidor proviene de una fuente de confianza, la autenticación solo se produce para el servidor. TLS/SSL debe estar habilitado en la página web (por ejemplo, un formulario de pedido) donde se producen las transacciones de datos.
Acceso para clientes autenticados a un sitio web con seguridad SSL	El cliente y el servidor necesitan certificados de una entidad de certificación (CA) de confianza mutua. Con el SSP de SChannel, los certificados de cliente se pueden asignar, con un patrón de uno a uno o de varios a uno, a cuentas de usuario o equipos en un sistema operativo Windows Server. Luego, se pueden administrar a través de Usuarios y equipos de Active Directory, y los usuarios se pueden autenticar en un sitio web sin proporcionar una contraseña. La asignación de varios a uno tiene distintos usos. Por ejemplo, si desea conceder acceso a varios usuarios a material confidencial, puede crear un grupo, asignar los certificados de los usuarios al grupo y otorgarle al grupo los permisos necesarios para el material. En la asignación de uno a uno, el servidor tiene una copia del certificado del cliente y cuando un usuario inicia sesión desde el equipo cliente, el servidor comprueba que son idénticos. Esta asignación uno a uno se utiliza normalmente para obtener material privado, como por ejemplo en un sitio web de banca en el que solo una persona tiene derecho a ver una cuenta personal.
Acceso remoto	El trabajo a distancia es un uso común del SSP. de SChannel Puede usar esta tecnología para ofrecer autenticación y protección de datos cuando los usuarios inician sesión de forma remota en sistemas o redes basados en Windows. Los usuarios pueden obtener un acceso más seguro a su correo electrónico o sus aplicaciones de empresa desde casa o cuando viajan, lo que reduce el riesgo de exposición de la información a cualquier persona en Internet.
Acceso de SQL Server	Puede requerir la autenticación de un equipo cliente cuando se conecte a un servidor que ejecute SQL Server. El cliente o el servidor pueden configurarse para requerir el cifrado de los datos que se transfieren entre ellos. La información altamente confidencial, como las bases de datos financieras o médicas, se puede proteger para evitar el acceso no autorizado y la divulgación de información sobre la red.
Correo electrónico	Cuando se utiliza Exchange Server, puede usar el SSP de SChannel para ayudar a proteger los datos cuando se mueven entre servidores de la intranet o de Internet. La seguridad de un extremo a otro podría requerir el uso de Extensiones seguras multipropósito al correo de Internet (S/MIME). Sin embargo, cuando se ayuda a proteger los datos en un intercambio entre servidores, las empresas pueden usar Internet para transferir de forma segura correos electrónicos entre divisiones dentro de la misma compañía, sucursales y socios. Esto se puede hacer independientemente de si se utiliza S/MIME.

Arquitectura del SSP de SChannel

En los sistemas operativos Windows Server, el conjunto de protocolos de autenticación de SChannel contiene TLS. En el diagrama siguiente se muestra dónde se enmarca el SSP de SChannel entre estas y otras tecnologías. Las aplicaciones de cliente o de servidor usan Secur32.dll mediante llamadas SSPI para comunicarse con el Servicio de subsistema de autoridad de seguridad local (LSASS).

Arquitectura del SSP de SChannel

Schannel Architecture

En la tabla siguiente se muestran las descripciones de los elementos que participan en TLS/SSL.

Elementos del subsistema de seguridad que se usan en la autenticación de TLS y SSL

Elemento	Descripción
Schannel.dll	Protocolo de autenticación TLS/SSL. Este protocolo ofrece autenticación en un canal cifrado, en lugar de un canal libre menos seguro.
Lsasrv.dll	LSASS aplica las directivas de seguridad y actúa como el administrador de paquetes de seguridad de la autoridad de seguridad local.
Netlogon.dll	En cuanto a los servicios TLS, el servicio Netlogon transmite la información del certificado del usuario a través de un canal SSL al controlador de dominio, para asignar el certificado del usuario a una cuenta de usuario.
Secur32.dll	El proveedor de autenticaciones múltiples que implementa SSPI.

El SSP de SChannel habilita el conjunto de protocolos de autenticación, que es compatible con la interfaz de programación de aplicaciones (API) del SSPI que ofrece los servicios de seguridad para los sistemas operativos Windows Server.

La interfaz del proveedor de compatibilidad para seguridad (SSPI) de Microsoft es la base de la autenticación en el sistema operativo Windows. Es decir, las aplicaciones y los servicios de infraestructura que requieren autenticación utilizan SSPI para proporcionarla. Cuando un cliente y un servidor deben estar autenticados para que puedan comunicarse de forma más segura, se enrutan las solicitudes de autenticación a la SSPI, que completa el proceso de autenticación, independientemente del protocolo de red actualmente en uso. La SSPI es la implementación de la API de servicio de seguridad genérico (GSSAPI). Para más información sobre GSSAPI, consulte las siguientes RFC en la base de datos de RFC de IETF.

Para información sobre la arquitectura SSPI de todos los SSP y cómo se integra el proveedor de Kerberos en esta arquitectura, consulte Security Support Provider Interface Architecture.

Puede usar el SSP de SChannel para obtener acceso a servicios habilitados para web, como el correo electrónico o la información personal que se sirve en páginas web. El SSP de SChannel usa certificados de clave pública para autenticar las partes. Se incluyen cuatro protocolos de autenticación en el conjunto. Al autenticar las partes, seleccionará uno de los cuatro protocolos en el siguiente orden de preferencia:

Versión 1.2 de TLS
Versión 1.1 de TLS
Versión 1.0 de TLS
Versión 3.0 de SSL

El SSP de SChannel seleccionará entonces el protocolo de autenticación preferido que tanto el cliente como el servidor admitan. Por ejemplo, si un servidor admite los cuatro protocolos de SChannel y el equipo cliente solo admite SSL 3.0, el proveedor de SChannel utilizará SSL 3.0 para la autenticación.

Administración de los emisores de confianza en la autenticación de cliente

Antes de Windows Server 2012 y Windows 8, los procesos o aplicaciones que usaban el SSP de SChannel (entre los que se incluyen HTTP.sys e IIS) podían proporcionar una lista de emisores de confianza que admitían para la autenticación de clientes. Esta información se ofrecía a través de una lista de certificados de confianza (CTL).

Cuando se requiere la autenticación del equipo cliente mediante SSL o TLS, el servidor puede configurarse para enviar una lista de emisores de certificados de confianza. Esta lista contiene el conjunto de emisores de certificados en los que el servidor confiará y servirá como una sugerencia para el equipo cliente respecto a qué certificado de cliente debe seleccionar si hay varios disponibles. Además, la cadena de certificados que el equipo cliente envía al servidor debe validarse con la lista de emisores de confianza configurados.

En Windows Server 2012 y Windows 8, se realizaron cambios en el proceso de autenticación subyacente, de forma que:

Ya no se admite la administración de listas de emisores de confianza basada en CTL.
El envío de la lista de emisores de confianza de forma predeterminada está desactivado de forma predeterminada. El valor predeterminado de la clave de registro SendTrustedIssuerList ahora es 0 (desactivado de forma predeterminada), en lugar de 1.
Se conserva la compatibilidad con las versiones anteriores de sistemas operativos Windows.

Esto permite una manejabilidad más familiar gracias a los cmdlets de administración de certificados existentes en el proveedor de Windows PowerShell y las herramientas de línea de comandos, como certutil.exe. Aunque el tamaño máximo de la lista de entidades de certificación de confianza que admite el SSP de SChannel (16 KB) sigue siendo el mismo que en Windows Server 2008 R2, en Windows Server 2012 hay un nuevo almacén de certificados dedicados para los emisores de autenticación de cliente con el objetivo de que los certificados que no están relacionados no se incluyan en el mensaje de cliente/servidor.

Cómo funciona

La lista de emisores de confianza se configura mediante el uso de almacenes de certificados: un almacén de certificados de equipos global predeterminado y otro que es opcional por sitio. El origen de la lista se determina como se indica a continuación:

Si hay un almacén de credenciales concreto configurado para el sitio, se utilizará como origen.
Si no hay certificados en el almacén definido por la aplicación, SChannel comprueba el almacén de emisores de autenticación de cliente en el equipo local. Si los certificados están presentes, SChannel utiliza ese almacén como el origen.
Si ninguno de los almacenes locales o globales contienen certificados, el SSP de SChannel usará el almacén de entidades de certificación raíz de confianza como el origen de la lista de emisores de confianza. (Este también es el comportamiento en Windows Server 2008 R2).

Puede crear una lista de nombres probables de emisores de certificados que ofrezcan al usuario final sugerencias sobre cuál elegir. Esta lista puede configurarse mediante la directiva de grupo.

Si el almacén de entidades de certificación raíz de confianza contiene una mezcla de certificados de emisores raíz (autofirmados) y de entidades de certificación (CA), de forma predeterminada solo se enviarán los certificados de emisores de CA al servidor.

Cómo configurar SChannel para usar el almacén de certificados con emisores de confianza

De forma predeterminada, el SSP de SChannel usará los almacenes como se describió anteriormente para administrar la lista de emisores de confianza. Se pueden seguir usando los cmdlets de administración de certificados existentes en el proveedor de Windows PowerShell y las herramientas de línea de comandos, como certutil.exe para administrar certificados.

Para más información sobre la administración de certificados mediante el proveedor de Windows PowerShell, consulte Cmdlets de administración de AD CS en Windows.

Para información sobre cómo administrar certificados mediante la utilidad de certificados, consulte certutil.exe.

Para información sobre qué datos (incluido el almacén definido por la aplicación) se definen para una credencial de SChannel, consulte Estructura SCHANNEL_CRED (Windows).

Configuración de una aplicación o característica para usar el almacén de emisores de autenticación de cliente

Algunas tecnologías no usan el almacén de emisores de autenticación de cliente de forma predeterminada. En estos casos, se debe configurar la tecnología para utilizar el almacén.

Por ejemplo, con el servidor web, HTTP.sys, que implementa la pila del servidor HTTP de Windows, no está configurado para usar el almacén de emisores de autenticación de cliente de forma predeterminada.

Para configurar HTTP. SYS para que use el almacén de emisores de autenticación de cliente, puede utilizar el comando siguiente:

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

Para encontrar los valores de certhash y appid en el servidor, puede usar el comando siguiente:

netsh http show sslcert

Valores predeterminados de los modos de confianza

Hay tres modos de confianza de autenticación de cliente que admite el SSP de SChannel. El modo de confianza controla cómo se realiza la validación de la cadena de certificados del cliente. Se trata de una configuración de todo el sistema que se controla mediante REG_DWORD "ClientAuthTrustMode" en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Value	Modo de confianza	Descripción
0	Confianza de la máquina (valor predeterminado)	Requiere que un certificado de la lista de emisores de confianza emita el certificado de cliente.
1	Confianza de raíz exclusiva	Requiere que un certificado de cliente esté enlazado con un certificado de raíz que se encuentre en el almacén de emisores de confianza especificado por el llamador. El certificado también se debe emitir desde la lista de emisores de confianza.
2	Confianza de CA exclusiva	Requiere que un certificado de cliente esté enlazado con un certificado de CA intermedio o un certificado de raíz del almacén de emisores de confianza especificado por el llamador.

Para información sobre los errores de autenticación debido a problemas de configuración en la lista de emisores de confianza, consulte el artículo 280256 de Microsoft Knowledge Base.

Dependencias de TLS y SSL

TLS y SSL dependen de varias tecnologías y recursos relacionados para funcionar correctamente. En la tabla siguiente se describen estos recursos y tecnologías y se resume cómo se relacionan con la autenticación TLS/SSL.

Dependencia	Descripción
Sistema operativo	La autenticación SSL y TLS se basa en la funcionalidad de cliente que se integra en los sistemas operativos Windows Server y los de cliente de Windows. Si un cliente o un servidor está ejecutando un sistema operativo que no admite TLS/SSL, no puede usar la autenticación TLS/SSL.
Conectividad de red TCP/IP	Para que la autenticación TLS o SSL se produzca, debe haber conectividad de red TCP/IP entre el cliente y el servidor de destino. Para obtener más información, consulte TCP/IP.
Dominio de Active Directory	Cuando una aplicación de servidor requiere autenticación del cliente, el SSP de SChannel intenta asignar automáticamente el certificado que facilita el cliente a una cuenta de usuario. Puede autenticar a los usuarios que inician sesión con un certificado de cliente mediante la creación manual de asignaciones, que relacionan la información del certificado con una cuenta de usuario de Windows. Después de crear y habilitar una asignación de certificados, cada vez que un cliente presente un certificado, la aplicación de servidor asociará automáticamente ese usuario a la cuenta de usuario correspondiente en el sistema operativo Windows. Debe usar cuentas de usuario en Servicios de dominio de Active Directory si quiere usar la asignación de certificados. Para obtener más información, consulte Introducción a los Servicios de dominio de Active Directory.
Entidades de certificación de confianza	Dado que la autenticación se basa en certificados digitales, las entidades de certificación (CA) (como Verisign o Servicios de certificados de Active Directory) son una parte importante de TLS/SSL. Una CA es un certificado de confianza mutua que no es de Microsoft que confirma la identidad del solicitante de un certificado (normalmente, un usuario o equipo) y, después, emite el solicitante de un certificado. El certificado enlaza la identidad del solicitante con una clave pública. Las CA también renuevan y revocan certificados según sea necesario. Por ejemplo, si a un cliente se le muestra un certificado de servidor, el equipo cliente comprueba si hay coincidencia entre la CA del servidor y la lista del cliente de CA de confianza. Si la CA emisora es de confianza, el cliente comprobará que el certificado es auténtico y que no se ha alterado. Para más información, consulte Información general de Servicios de certificados de Active Directory.

Vea también

Referencia técnica del proveedor de compatibilidad con seguridad Schannel

Compartir a través de