Recientemente Google dio a conocer ha comenzado a implementar una nueva API «Raw Sockets» en Chrome que permite que las aplicaciones web establezcan conexiones de red directas utilizando los protocolos TCP y UDP.

Cabe recordar que en 2015, el consorcio W3C ya intentó estandarizar la API «TCP y UDP Socket», pero los miembros del grupo de trabajo no llegaron a un consenso y se detuvo el desarrollo de esta API.

Pero Google ha retomado el camino ante la necesidad de agregar una nueva API y se debe a la provisión de interoperabilidad con dispositivos de red que usan protocolos propietarios que se ejecutan sobre TCP y UDP y no admiten la comunicación a través de HTTPS o WebSockets.

Cabe señalar que la API Raw Sockets complementará las API WebUSB, WebMIDI y WebBluetooth de bajo nivel ya disponibles en el navegador, que permiten interactuar con dispositivos locales.

Para excluir un impacto negativo en la seguridad, la API Raw Sockets solo permitirá llamadas de red iniciadas con el consentimiento del usuario y limitadas a la lista de hosts permitidos por el usuario.

El usuario tendrá que confirmar explícitamente el primer intento de conexión para el nuevo host. Con la ayuda de un indicador especial, el usuario podrá deshabilitar la salida de solicitudes repetidas de confirmación de la operación en conexiones repetidas al mismo host.

Para evitar ataques DDoS, la intensidad de las solicitudes a través de Raw Sockets será limitada y el envío de solicitudes solo será posible después de que el usuario interactúe con la página. Los paquetes UDP recibidos de hosts no aprobados por el usuario serán ignorados y no llegarán a la aplicación web.

La implementación inicial no prevé la creación de sockets de escucha, pero en el futuro es posible proporcionar llamadas para aceptar conexiones entrantes de localhost o una lista de hosts conocidos.

También menciona la necesidad de protegerse contra los ataques de revinculación de DNS (un atacante puede cambiar la dirección IP de un nombre de dominio aprobado por el usuario en el nivel de DNS y obtener acceso a otros hosts).

Está previsto bloquear el acceso a los dominios resueltos en 127.0.0.0/8 y la intranet de la red (se propone permitir llamadas a localhost solo si la dirección IP se ingresa explícitamente en el formulario de confirmación).

Entre los riesgos que pueden surgir cuando se implementa la nueva API, se observa que puede ser rechazada por fabricantes de otros navegadores, lo que podría generar problemas de compatibilidad.

Los desarrolladores de los motores Mozilla Gecko y WebKit aún no han resuelto su posición sobre una posible implementación de la API Raw Sockets, pero Mozilla ha ofrecido anteriormente una API similar para el proyecto Firefox OS (B2G).

Si se aprueba en la primera etapa, se planea que la API Raw Sockets se active en Chrome OS y solo luego se ofrezca a los usuarios de Chrome en otros sistemas.

Los desarrolladores web han comentado favorablemente sobre la nueva API y han presentado muchas ideas nuevas para su uso en áreas donde las API XMLHttpRequest, WebSocket y WebRTC no son suficientes (desde crear clientes de navegador para SSH, RDP, IMAP, SMTP, IRC y protocolos de impresión hasta desarrollar sistemas P2P distribuidos con DHT (Distributed Hash Table), soporte IPFS e interacción con protocolos específicos de dispositivos IoT).

Por otra parte, también vale la pena mencionar que el registrador APNIC responsable de la distribución de direcciones IP en la región de Asia-Pacífico ha publicado los resultados de un análisis de la distribución del tráfico en uno de los servidores DNS root-servers.net.

En el cual el 45,80% de las solicitudes al servidor root se debieron a comprobaciones realizadas por navegadores basados ​​en el motor Chromium. Por lo tanto, casi la mitad de los recursos de los servidores DNS root se gastan en realizar comprobaciones de diagnóstico de Chromium, en lugar de procesar consultas de servidores DNS al determinar las zonas root.

Dado que Chrome representa el 70% del mercado de navegadores web, esta actividad de diagnóstico genera alrededor de 60 mil millones de solicitudes por día.

Las comprobaciones de diagnóstico se utilizan en Chromium para determinar si los proveedores de servicios utilizan proveedores de servicios que redirigen las solicitudes de nombres inexistentes a sus controladores.

Algunos proveedores implementan dichos sistemas para dirigir el tráfico a los nombres de dominio ingresados ​​con un error; como regla, se muestran páginas con una advertencia de error, una lista de nombres probablemente correctos y publicidad para dominios inexistentes.