Si HTTPS es más seguro, ¿por qué no se utiliza en toda la Web?

Por Scott Gilbertson, wired.com

Usted no escribiría su nombre de usuario y contraseñas en una postal y la enviaría por correo regular para que el mundo las vea, ¿por qué entonces lo está haciendo en línea? Cada vez que se conecta a Twitter, Facebook o cualquier otro servicio que utiliza una conexión HTTP normal, eso es básicamente lo que está haciendo.

Hay una manera mejor, la versión segura de HTTP: HTTPS. Esa "S” extra en el URL (siglas en inglés de Uniform Resource Locator; o sea, localizador uniforme de recursos) significa que su conexión es segura, y es mucho más difícil que otra persona vea lo que usted está haciendo. Pero si HTTPS es más seguro, ¿por qué no se utiliza en toda la Web?

HTTPS ha existido casi por tanto tiempo como la web misma, pero es utilizado principalmente por los sitios que manejan dinero – el sitio web de su banco o los carritos de la compra que capturan los datos de su tarjeta de crédito. Incluso, muchos sitios que hacen uso de HTTPS la utilizan solo para las partes de sus sitios que lo necesitan, tales como los carritos de la compra o las páginas de cuentas.

La seguridad en la Web recibió un disparo en el brazo el año pasado cuando la herramienta de rastreo FireSheep network-sniffing tool facilitó que cualquiera pueda detectar su información de acceso en las redes inseguras, tales como el punto de acceso de su cafetería local o el Wi-Fi público de la biblioteca. Eso ocasionó que una serie de sitios de gran tamaño comenzaran a ofrecer versiones cifradas de sus servicios en las conexiones HTTPS.

Últimamente, incluso sitios como Twitter (cuyos datos son casi en su totalidad públicos) están ofreciendo conexiones HTTPS. Es posible que a usted no le importe si alguien rastrea y lee sus mensajes de Twitter en ruta hacia el servidor, pero a la mayoría de la gente creo que sí le preocuparía que alguien tenga acceso a la lectura de su nombre de usuario y la información de contraseña. Es por eso que Twitter ha anunciado recientemente una nueva opción para forzar conexiones HTTPS (tenga en cuenta que la opción HTTPS de Twitter sólo funciona con un navegador de escritorio, no con sitios móviles, que aún requieren introducir manualmente la dirección HTTPS).

Google incluso ha anunciado que añadirá HTTPS para muchas de las API (Siglas de Application Programming Interface; o sea, Interfaz de programación de la aplicación) de la compañía. Los usuarios de Firefox pueden dar un paso extra y utilizar el add-on HTTPS Everywhere (en todas partes) para forzar conexiones HTTPS para varias docenas de sitios web que ofrecen HTTPS, pero que no lo usan como parte integral.

Por tanto, si la web está claramente avanzando hacia más conexiones de HTTPS, ¿por qué no hacer todo HTTPS?

Esa es la pregunta que hice a Yves Lafon, uno de los expertos residentes en HTTP(S) de la W3C. Hay algunas cuestiones prácticas que probablemente la mayoría de los desarrolladores web reconocen, tales como el alto costo de los certificados de seguro, pero obviamente eso no es un gran problema para los servicios web de gran tamaño que tienen millones de dólares.

El verdadero problema, según Lafon, es que con HTTPS se pierde la capacidad para almacenar en cache. "Eso no es realmente un problema cuando los servidores y los clientes están en la misma región (o sea, en el mismo continente)", escribe Lafon en un correo electrónico a Webmonkey, "pero, por ejemplo, a la gente en Australia le encanta cuando algo puede ser almacenado en cache y servirse sin tomar un gran tiempo de respuesta."

Lafon también hace notar que hay otro pequeño escollo al usar HTTPS, ya que "el intercambio de claves inicial SSL se suma a la latencia." En otras palabras, una web totalmente HTTPS, orientada puramente a la seguridad, con la tecnología actual resultaría más lenta.

Para los sitios que no tienen ninguna razón para cifrar su información - en otras palabras, no necesitan clave de acceso, o no hay nada que proteger - los gastos indirectos y la pérdida de la memoria cache que viene con HTTPS simplemente no hace sentido. Sin embargo, en sitios grandes como Facebook, Google Apps o Twitter, la mayoría de usuarios podrían estar dispuestos a enfrentar el pequeño impacto de rendimiento a cambio de una conexión más segura. Y el hecho de que más y más sitios web están añadiendo soporte de HTTPS muestra que los usuarios valoran la seguridad sobre la velocidad, siempre y cuando la diferencia de velocidad sea mínima.

Otro problema con el funcionamiento de un sitio HTTPS es el costo de las operaciones. "Aunque los servidores son más rápidos, y las implementaciones de SSL más optimizadas, todavía cuesta más que el simple uso de HTTP", escribe Lafon. Si bien esto no es una preocupación para los sitios más pequeños con poco tráfico, HTTPS puede encarecer sus operaciones si su sitio de repente se vuelve popular.

Pero tal vez la principal razón por la que la mayoría de nosotros no está usando HTTPS para servir nuestros sitios web es simplemente porque no funciona con máquinas virtuales. Las máquinas virtuales, que son las más comunes en proveedores baratos de alojamientos de web, permiten al proveedor servir a múltiples sitios web desde el mismo servidor físico - cientos de sitios web, todos con la misma dirección IP. Eso funciona muy bien con conexiones regulares de HTTP, pero no funciona en absoluto con HTTPS.

Hay una manera de lograr que el alojamiento virtual y HTTPS trabajen juntos: el protocolo de extensiones TLS; pero Lafon observa que, hasta ahora, estas están implementadas solo en parte. Por supuesto, eso no es un problema para los sitios grandes, que a menudo tienen granjas enteras de servidores detrás de ellos. Pero hasta que esas especificaciones, o algo similar, no sean ampliamente utilizadas, HTTPS no va a funcionar para los sitios web pequeños, alojados virtualmente.

A fin de cuentas, no hay ninguna razón real para que toda la red no utilice HTTPS. Hay razones prácticas por lo que eso no está sucediendo hoy en día, pero con el tiempo los obstáculos prácticos se desvanecerán. Las velocidades de banda ancha van a mejorar, lo que hará que el almacenamiento en cache sea una preocupación menos, y los servidores mejorados serán optimizados para conexiones seguras.

En la web del futuro, la principal preocupación no será solo la rapidez con que el sitio cargue, sino lo bien que resguarde y proteja sus datos una vez ha sido cargado.

Traducción de Isaías Ferreira

GLOSARIO

API (Siglas de Application Programming Interface; o sea, Interfaz de programación de la aplicación)

HTTP (Hyper Text Transfer Protocol) = Protocolo de transferencia de hipertexto

HTTPS (http Secure) = Protocolo de transferencia de hipertexto seguro

URL (Uniform Resource Locator) = localizador uniforme de recursos

Wi-Fi = Equipos de Red Inalámbrica que se ajustan a la norma IEEE 802.11b

W3C (The World Wide Web Consortium (W3C)) = El Consorcio World Wide Web

SSL (Secure Sockets Layer) = Capa de seguridad

Webmonkey = Sitio web de recursos para desarrolladores: Webmonkey

IP Address (Internet Protocol Address) = Dirección de Protocolo de Internet

TLS Extensions (Transport Layer Security Extensions) = Extensiones de seguridad de la capa de transporte