Como facer HTTPS a primeira solicitude a través dunha VPN

Un navegador que escribe http:// primeiro e chega a https:// despois de que unha redirección xa enviou unha solicitude en claro, e unha VPN non o cambia. O túnel protexe a perna desde o cliente ata o nodo de saída; non cifra nada por riba da capa de transporte, polo que un observador entre a saída e a orixe aínda ve o salto de texto plano. Facer HTTPS a primeira solicitude é un cambio no lado do cliente con tres partes: un enderezo HTTPS real, o modo de actualización do navegador e a propia política do sitio. Os pasos que se indican a continuación son a orde que utilizo, cada un coa verificación que che indica se foi necesario.

Paso 1: confirma cal é a primeira solicitude

Antes de cambiar calquera cousa, mira o que envía o navegador. Abre o panel de rede coa páxina recargada desde unha caché fría e le a primeira fila: se o esquema é http e o estado é 301 ou 308, todo despois desa fila é unha segunda solicitude. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com reproduce a mesma secuencia fóra do navegador e imprime o URL no que acabou.

Son posibles dous resultados e necesitan correccións diferentes. Se o sitio ofrece HTTPS no mesmo servidor, a solución consiste en deixar de publicar o formulario HTTP: actualiza o marcador, a ligazón wiki, o atallo do escritorio e o modelo de correo electrónico que fai clic a xente. Se o sitio non serve HTTPS en absoluto, ningunha configuración do navegador o creará, e a resposta honesta é que o destino é o problema. Non papele o segundo caso cunha excepción, porque unha excepción de certificado nunha páxina de conta converte un problema de transporte nun problema de credenciais. Anota en que caso te atopas antes de tocar unha configuración.

Paso 2: activa o modo só HTTPS do navegador

O modo de actualización é a segunda parte e os modos non son intercambiables. Comproba o que fai o teu antes de activalo: actualiza silenciosamente, actualiza cunha advertencia ou rexeita a carga.

En Firefox, os controis están detrás de about:config e na páxina de configuración de privacidade, con dom.security.https_only_mode como interruptor e as excepcións por sitio xestionadas desde o menú de cadeado. En Chrome e Edge, a mesma idea sitúase en Configuración, Privacidade e seguridade, Seguridade, etiquetadas como Usar sempre conexións seguras. Sexa cal sexa a etiqueta, verifique o comportamento fronte a un host que só responde no porto 80, porque un modo que se actualiza e despois cae silenciosamente non é a protección que pensas que habilitou. A documentación de Firefox só HTTPS detalla o comportamento de actualización, aviso e excepción para ese navegador.

Paso 3: corrixe os recursos, non só a barra de enderezos

Cando falla unha actualización, le o erro exacto en lugar da barra de enderezos. Un servidor sen escoita HTTPS, un nome de host que non coincide co certificado e unha cadea caducada producen mensaxes diferentes e pertencen a propietarios diferentes. Só o primeiro é un oco no servidor; o segundo adoita ser un marcador que nunca se actualizou; o terceiro é un problema de renovación para o que a conexión VPN é irrelevante.

Non engadas unha excepción de certificado a un sitio de conta porque a VPN está activada. A excepción desactiva a comprobación que detectaría exactamente a interceptación que unha VPN pretende evitar.

A terceira parte está dentro da páxina, e é a que a xente bota de menos. Unha páxina que se carga a través de HTTPS aínda pode extraer imaxes, fontes ou scripts dun URL http e o navegador bloqueará o indicador de seguridade de toda a páxina. Inspecciona as solicitudes erradas no panel de rede e corrixe as referencias de recursos no seu propietario en lugar de asumir que a barra de enderezos describe todas as solicitudes. Nun sitio que executas, iso significa corrixir os URL almacenados no CMS ou no modelo en lugar de reescribilos no navegador. Se non podes cambiar a fonte, rexistra o contido mixto como un espazo coñecido, porque un cadeado sobre unha páxina que extrae recursos de texto sinxelo é un sinal falso.

Paso 4: o que engade HSTS e o que non

HSTS é unha política do sitio máis que unha preferencia do navegador, e é o único mecanismo aquí que sobrevive a un http:// escrito nun perfil novo. Unha vez que un navegador viu unha cabeceira Strict-Transport-Security para un host, reescribe as solicitudes posteriores en https antes de envialas, que é exactamente a propiedade que desexa. Non fai nada para un host que nunca visitou o navegador, nin para un nome de host diferente que serve á mesma aplicación.

Comproba o que envía a orixe con curl -sSI https://example.com | grep -i strict-transport-security. Unha cabeceira que falta é un cambio de servidor e non é algo que un cliente poida instalar. Se está presente, le max-age e se se estableceu includeSubDomains, porque unha idade máxima curta caduca entre as visitas e un subdominio incluído que falta deixa cada subdominio desprotexido. O RFC 6797 define como un axente de usuario aplica a política e o que pode ignorar. A carga previa é un compromiso aparte, polo que comprobe o estado a través da API de hstspreload.org antes de prometer a ninguén que hai un dominio na lista.

Verificación e reversión

A recuperación é barata para a configuración do cliente e cara para HSTS. Ao desactivar o modo só HTTPS restablece o comportamento anterior inmediatamente; unha idade máxima longa non o fai, e os visitantes que xa o recibiron seguen actualizando ata que caduca.

Así que verifique a orde antes de chamalo. Recarga desde unha caché fría e confirma que a primeira solicitude no panel de rede é https sen redirección previa. A continuación, comprobe un subdominio, porque includeSubDomains é onde estas políticas adoitan resultar máis estreitas do que se supón. A continuación, comprobe unha páxina que extrae recursos de terceiros, xa que o contido mixto é o fallo que sobrevive a todas as outras solucións.

Se a primeira solicitude segue sendo http despois de todo isto, o cliente xa non é a variable: é a ligazón na que fan clic as persoas. Busca nos lugares que controlas a forma http do nome de host, actualízaos e volve probar coa mesma recarga de caché en frío. Mantén a pregunta VPN separada en todo momento, porque o túnel cambia quen pode ver a solicitude e nunca cambia se a solicitude está cifrada. A liña a poñer no ticket é que a primeira solicitude é a que importa, e unha redirección é só un recibo dunha solicitude xa enviada.