TLS y MTLS para Lync Server 2013

 

Última modificación del tema: 2013-11-07

Los protocolos de Seguridad de la capa de transporte (TLS) y Seguridad de la capa de transporte mutua (MTLS) ofrecen comunicaciones cifradas y autenticación de extremos en Internet. Microsoft Lync Server 2013 usa estos dos protocolos para crear la red de servidores de confianza y garantizar que todas las comunicaciones a través de esa red están cifradas. Todas las comunicaciones SIP entre los servidores se llevan a cabo a través de MTLS. Las comunicaciones SIP entre el cliente y el servidor se realizan a través de TLS.

TLS permite a los usuarios, a través de su software cliente, autenticar los servidores de Lync Server 2013 a los que se conectan. En una conexión TLS, el cliente solicita un certificado válido al servidor. Para que sea válido, el certificado debe haber sido emitido por una CA que también sea de confianza para el cliente y el nombre DNS del servidor debe coincidir con el nombre DNS del certificado. Si el certificado es válido, el cliente usa la clave pública del certificado para cifrar las claves de cifrado simétricas que se utilizarán para la comunicación, de modo que solo el propietario original del certificado puede usar su clave privada para descifrar el contenido de la comunicación. La conexión resultante es fiable y desde ese punto no es desafiada por otros servidores o clientes fiables. En este contexto, SSL, tal como se usa con los servicios web, se puede asociar como basada en TLS.

Las conexiones entre servidores dependen de MTLS para la autenticación mutua. En una conexión MTLS, el servidor de origen de un mensaje y el que lo recibe intercambian certificados procedentes de una CA de confianza para ambos. Los certificados permiten a los servidores demostrarse mutuamente sus identidades. En las implementaciones de Lync Server 2013, todos los clientes internos y servidores consideran válidos automáticamente los certificados emitidos por la CA de empresa que se encuentran durante su período de validez y no son revocados por la CA emisora, ya que todos los miembros de un dominio de Active Directory confían en la CA empresarial de ese dominio. En los escenarios de federación, ambos socios federados deben confiar en la CA que emite los certificados. Si así lo desea, cada socio puede utilizar una CA diferente, siempre y cuando el otro socio también confíe en esa CA. La manera más fácil de lograr esa confianza es configurar los servidores perimetrales para que el certificado de la CA raíz del socio figure entre sus CA raíz de confianza, o bien usar una CA de otro fabricante en la que confíen ambas partes.

TLS y MTLS ayudan a evitar los ataques de interceptación y de tipo "Man in the middle". En los ataques de tipo "Man in the middle", el atacante enruta las comunicaciones entre dos entidades de red a través del equipo del atacante sin que lo sepa ninguna de esas entidades. La especificación de TLS y Lync Server 2013 de servidores de confianza (solo los especificados en el Generador de topologías) mitiga el riesgo de un ataque man-in-the-middle parcialmente en la capa de aplicación mediante cifrado de un extremo a otro coordinado mediante la criptografía de clave pública entre los dos puntos de conexión, y un atacante tendría que tener un certificado válido y de confianza con la clave privada correspondiente y emitido al nombre del servicio al que el cliente se comunica para descifrar la comunicación. En todo caso, usted deberá seguir buenas prácticas de seguridad en su infraestructura de red (en este caso, DNS empresarial). Lync Server 2013 asume que el servidor DNS es de confianza de la misma manera que los controladores de dominio y los catálogos globales son de confianza, pero DNS proporciona un nivel de protección contra ataques de secuestro dns al evitar que el servidor de un atacante responda correctamente a una solicitud al nombre falsificado.

La figura siguiente muestra a un alto nivel cómo Lync Server 2013 usa MTLS para crear una red de servidores de confianza.

Conexiones de confianza en una red de Lync Server

437749da-c372-4f0d-ac72-ccfd5191696b