Autenticación básica sobre HTTPS frente a IPsec: qué protege cada una

Abra las herramientas de desarrollo, cargue la aplicación interna y observe cómo una solicitud atraviesa cuatro puntos de control antes de que se represente la página. Primero se resuelve el nombre, luego se abre una conexión TCP, después un protocolo de enlace TLS establece quién es el servidor y solo entonces la aplicación pregunta quién es usted. Trátelos como eventos separados, porque cada uno falla con pruebas distintas y cada uno pertenece a un equipo distinto. La mayor parte de la confusión en los incidentes viene de leer un 401 como un problema de túnel, o un problema de túnel como una contraseña incorrecta.

Punto de control uno: ¿es este el servidor con el que quería hablar

El protocolo de enlace TLS responde a esa pregunta antes de que se envíe cualquier credencial. Su cliente valida la cadena de certificados contra un almacén de confianza y comprueba que el nombre del certificado coincida con el host que escribió. Si eso falla, el navegador muestra un error de certificado y nunca envía la cabecera Authorization. Por tanto, la petición de contraseña no es prueba de que el servidor sea auténtico; es prueba de que la aplicación respondió.

Aquí aparece la primera frontera. TLS protege la conexión hasta su punto de terminación. Si un balanceador de carga termina TLS y reenvía HTTP simple a la aplicación, el segmento cifrado acaba en el balanceador y las credenciales solo quedan protegidas en ese primer salto.

Punto de control dos: qué viaja realmente en un intercambio 401

La autenticación básica HTTP envía el identificador de usuario y la contraseña en una cabecera, codificados con Base64 como se describe en RFC 7617. Authorization: Basic dXNlcjpwYXNz es la forma; cualquiera que pueda leer la solicitud puede revertir la codificación, así que todo el secreto viene del transporte que hay debajo. curl -v muestra tanto el desafío WWW-Authenticate: Basic como la cabecera que usted devuelve.

Esa cabecera le dice a la aplicación quién pregunta. No le dice a la red quién puede conectarse y no cifra nada por sí misma. La aplicación todavía tiene que comprobar la credencial contra un almacén y decidir qué puede hacer esa cuenta, lo cual es autorización y ocurre después de la autenticación.

Dónde se sitúa el túnel IPsec en esa ruta

Ahora camine hacia fuera desde el navegador. Un túnel IPsec de puerta a puerta protege el tráfico seleccionado entre dos puertas de seguridad, no entre su portátil y el proceso de la aplicación. ESP en modo túnel envuelve el paquete original, las puertas lo cifran y lo autentican, y las direcciones internas sobreviven para que el lado remoto pueda encaminar la solicitud a la aplicación.

La selección es la parte que hace tropezar a la gente. Los túneles basados en políticas usan selectores de tráfico, a menudo expresados como listas de control de acceso, para decidir qué paquetes entran en el túnel. Los túneles basados en rutas usan en cambio una interfaz virtual y la tabla de enrutamiento. En Linux, ip xfrm policy muestra los selectores y ip xfrm state las asociaciones de seguridad establecidas; en un dispositivo de cortafuegos el equivalente es la tabla SA del túnel más un rastreador de paquetes.

La consecuencia merece decirse con claridad. Un paquete puede estar dentro de un túnel perfectamente sano y aun así llevar una solicitud HTTPS que la aplicación rechaza, y unas credenciales válidas pueden llegar por una ruta sin túnel alguno si el enrutamiento lo permite.

Lea el fallo en la capa que lo informó

Un 401 significa que la aplicación no aceptó la credencial. Un 403 significa que aceptó la identidad y rechazó la operación. Un error TLS significa que el cliente no aceptó el servidor. Ninguna ruta o un desajuste de política significa que el paquete nunca llegó a la puerta remota. Cuatro fallos distintos, cuatro propietarios distintos, y ninguno de ellos se diagnostica mirando fijamente el formulario de acceso.

Use las pruebas que produce cada capa: el panel de red del navegador para estados y cabeceras, openssl s_client -connect host:443 para la cadena de certificados, los contadores SA y los registros de la puerta para el tráfico del túnel, y el registro de la aplicación para la decisión de la cuenta. Cuando dos capas informan errores a la vez, arregle primero la de abajo, porque un túnel muerto puede enmascarar fácilmente un fallo de autenticación y al revés.

Mapee un servicio de extremo a extremo

Escriba cinco líneas para el servicio que está diagnosticando: qué pares conecta el túnel, qué subredes y puertos permiten los selectores, dónde termina TLS y qué identidad afirma el certificado, qué cuenta y rol de aplicación se usa, y dónde registra cada capa. Manténgalas en una página, porque el objetivo del mapa es mostrar dónde termina la responsabilidad de una capa y empieza la siguiente.

Luego pruebe un caso negativo por capa. Use una contraseña incorrecta y confirme que obtiene un 401, no un tiempo de espera. Conéctese desde una subred fuera de los selectores y confirme que el paquete no pasa por el túnel. Presente un certificado para el nombre equivocado y confirme que el cliente rechaza antes de enviar credenciales. Esos tres resultados le dicen más sobre el diseño que cualquier diagrama de cajas.

Por último, decida deliberadamente qué protección necesita cada relación. La autenticación básica sobre TLS es una opción razonable para una herramienta interna pequeña detrás de una puerta; no sustituye la autorización por usuario ni la protección del tráfico más allá del punto final TLS. El túnel protege el camino, el certificado protege el salto y el 401 protege la cuenta, y solo el último sabe quién es usted.