Autenticació bàsica per HTTPS davant d’IPsec: què protegeix cadascuna

Obriu les eines de desenvolupador, carregueu l’aplicació interna i observeu com una sol·licitud travessa quatre punts de control abans que es renderitzi la pàgina. Primer es resol el nom, després s’obre una connexió TCP, després un intercanvi de claus TLS estableix qui és el servidor i només llavors l’aplicació pregunta qui sou. Tracteu-ho com a esdeveniments separats, perquè cadascun falla amb proves diferents i cadascun pertany a un equip diferent. La major part de la confusió en els incidents ve de llegir un 401 com un problema de túnel, o un problema de túnel com una contrasenya dolenta.

Punt de control u: és aquest el servidor amb qui volíeu parlar

L’intercanvi de claus TLS respon aquesta pregunta abans que s’enviï cap credencial. El vostre client valida la cadena de certificats contra un magatzem de confiança i comprova que el nom del certificat coincideixi amb l’amfitrió que heu escrit. Si això falla, el navegador mostra un error de certificat i no envia mai la capçalera Authorization. Per tant, la petició de contrasenya no és prova que el servidor sigui autèntic; és prova que l’aplicació ha respost.

Aquí apareix la primera frontera. TLS protegeix la connexió fins al seu punt de terminació. Si un balancejador de càrrega termina TLS i reenvia HTTP pla a l’aplicació, el segment xifrat acaba al balancejador i les credencials només queden protegides en aquell primer salt.

Punt de control dos: què viatja realment en un intercanvi 401

L’autenticació bàsica HTTP envia l’identificador d’usuari i la contrasenya en una capçalera, codificats amb Base64 tal com es descriu a RFC 7617. Authorization: Basic dXNlcjpwYXNz és la forma; qualsevol que pugui llegir la sol·licitud pot revertir la codificació, així que tota la secretesa ve del transport de sota. curl -v mostra tant el repte WWW-Authenticate: Basic com la capçalera que envieu de tornada.

Aquesta capçalera diu a l’aplicació qui pregunta. No diu a la xarxa qui es pot connectar i no xifra res per si mateixa. L’aplicació encara ha de comprovar la credencial contra un magatzem i decidir què pot fer aquell compte, cosa que és autorització i passa després de l’autenticació.

On se situa el túnel IPsec en aquest camí

Ara camineu cap enfora des del navegador. Un túnel IPsec de porta a porta protegeix el tràfic seleccionat entre dues portes de seguretat, no entre el vostre portàtil i el procés de l’aplicació. L’ESP en mode túnel embolcalla el paquet original, les portes el xifren i l’autentiquen, i les adreces internes sobreviuen perquè el costat llunyà pugui encaminar la sol·licitud a l’aplicació.

La selecció és la part que fa ensopegar la gent. Els túnels basats en polítiques utilitzen selectors de tràfic, sovint expressats com a llistes de control d’accés, per decidir quins paquets entren al túnel. Els túnels basats en rutes utilitzen en canvi una interfície virtual i la taula d’encaminament. A Linux, ip xfrm policy mostra els selectors i ip xfrm state les associacions de seguretat establertes; en un dispositiu de tallafoc l’equivalent és la taula SA del túnel més un rastrejador de paquets.

La conseqüència val la pena dir-la clarament. Un paquet pot seure dins d’un túnel perfectament sa i tot i així portar una sol·licitud HTTPS que l’aplicació rebutja, i unes credencials vàlides poden arribar per un camí sense cap túnel si l’encaminament ho permet.

Llegiu la fallada a la capa que l’ha reportat

Un 401 vol dir que l’aplicació no ha acceptat la credencial. Un 403 vol dir que ha acceptat la identitat i ha refusat l’operació. Un error TLS vol dir que el client no ha acceptat el servidor. Cap ruta o un desajust de política vol dir que el paquet no ha arribat mai a la porta llunyana. Quatre fallades diferents, quatre propietaris diferents, i cap d’elles no es diagnostica mirant fixament el formulari d’accés.

Utilitzeu les proves que produeix cada capa: el panell de xarxa del navegador per a l’estat i les capçaleres, openssl s_client -connect host:443 per a la cadena de certificats, els comptadors SA i els registres de la porta per al tràfic del túnel, i el registre de l’aplicació per a la decisió del compte. Quan dues capes reporten errors alhora, arregleu primer la de sota, perquè un túnel mort pot emmascarar fàcilment una fallada d’autenticació i a l’inrevés.

Mapa d’un servei d’extrem a extrem

Escriviu cinc línies per al servei que esteu diagnosticant: quins parells connecta el túnel, quines subxarxes i ports permeten els selectors, on termina TLS i quina identitat afirma el certificat, quin compte i rol d’aplicació s’utilitza, i on registra cada capa. Manteniu-les en una pàgina, perquè el punt del mapa és mostrar on acaba la responsabilitat d’una capa i comença la següent.

Després proveu un cas negatiu per capa. Feu servir una contrasenya incorrecta i confirmeu que obteniu un 401, no un temps d’espera. Connecteu-vos des d’una subxarxa fora dels selectors i confirmeu que el paquet no passa pel túnel. Presenteu un certificat per a un nom incorrecte i confirmeu que el client refusa abans d’enviar credencials. Aquests tres resultats us diuen sobre el disseny més que qualsevol diagrama de caixes.

Finalment, decidiu deliberadament quina protecció necessita cada relació. L’autenticació bàsica sobre TLS és una opció raonable per a una eina interna petita darrere d’una porta; no substitueix l’autorització per usuari ni la protecció del tràfic més enllà del punt final TLS. El túnel protegeix el camí, el certificat protegeix el salt i el 401 protegeix el compte, i només l’últim sap qui sou.