Auditoría de configuración HTTPS

Pegue las cabeceras de respuesta de un sitio — y, si las tiene, su certificado, un fragmento del código fuente de su página y el nombre de host — y esta página informa de cómo está configurada la parte HTTPS: si HSTS está establecido y durante cuánto tiempo, si una política de contenido actualiza las peticiones inseguras, si las cookies están marcadas como Secure y SameSite, si un banner del servidor revela una versión, y qué dicen las cabeceras de proxy sobre la petición que vio realmente la aplicación. El certificado se audita en el mismo informe, los subrecursos http:// en claro se cuentan a partir del código fuente de la página, y se enumeran los comandos que pueden ver el handshake para que los ejecute usted mismo. Todo se ejecuta en su navegador y la página no hace ninguna petición por su cuenta.
1. Cabeceras de respuesta
El bloque completo de cabeceras de respuesta, incluida la línea de estado. La fuente más sencilla: curl -sI https://example.com/ en una terminal, o el panel de cabeceras de la pestaña Red de las herramientas de desarrollo del navegador, copiado desde el principio. Las cabeceras adicionales se leen y se ignoran; solo se informa de las relevantes para HTTPS.
2. Certificado o cadena (opcional)
Si lo rellena, el mismo informe incluye también la auditoría completa del certificado, de modo que la configuración y el certificado se leen juntos. Funcionan PEM, un cuerpo base64 o hexadecimal sin envoltorio y un .p7b PKCS#7; el comprobador de certificados analiza el certificado por separado con más profundidad.
3. Fragmento del código fuente de la página (opcional)
Pegue el código fuente de la página (o solo las etiquetas con URL) y se enumera cada dirección http:// en claro, porque un subrecurso cargado por HTTP rompe el candado y puede reescribirse en tránsito incluso cuando la página en sí llegó por HTTPS. Las direcciones al propio host del sitio se destacan por separado, ya que son las que corregiría una URL relativa.
4. Nombre de host (opcional)
Con un nombre de host aquí, la auditoría comprueba los nombres alternativos del sujeto de la misma forma que un navegador, incluidas las reglas de comodín, y compara con él las direcciones http:// en claro.
todavía no se ha auditado nada
El ejemplo es deliberadamente imperfecto, para que cada parte del informe tenga contenido: un bloque de cabeceras con HSTS y una política de contenido (pero sin preload y con una cookie sin SameSite), una cadena de dos certificados, y un fragmento de página que carga un script por http:// en claro y apunta una imagen al propio host del sitio de la misma forma. Espere una F en el ejemplo y lea los hallazgos de abajo para ver lo que significa cada uno.
Qué se comprueba. Del bloque de cabeceras: HSTS, su max-age, includeSubDomains y preload; una política de contenido que actualiza las peticiones inseguras; los indicadores Secure, HttpOnly y SameSite de cada Set-Cookie; un banner del servidor que nombra un producto y una versión; y las cabeceras reenviadas que indican si la aplicación vio la petición como HTTPS. Del bloque de certificado: la auditoría completa del certificado, hasta comprobar si cada enlace de la cadena firmó realmente al siguiente. Del código fuente de la página: los subrecursos http:// en claro. Los tres se informan por separado y después se resumen juntos, porque un candado roto suele deberse a uno de esos tres y no a los otros dos. Para la lista completa de cabeceras de respuesta de seguridad de OWASP — X-Content-Type-Options, protección contra el enmarcado, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP y la puntuación calificada — pegue el mismo bloque de cabeceras en la página de Comprobación de cabeceras de seguridad; las dos páginas reparten el trabajo entre la capa TLS y la capa de cabeceras.

Lo que no puede ver. Esta página nunca abre una conexión TLS. Los navegadores no exponen el handshake a una página, así que la versión del protocolo, el conjunto de cifrado, el grupo de intercambio de claves, el grapado de OCSP, la reanudación de sesión, el 0-RTT, la cadena de certificados que envía realmente un servidor en marcha, y si la redirección de HTTP a HTTPS ocurre en el origen o en un proxy quedan fuera de lo que puede informar cualquier página web. Tampoco puede acceder a un sitio de terceros para recoger las cabeceras por usted, y no puede decirle si un certificado es de confianza, porque eso depende de un almacén de raíces que una página no puede leer. Los comandos que aparecen más abajo en esta página sí ven esas cosas, y están pensados para que los ejecute usted, en su propio equipo.

Dónde obtener el bloque de cabeceras. En una terminal, curl -sI https://example.com/ imprime exactamente lo que quiere esta página. En un navegador, abra las herramientas de desarrollo, vaya a la pestaña Red, recargue la página, seleccione la petición del documento y copie toda la zona de cabeceras de respuesta, o use Copiar → Copiar cabeceras de respuesta. Para la comprobación de redirección, ejecute también curl -sI http://example.com/ y pegue ambos bloques: la página los informa uno tras otro.
Informe de auditoría
Todavía no se ha auditado nada. Pegue un bloque de cabeceras arriba y pulse Auditar esta configuración para el informe completo; un certificado, un fragmento del código fuente de la página y un nombre de host son opcionales y cada uno añade su propia sección.
Sonda de accesibilidad — la única parte de esta página que usa la red
Una página no puede abrir una conexión TLS, pero sí puede intentar una petición corriente. Si el sitio permite lecturas de origen cruzado, la URL en la que termina la respuesta muestra si http:// se redirigió a https://, y eso es todo lo que puede demostrar esto. Si la petición falla, esta página no puede decirle si el host está caído, si su propia conexión está caída o si el sitio simplemente no permite lecturas de origen cruzado — esto último es lo habitual, porque la mayoría de los sitios no envían Access-Control-Allow-Origin. Una URL http:// se responde antes de cualquier redirección, así que esta es la única cosa de aquí que un navegador intentará sobre una conexión en claro. Nada sale del navegador hasta que pulse el botón.
Comandos que sí ven el handshake
curl -sI https://example.com/ # the header block this page reads curl -sI http://example.com/ # is plain HTTP answered, or redirected? curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName nmap --script ssl-enum-ciphers -p 443 example.com testssl.sh example.com # or: docker run --rm -ti drwetter/testssl.sh example.com
Están pensados para que los ejecute usted, en un equipo que controle, contra un host que tiene permiso para probar. La salida de -showcerts puede pegarse directamente en el comprobador de certificados, y la salida de las cabeceras de vuelta en esta página.
El certificado es un documento público. Todo certificado de confianza pública se publica en los registros de Certificate Transparency, así que cualquier nombre de host que contenga — incluido un nombre interno o mal escrito que una autoridad de certificación pública haya firmado — puede encontrarse buscando en esos registros. Un certificado también lleva las direcciones de revocación que eligió su emisor, y a veces nombran un host interno. Por eso el certificado que sirve una CDN no dice nada sobre el servidor de origen: los nombres que contiene pertenecen a la CDN. Si la auditoría revela un nombre de host que no esperaba, trátelo como público y sustituya lo que protege.

Privacidad: el bloque de cabeceras, el certificado y el código fuente de la página se leen localmente y nunca se suben, y no se hace ninguna petición de ningún tipo salvo que pulse el botón de la sonda de accesibilidad. Para crear un certificado propio use el generador de certificados autofirmados; para comprobar que una clave privada pertenece a un certificado use el comparador de certificado y clave.