Autenticación mutua: ¿autenticación del cliente al servidor a través de IP / FQDN?

  

¿Hay alguna forma de implementar la autenticación del cliente en el lado del servidor en función de la IP / FQDN presentada por el cliente?

Sí, esto se puede hacer. Para el certificado del servidor, el cliente verifica no solo la cadena de certificados del certificado del servidor, sino que también compara el asunto con el nombre de host de la URL. Con los certificados de cliente, el servidor debe realizar verificaciones similares, es decir, verificar el asunto del certificado contra el sujeto esperado.

Pero la pregunta sigue siendo cuál debería ser el tema esperado. En el caso de una VPN, esta podría ser la dirección IP del cliente o el FQDN según lo determine un búsqueda DNS inversa hacia adelante confirmada . O el servidor podría tener una configuración específica sujeta a la expectativa de cada punto final de VPN. O si esto es solo una VPN para conectar un solo cliente a la empresa, el certificado del cliente podría contener el correo electrónico o el nombre de cuenta del usuario.

Por lo tanto, en resumen: sí, esto se puede hacer pero no hay una sola manera verdadera. En cambio, la forma en que se debe realizar el tema depende de cómo se utilizará el producto y los diferentes productos ofrecen diferentes formas de verificar el tema del certificado.

La forma en que autentica los certificados de un par en la autenticación TLS mutua no es, en rigor, parte del propio TLS, sino que forma parte de la política de la aplicación.

Cómo la aplicación comprueba la autenticidad de un certificado, por ejemplo, verificando que el FQDN / IP del par coincida con lo que está escrito en el campo C (ommon) N (ame) o S (ubject) A (lternative) N (ame) o O (rganizational) U (nit) o verificando el O (rganization) ) para un valor específico o para verificar las restricciones del uso de clave extendida, son específicas de la aplicación.

Para la mayoría de las aplicaciones, es suficiente autenticar el certificado del cliente confiando en el CN y el Emisor. Esto significa que escribiría la política de autorización en función del CN del certificado. Esto permite que los clientes sean móviles (para moverse a diferentes direcciones IP) sin que la CA tenga que volver a emitir nuevos certificados, y para que la CA renueve los certificados del cliente sin que el servidor tenga que actualizar las autorizaciones.

La asimetría aquí se debe a que, en la mayoría de las implementaciones de VPN, generalmente se espera que los servidores permanezcan en un solo lugar, mientras que los clientes generalmente son móviles.

En algunas implementaciones, si tiene una creencia razonable de que el cliente no será muy móvil, es posible que desee restringir aún más que un cierto CN solo pueda conectarse desde un determinado rango de direcciones IP. Esto puede ser parte de la política de autenticación de esa implementación y se puede hacer fuera del certificado x.509. Simplemente tiene una tabla de CN y las direcciones IP a las que se les permite a la CN conectarse en su aplicación / terminador TLS. No veo ninguna ventaja de anotar la dirección IP permitida en el propio certificado.

  

¿Hay alguna forma de implementar la autenticación del cliente en el servidor   lado basado en el IP / FQDN presentado por el cliente?

Se podría hacer.

El certificado del cliente REAL a menudo no contiene ninguna información de IP / FQDN. Para certificados personales suele ser un nombre y algún identificador, para aplicaciones suele ser un nombre de sistema / nombre de aplicación. De hecho, puede crear un certificado de cliente que contenga un nombre de host / IP.

En lo que concierne al TLS, el servidor solo valida la validez del certificado (si el servidor confía en el certificado o en cualquiera de las CA en la cadena). Es común que las aplicaciones (por encima de TLS) impongan un filtro para validar el certificado provisto que sea aceptable .

  

También pregunto porque varias soluciones de acceso remoto VPN SSL   mencionar la autenticación mutua TLS1.2, pero técnicamente tengo la   sintiendo que la forma en que el servidor y el cliente se autentican entre sí   es de alguna manera asimétrica.

Para el propio SSL, el nombre de host no es tan importante. Para el lado del servidor, el nombre de host se valida comúnmente, pero esa es la tarea del cliente para decidir si confiar o no (solo un buen ejemplo son los registros DNS de CNAME, el cliente es efectivamente redirigido, debería confiar en el nuevo nombre de host o no ?).

Su intuición es correcta, los clientes (principalmente para personas) no pueden imponer una IP estática o un nombre de host. Puede especificar eso en el certificado, pero el servidor realmente no lo comprueba (a menudo no tiene medios para hacerlo, como la dirección IP proporcionada es a menudo el proxy o VPN).