¿Certificados TLS enlazados a puertos? (1 autofirmado y 1 CA)

1

Para mi juego de Android, quiero asegurar la conexión entre el servidor y sus clientes a través de certificados TLS en cada lado, debido a los datos confidenciales que se intercambian a través de un sistema de inicio de sesión basado en token y otros datos de usuario. Los navegadores web también deben acceder al mismo dominio pero recibir diferentes datos servidos.

¿Es posible utilizar dos tipos diferentes de certificados en el dominio de los servidores vinculados a los puertos? Uno autofirmado para el servidor (sin CA propia) y uno autofirmado (codificado en el cliente) para las conexiones de gameclient al puerto 9443. ¿Uno de una CA como letsencrypt.org para navegadores web que se conectan al puerto 443?

¿Tengo que ejecutar 2 servidores http diferentes para eso en la misma máquina?

Ejemplo: Un cliente del juego que se conecta a example.com (o la dirección IP directa con el puerto 9443) se autentica como un cliente válido y, por lo tanto, puede registrarse, iniciar sesión o actualizar los datos del juego.

El navegador que se conecta a example.com (puerto 443) ve un sitio web, puede acceder a los perfiles de los jugadores que son páginas HTML simples.

Mi investigación hasta ahora: Ya vi en el archivo de configuración del ejemplo de openssl aquí , ¿el uso de diferentes subdominios como nombre común para cada certificado puede funcionar? Pero no se menciona si algo funciona vinculado a los puertos.

Aprecio tu ayuda. Gracias.

    
pregunta Androphin 22.11.2018 - 12:22
fuente

2 respuestas

0
  

¿Es posible utilizar dos tipos diferentes de certificados en el dominio de los servidores vinculados a los puertos?

Sí, es posible utilizar diferentes certificados en diferentes puertos.

  

¿Tengo que ejecutar 2 servidores http diferentes para eso en la misma máquina?

Los servidores web como nginx o apache soportan la ejecución del mismo servidor en varios puertos con diferentes certificados al mismo tiempo. Pero también es posible ejecutar diferentes servidores en diferentes puertos.

    
respondido por el Steffen Ullrich 22.11.2018 - 20:43
fuente
0

Al momento de escribir este documento, los detalles de la vinculación de token de TLS están siendo redactados activamente por el IETF "tokbind" Grupo de trabajo y se propuso inicialmente en RFC8471 , "The Token Binding Protocol Version 1.0". El resumen de ese documento RFC dice: "El protocolo Token Binding permite que las aplicaciones cliente / servidor creen enlaces TLS de larga duración, identificables de manera única, que abarcan múltiples sesiones y conexiones TLS". Si bien no restringe específicamente el token a un número de puerto en particular, está claro que un enlace TLS que abarca múltiples sesiones / conexiones puede aplicarse naturalmente a un número de puerto en particular. En otras palabras, el token está vinculado al origen (es decir, esquema-puerto-host triple) del URI donde el servicio HTTPS está escuchando. Esto es de esperar, ya que SOP, a.k.a. Same-Origin-Policy es uno de los conceptos más fundamentales de seguridad de aplicaciones web.

La implementación de este protocolo de enlace de token requiere soporte para la extensión TLS en el software del cliente y del servidor. Según RFC8473, "Token Binding over HTTP", Sección 4 : la configuración que estás describiendo es conocido como un escenario de "primera parte" o "mismo sitio". Esto está en oposición a un escenario federado donde un IdP (Proveedor de Identidad) enlaza el token a través de múltiples servicios TLS.

Las modificaciones de la capa de la aplicación, es decir, los encabezados HTTP como Include-Referred-Token-Binding-ID y Sec-Token-Binding como se define en RFC8473 no son necesarios en este caso, aunque son necesarios para los casos de uso de federación donde los clientes pueden tener solicitudes redirigidas a proveedores de identidad. Un caso de uso del mismo sitio / primera parte (o como lo ha mencionado, "enlazado a puerto") solo requiere soporte de capa de transporte para la extensión TLS token_binding cuyos datos de protocolo se detallan en Secciones 2 y 3 de RFC8472, "Extensión de seguridad de la capa de transporte (TLS) para la negociación del protocolo de enlace de token" . Las unidades de datos de protocolo TLS ClientHello y ServerHello comunican el soporte para la extensión y sus parámetros clave.

Para obtener más información sobre el protocolo en sí, consulte los documentos RFC a los que se hace referencia y la cuenta de TokenBinding GitHub . También hay un repositorio mod_token_binding publicado por el usuario de GitHub zmartzone que tiene un módulo de Apache 2.4 que implementa esta función. Además, Google ha publicado ngx_token_binding en GitHub, que es un módulo NGINX que admite la extensión TLS. De acuerdo con este documento [Intención de Implementar: Enlace de Token] para Chromium, la implementación del lado del navegador se divide entre BoringSSL y SSLClientSocket de Chromium. El documentos del sitio web de Windows IT Pro Center vincula el token vinculante para Windows Server 2016 y Windows 10. Espero que esto ayude!

    
respondido por el Derek Callaway 22.11.2018 - 14:41
fuente

Lea otras preguntas en las etiquetas