Com fer que HTTPS sigui la primera sol·licitud mitjançant una VPN

Un navegador que escrigui http:// primer i arriba a https:// després que una redirecció ja hagi enviat una sol·licitud en clar, i una VPN no ho canvia. El túnel protegeix la cama des del client fins al node de sortida; no xifra res per sobre de la capa de transport, de manera que un observador entre la sortida i l'origen encara veu el salt de text pla. Fer que HTTPS sigui la primera sol·licitud és un canvi del costat del client amb tres parts: una adreça HTTPS real, el mode d'actualització del navegador i la pròpia política del lloc. Els passos següents són l'ordre que faig servir, cadascun amb el xec que us indica si ho va fer.

Pas 1: confirmeu quina és realment la primera sol·licitud

Abans de canviar res, mireu què envia el navegador. Obriu el tauler de xarxa amb la pàgina tornada a carregar des d'una memòria cau en fred i llegiu la primera fila: si l'esquema és http i l'estat és 301 o 308, tot després d'aquesta fila és una segona sol·licitud. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com reprodueix la mateixa seqüència fora del navegador i imprimeix l'URL on has acabat.

Són possibles dos resultats i necessiten solucions diferents. Si el lloc serveix HTTPS al mateix amfitrió, la solució és deixar de publicar el formulari HTTP: actualitzeu l'adreça d'interès, l'enllaç wiki, la drecera de l'escriptori i la plantilla de correu electrònic que la gent fa clic. Si el lloc no serveix HTTPS en absolut, cap configuració del navegador el crearà i la resposta honesta és que la destinació és el problema. No papereu el segon cas amb una excepció, perquè una excepció de certificat en una pàgina de compte converteix un problema de transport en un problema de credencials. Anoteu en quin cas us trobeu abans de tocar una configuració.

Pas 2: activeu el mode només HTTPS del navegador

El mode d'actualització és la segona part i els modes no són intercanviables. Comproveu què fa el vostre abans d'activar-lo: actualitzeu-lo en silenci, actualitzeu-lo amb un avís o negueu a carregar-lo.

Al Firefox, els controls es troben darrere de about:config i a la pàgina de configuració de privadesa, amb dom.security.https_only_mode com a commutador i les excepcions per lloc gestionades des del menú del cadenat. A Chrome i Edge, la mateixa idea es troba a Configuració, Privadesa i seguretat, Seguretat, amb l'etiqueta Utilitza sempre connexions segures. Sigui quina sigui l'etiqueta, verifiqueu el comportament amb un amfitrió que només respon al port 80, perquè un mode que s'actualitza i després es redueix en silenci no és la protecció que creieu que heu activat. La documentació de Firefox només HTTPS detalla el comportament d'actualització, advertència i excepció d'aquest navegador.

Pas 3: arregleu els recursos, no només la barra d'adreces

Quan falla una actualització, llegiu l'error exacte en lloc de la barra d'adreces. Un host sense oient HTTPS, un nom d'amfitrió que no coincideix amb el certificat i una cadena caducada produeixen missatges diferents i pertanyen a propietaris diferents. Només el primer és un buit del costat del servidor; el segon sol ser un marcador que mai s'ha actualitzat; el tercer és un problema de renovació per al qual la connexió VPN és irrellevant.

No afegiu una excepció de certificat a un lloc de compte perquè la VPN està activada. L'excepció desactiva la comprovació que hauria detectat exactament la intercepció que pretén evitar una VPN.

La tercera part es troba dins de la pàgina, i és la que la gent troba a faltar. Una pàgina que es carregui mitjançant HTTPS encara pot extreure imatges, tipus de lletra o scripts d'una URL http, i el navegador les bloquejarà o bé baixarà l'indicador de seguretat de tota la pàgina. Inspeccioneu les sol·licituds fallides al tauler de xarxa i fixeu les referències de recursos al seu propietari en lloc de suposar que la barra d'adreces descriu cada sol·licitud. En un lloc que executeu, això significa corregir els URL emmagatzemats al CMS o a la plantilla en lloc de reescriure-los al navegador. Si no podeu canviar la font, registreu el contingut mixt com a buit conegut, perquè un cadenat sobre una pàgina que extreu recursos de text sense format és un senyal fals.

Pas 4: què afegeix HSTS i què no

HSTS és una política de lloc en lloc d'una preferència del navegador, i és l'únic mecanisme aquí que sobreviu a un http:// escrit en un perfil nou. Una vegada que un navegador ha vist una capçalera Strict-Transport-Security per a un amfitrió, reescriu les sol·licituds posteriors a https abans d'enviar-les, que és exactament la propietat que voleu. No fa res per a un amfitrió que el navegador no ha visitat mai, ni per a un altre nom d'amfitrió que serveixi a la mateixa aplicació.

Comproveu què envia l'origen amb curl -sSI https://example.com | grep -i strict-transport-security. Una capçalera que falta és un canvi de servidor i no una cosa que un client pugui instal·lar. Si està present, llegiu max-age i si includeSubDomains està establert, perquè una edat màxima curta caduca entre visites i un includeSubDomains que falten deixa tots els subdominis sense protecció. RFC 6797 defineix com un agent d'usuari aplica la política i què pot ignorar. La càrrega prèvia és un compromís independent, així que comproveu l'estat a través de l'API hstspreload.org abans de prometre a ningú que hi ha un domini a la llista.

Verificació i retrocés

La recuperació és barata per a la configuració del client i cara per a HSTS. Desactivar el mode només HTTPS restaura el comportament anterior immediatament; una edat màxima llarga no, i els visitants que ja l'han rebut continuen actualitzant-se fins que caduca.

Així que comprova l'ordre abans de trucar-ho. Torneu a carregar des d'una memòria cau freda i confirmeu que la primera sol·licitud al tauler de xarxa és https sense cap redirecció anterior. A continuació, comproveu un subdomini, perquè includeSubDomains és on aquestes polítiques solen resultar més estretes del que s'assumeix. A continuació, comproveu una pàgina que extreu recursos de tercers, ja que el contingut mixt és l'error que sobreviu a totes les altres solucions.

Si la primera sol·licitud encara és http després de tot això, el client ja no és la variable: és l'enllaç que fan clic les persones. Cerqueu als llocs que controleu la forma http del nom d'amfitrió, actualitzeu-los i torneu a provar amb la mateixa recàrrega de memòria cau en fred. Manteniu la pregunta VPN separada durant tot el procés, perquè el túnel canvia qui pot veure la sol·licitud i mai no canvia si la sol·licitud està xifrada. La línia a posar al tiquet és que la primera sol·licitud és la que importa, i una redirecció només és un rebut d'una sol·licitud ja enviada.