Server Name Indication

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

Server Name Indication (SNI, en español: Indicación de nombre de servidor) es una extensión del protocolo TLS.[1] Este indica qué nombre de host el cliente esta intentando conectar antes de que el proceso de handshaking se complete. Esta funcionalidad permite a un servidor utilizar múltiples certificados en una misma dirección IP y número de puerto y permitir múltiples sitios seguros (HTTPS) o cualquier otro servicio sobre TLS pueda ser servido en una misma IP sin que todos los sitios compartan un certificado común. Esto es equivalente a al concepto de VirtualHost HTTPS sobre el protocolo HTTP/1.1.

Para hacer uso de SNI prácticamente, es necesario que una gran proporción de los usuarios usen un Navegador Web que soporte dicha característica. Los usuarios cuyos navegadores no soportan SNI serán presentados con un certificado predeterminado y por lo tanto son propensos a recibir advertencias de certificado, a menos que el servidor está equipado con un certificado comodín que coincide con el nombre de la página web. A partir de noviembre de 2012, los únicos grandes bases de usuarios cuyos navegadores no soportan SNI son de Android 2.x (navegador predeterminado), Internet Explorer en Windows XP y versiones de Java antes de 1.7 en cualquier sistema operativo.

Antecedentes del problema[editar]

Al establecer una conexión TLS el cliente solicita un certificado digital en el servidor web , una vez que el servidor envía el certificado , el cliente examina y compara el nombre que estaba tratando de conectar con el nombre(s) incluida en el certificado . Si se encuentra una coincidencia la conexión procede de forma normal . Si no se encuentra una coincidencia , el usuario puede ser advertido de la discrepancia y la conexión puede ser abortada como la falta de correspondencia puede indicar un intento de ataque man-in-the-middle . Sin embargo , algunas aplicaciones permiten al usuario pasar por alto la advertencia de proceder a la conexión, con el usuario asumiendo la responsabilidad de confiar en el certificado y , por extensión, de la conexión.

Es posible que un certificado para cubrir múltiples nombres de host. La especificación X.509 v3 introduce el campo subjectAltName que permite un certificado para especificar más de un dominio y el uso de comodines en tanto el nombre común y campos subjectAltName. Sin embargo, puede ser poco práctico o incluso imposible , debido a la falta de una lista completa de todos los nombres de antemano. Como el servidor de tal manera que es responsable de múltiples nombres de host es probable que tenga que presentar un certificado diferente para cada nombre (o un pequeño grupo de nombres). Desde 2005, se ha quedado CAcert experimentos sobre diferentes métodos de uso de TLS en los servidores virtuales. La mayoría de los experimentos son insatisfactorios y poco práctico. Por ejemplo, es posible utilizar subjectAltName para contener múltiples dominios controlados por una sola persona en un único certificado. LLamados "certificados de comunicaciones unificadas " sin embargo los mismos se deben volver a emitir cada vez que la lista de dominios de cambie.

Hosting virtual basado en nombre permite que varios nombres de host DNS que se celebrará en un solo servidor (generalmente un servidor web) en la misma dirección IP . Para lograr esto, el servidor utiliza un nombre de host presentado por el cliente como parte del protocolo (HTTP para el nombre se presenta en el encabezado de host) . Sin embargo cuando se utiliza HTTPS el clientHello TLS ocurre antes de que el servidor ve cualquiera de las cabeceras HTTP. Por lo tanto no es posible que el servidor utilice la información en el encabezado de host HTTP para decidir cuál es el certificado para presentar y , como tal, sólo los nombres incluidos en el mismo certificado se puede servir desde la misma dirección IP.

En la práctica, esto significa que un servidor HTTPS sólo puede servir a un dominio (o un pequeño grupo de dominios) por cada dirección IP para la navegación segura. Asignación de una dirección IP diferente para cada sitio aumenta el coste de la acogida ya las peticiones de direcciones IP deben estar justificadas en el registro regional de Internet y las direcciones IPv4 son ahora escasos. El resultado es que muchos sitios web se previenen con eficacia el uso de comunicaciones seguras. [2]

Referencias[editar]