La extraña cabecera "Upgrade-Insecure-Requests" y cómo gestionarla en el servidor

Como todo programador web que se precie, más temprano que tarde acabarás por utilizar el inspector de tráfico de Google Chrome o cualquier otro analizador de protocolos como por ejemplo el magnífico Fiddler. Estas utilidades sirven para inspeccionar todo el tráfico web saliente y poder ver exactamente qué datos se intercambian, poder modificar peticiones y respuestas, etc… lo cual es de gran ayuda para depurar las aplicaciones Web.

Si inspeccionas tráfico generado por Google Chrome verás una cabecera muy rara en casi todas las peticiones dirigidas a través de HTTP:

Upgrade-Insecure-Requests

¿Qué es esta cabecera "Upgrade-Insecure-Requests"?

SIGUE LEYENDO…

Cómo cambiar el orden de los algoritmos criptográficos de SSL en Windows Server / IIS

Hace poco veíamos cómo solicitar un certificado digital para SSL usando un algoritmo de hash moderno, y no el que se usa por defecto en IIS.

En esta ocasión vamos a ver cómo podemos modificar en Windows Server, y por lo tanto en Internet Information Server, el orden de preferencia de los diferentes conjuntos de algoritmos de cifrado disponibles. De este modo nos cerciorarnos de que los más modernos y seguros van primero en la lista y por lo tanto se les da preferencia a la hora de cifrar las comunicaciones, obteniendo un servidor más seguro.

La cosa es bastante sencilla. Sólo hay que saber en dónde tocar y entender lo que se toca.

SIGUE LEYENDO para averiguar:

  • Cómo configuramos el orden de precedencia de los conjuntos de algoritmos criptográficos
  • Cuáles deberíamos priorizar en un servidor habitualmente
  • Cuál es el caso ideal y cómo podríamos ponerlo en marcha
  • Cuáles son las pegas de ese caso "ideal"

Cómo solicitar certificados con SHA-2 en lugar de SHA-1 en IIS y Windows Server 2008

Dentro de las tareas criptográficas necesarias para realizar comunicaciones seguras están los algoritmos de resumen digital o hashing. Uno de los más utilizados desde hace varios lustros es el algoritmo SHA-1.

El problema es que este algoritmo ha sido ya vapuleado por algunos expertos en seguridad a partir de 2004, y hoy en día se considera inseguro, por lo que la mayor parte de fabricantes de navegadores y otros sistemas han anunciado que irán dejando de soportarlo paulatinamente:

Lo que hay que hacer es utilizar SHA-2 en cualquiera de sus 6 variantes, y más en concreto se suele utilizar SHA-256.

El consenso general es que a partir del día 1 de Enero de 2017 los navegadores que se encuentran con una conexión segura SSL basada en el algoritmo SHA-1 pasarán a considerarla insegura y mostrarán un aviso de seguridad.

Es más, hoy en día esto ya está ocurriendo puesto que Chrome, si despliegas la información del sitio pulsando en el candado, te advierte de que el sitio está usando un conjunto de cifrado obsoleto:

Certificado-SSL-Hacienda-Obsoleto

En el caso de nuestra querida agencia tributaria encima es que ni siquiera proporciona información sobre transparencia de certificados, por lo que además el icono del candado muestra ya una advertencia en la barra de direcciones. La Administración siempre por delante, ya se sabe…

Bien, el caso es que dentro de poco si tu certificado SSL no está correctamente generado para poder utilizar algoritmos de cifrado y hashing modernos, vas a tener un problema.

Esto implica fundamentalmente dos cosas:

  1. Permitir únicamente el uso de protocolos seguros en el servidor: básicamente deshabilitar SSL 2.0 y SSL 3.0 y recurrir a TLS, mejor a una de sus versiones más recientes (la 1.1 o la 1.2). Fíjate que en el caso de Hacienda, sí que usan TLS 1.2, pero como utilizan SHA1, Chrome advierte igualmente de que es un conjunto de cifrado obsoleto. En Enero de 2017 simplemente lo marcará como inseguro.
  2. Solicitar un certificado SSL indicando que queremos utilizar alguna variante de SHA-2. Esto es precisamente lo que vamos a ver en este post.

Si utilizas Internet Information Server en algún sistema que no sea con Windows Server 2012 (que lleva IIS 8.x), no podrás solicitar el certificado de la manera habitual. De hecho, si generas un certificado desde la opción correspondiente del IIS Manager, cuando vayas a comprarlo lo más probable es que el proveedor te avise y te diga que debes hacer la solicitud con SHA-2. Por ejemplo, si copias y pegas tu solicitud en esta página de Symantec, te dirá qué tipo de solicitud estás haciendo (pulsa para aumentar):

SSL-SHA-Cert-SHA1

En este caso, como vemos, se está solicitando con SHA-1, que es lo que utiliza por defecto Internet Information Server 7.x. Conviene usar esta herramienta gratuita para verificar nuestra solicitud antes de comprar el certificado.

Entonces, si IIS genera una petición de certificado con SHA-1 ¿cómo podemos obtener una solicitud apropiada con SHA-2?.

Para ello debes utilizar la consola de gestión del sistema directamente, y hacer caso omiso de la administración de Internet Information Server.

SIGUE LEYENDO para ver una explicación detallada paso a paso de cómo conseguirlo.