Autenticación básica sobre HTTPS fronte a IPsec: que protexe cada unha

Abra as ferramentas de desenvolvemento, cargue a aplicación interna e observe como unha solicitude atravesa catro puntos de control antes de que se represente a páxina. Primeiro resólvese o nome, despois ábrese unha conexión TCP, despois un protocolo de enlace TLS establece quen é o servidor e só entón a aplicación pregunta quen é vostede. Tráteos como acontecementos separados, porque cada un falla con probas distintas e cada un pertence a un equipo distinto. A maior parte da confusión nos incidentes vén de ler un 401 como un problema de túnel, ou un problema de túnel como un contrasinal incorrecto.

Punto de control un: é este o servidor co que quería falar

O protocolo de enlace TLS responde a esa pregunta antes de que se envíe calquera credencial. O seu cliente valida a cadea de certificados contra un almacén de confianza e comproba que o nome do certificado coincida co host que escribiu. Se iso falla, o navegador mostra un erro de certificado e nunca envía a cabeceira Authorization. Por tanto, a petición de contrasinal non é proba de que o servidor sexa auténtico; é proba de que a aplicación respondeu.

Aquí aparece a primeira fronteira. TLS protexe a conexión ata o seu punto de terminación. Se un balanceador de carga termina TLS e reenvía HTTP simple á aplicación, o segmento cifrado acaba no balanceador e as credenciais só quedan protexidas nese primeiro salto.

Punto de control dous: que viaxa realmente nun intercambio 401

A autenticación básica HTTP envía o identificador de usuario e o contrasinal nunha cabeceira, codificados con Base64 como se describe en RFC 7617. Authorization: Basic dXNlcjpwYXNz é a forma; calquera que poida ler a solicitude pode reverter a codificación, así que todo o segredo vén do transporte que hai debaixo. curl -v mostra tanto o desafío WWW-Authenticate: Basic como a cabeceira que vostede devolve.

Esa cabeceira dille á aplicación quen pregunta. Non lle di á rede quen pode conectarse e non cifra nada por si mesma. A aplicación aínda ten que comprobar a credencial contra un almacén e decidir que pode facer esa conta, o cal é autorización e ocorre despois da autenticación.

Onde se sitúa o túnel IPsec nesa ruta

Agora camiñe cara a fóra desde o navegador. Un túnel IPsec de porta a porta protexe o tráfico seleccionado entre dúas portas de seguridade, non entre o seu portátil e o proceso da aplicación. ESP en modo túnel envolve o paquete orixinal, as portas cífrao e autentícano, e os enderezos internos sobreviven para que o lado remoto poida encamiñar a solicitude á aplicación.

A selección é a parte que fai tropezar á xente. Os túneles baseados en políticas usan selectores de tráfico, a miúdo expresados como listas de control de acceso, para decidir que paquetes entran no túnel. Os túneles baseados en rutas usan en cambio unha interface virtual e a táboa de encamiñamento. En Linux, ip xfrm policy mostra os selectores e ip xfrm state as asociacións de seguridade establecidas; nun dispositivo de cortafuegos o equivalente é a táboa SA do túnel máis un rastrexador de paquetes.

A consecuencia merece dicirse con claridade. Un paquete pode estar dentro dun túnel perfectamente san e aínda así levar unha solicitude HTTPS que a aplicación rexeita, e unhas credenciais válidas poden chegar por unha ruta sen ningún túnel se o encamiñamento o permite.

Lea o fallo na capa que o informou

Un 401 significa que a aplicación non aceptou a credencial. Un 403 significa que aceptou a identidade e rexeitou a operación. Un erro TLS significa que o cliente non aceptou o servidor. Ningunha ruta ou un desaxuste de política significa que o paquete nunca chegou á porta remota. Catro fallos distintos, catro propietarios distintos, e ningún deles se diagnostica mirando fixamente o formulario de acceso.

Use as probas que produce cada capa: o panel de rede do navegador para estados e cabeceiras, openssl s_client -connect host:443 para a cadea de certificados, os contadores SA e os rexistros da porta para o tráfico do túnel, e o rexistro da aplicación para a decisión da conta. Cando dúas capas informan erros á vez, arranxe primeiro a de abaixo, porque un túnel morto pode enmascarar facilmente un fallo de autenticación e ao revés.

Mapee un servizo de extremo a extremo

Escriba cinco liñas para o servizo que está diagnosticando: que pares conecta o túnel, que subredes e portos permiten os selectores, onde termina TLS e que identidade afirma o certificado, que conta e rol de aplicación se usa, e onde rexistra cada capa. Mantéñaas nunha páxina, porque o obxectivo do mapa é mostrar onde remata a responsabilidade dunha capa e comeza a seguinte.

Despois probe un caso negativo por capa. Use un contrasinal incorrecto e confirme que obtén un 401, non un tempo de espera. Conéctese desde unha subrede fóra dos selectores e confirme que o paquete non pasa polo túnel. Presente un certificado para o nome incorrecto e confirme que o cliente rexeita antes de enviar credenciais. Eses tres resultados dinnos máis sobre o deseño que calquera diagrama de caixas.

Por último, decida deliberadamente que protección necesita cada relación. A autenticación básica sobre TLS é unha opción razoable para unha ferramenta interna pequena detrás dunha porta; non substitúe a autorización por usuario nin a protección do tráfico máis aló do punto final TLS. O túnel protexe o camiño, o certificado protexe o salto e o 401 protexe a conta, e só o último sabe quen é vostede.