Tecnología WebSockets

Los  WebSockets  [267]  han  sido  incorporados  en  HTML5  para  posibilitar,  de  forma  nativa  (sin  necesidad de plugins o programas propietarios) que las páginas Web y las aplicaciones contenidas en  éstas realicen transacciones de gran volumen de información en la Web en tiempo real y de forma  bidireccional,  pudiendo  el  servidor  enviar  información  sin  necesidad  de  que  el  cliente  realice  una  petición  previa.  La  comunicación  se  desarrolla  sobre  un  socket  tradicional  TCP/IP  bidireccional,  sin  necesidad  de  seguir  el  mecanismo  tradicional  de  HTTP.  Precisamente  esta  tecnología  es  el  complemento necesario para poder dotar a las aplicaciones nativas (implementadas con JavaScript,  HTML5  y  CSS3)  del  soporte  de  comunicaciones  necesario  y  ofrecer  una  usabilidad  mayor  que  las  aplicaciones  instalables  o  de  escritorio.  Como  cualquier  aplicación  Web  2.0,  el  mantenimiento  de  versiones queda centralizado de forma que el cliente o usuario no tenga que preocuparse de poder  tener  actualizada  la  aplicación.  Por  otro  lado,  se  consigue  además  una  funcionalidad  multi‐ plataforma basada en el navegador Web, e independiente de arquitecturas o sistemas operativos.  Esta  tecnología  ha  ido  evolucionando  desde  la  aparición  de  la  primera  propuesta  en  Julio  de  2009  (The  Web  Socket  protocol  draft‐hixie‐thewebsocketprotocol‐00),  especialmente  en  aspectos  relacionados con el tipo de formato de trama para las comunicaciones y la seguridad. En este aspecto,  ya dentro de la siguiente etapa de desarrollo (a partir de la versión draft‐hixie‐thewebsocketprotocol‐

76 [268], pasan a denominarse draft‐ietf‐hybi‐thewebsocketprotocol bajo la gestión del IETF [178]) y, 

de  seguridad  de  tipo  cache  poisoning  detectados  a  finales  del  año  2010  [269].  Llevando  un  seguimiento  de  la  evolución  del  protocolo,  se  han  ido  implementando  las  diferentes  versiones  publicadas  hasta  la  fecha,  estando  en  las  aplicaciones  basadas  en  WebSockets  desarrollados  en  el  marco  de  esta  tesis,  la  versión  17  (30  Septiembre  2011)  [270]  que  es  compatible  con  las  últimas  versiones  del  navegador  Google  Chrome.  El  proceso  de  establecimiento  de  la  conexión  en 

WebSockets  (versión  6+)  se  basa  en  un  mecanismo  de  handshake  de  seguridad  inicializado  por  el 

cliente, que consiste en una cabecera HTTP con parámetros relativos al protocolo WebSockets, en un  orden aleatorio:  GET /chat HTTP/1.1 Host: server.example.com  Upgrade: websocket  Connection: Upgrade  Sec‐WebSocket‐Key: dGhlIHNhbXBsZSBub25jZQ==  Sec‐WebSocket‐Origin: http://example.com  Sec‐WebSocket‐Protocol: chat, X73  Sec‐WebSocket‐Version: 8     

La  cabecera,  que  sigue  el  formato  de  Request‐Line  definido  en  HTTP,  contiene  básicamente  el  comando  GET  y  dos  líneas  de  declaración  estándar  de  conversión  a  WebSockets  (upgrade  y 

connection).  Otra  de  las  líneas  permite  definir,  como  medida  de  seguridad,  la  localización  del  host 

remoto que llevará a cabo la comunicación con el cliente una vez establecido el enlace. En el caso de  que  el  host  indicado  no  exista,  el  procedimiento  de  handshake  será  abortado  automáticamente.  Adicionalmente,  las  siguientes  líneas  están  orientadas  a  ofrecer  un  mayor  grado  de  seguridad  durante el proceso: 

 Sec‐WebSocket‐Protocol: X73. Permite definir el tipo de sub‐protocolo a emplear, una vez se ha  establecido  la  conexión  entre  ambos  extremos.  Si  el  servidor  soporta  dicho  sub‐protocolo  lo  incluye de vuelta en el mensaje de respuesta del handshake. En el caso de que el cliente ofrezca  un subprotocolo no soportado por el servidor, este puede abortar directamente la solicitud.   Sec‐WebSocket‐Origin: http://example.com. Indica el dominio en el cual se encuentra la página 

Web  con  la  aplicación  (script)  que  implementa  los  WebSockets  configurados  para  acceder  al  servidor.  Es  una  medida  de  evitar  ataques  de  tipo  DNS,  así  como  para  permitir  servir  varios  dominios  desde  una  misma  dirección  IP.  En  el  caso  de  WebSockets  implementados  de  forma  nativa mediante JavaScript en una página Web, contiene el dominio del servidor de dicha página,  de  forma  que  puedan  restringirse  los  accesos  no  autorizados  a  los  recursos  del  servidor  si  han  obtenido el código de forma alternativa. 

Después  de  que  el  servidor  ha  recibido  la  solicitud,  además  de  comprobar  los  parámetros  de  seguridad mencionados, ha de procesar un desafío de clave que consistente en las siguientes etapas: 

1. Extraer la clave, la cual se encuentra en Sec‐WebSocket‐Key: dGhlIHNhbXBsZSBub25jZQ==.  2. Concatenar  la  clave  con  el  GUID  “258EAFA5‐E914‐47DA‐95CA‐C5AB0DC85B11”,  obteniendo 

como  resultado  un  nuevo  string  de  texto.  El  objetivo  es  minimizar  la  probabilidad  de  que  sea  usado por endpoints que desconozcan el protocolo WebSockets, reforzando la seguridad.  3. Obtener la huella (SHA‐1) [271] a partir del string anterior y codificar como base‐64 antes de ser  devuelta al cliente.  Una vez procesada la respuesta y comprobados los requisitos de seguridad, el servidor responde al  cliente de la siguiente forma:  HTTP/1.1 101 Switching Protocols Upgrade: websocket  Connection: Upgrade  Sec‐WebSocket‐Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  Sec‐WebSocket‐Protocol: X73    En esta cabecera se indica tanto la clave de respuesta como el nombre del subprotocolo soportado  para poder iniciar las comunicaciones. A partir de ese momento, la conexión queda establecida y las  dos  entidades  pueden  comenzar  a  intercambiar  información.  Como  ya  se  ha  puntualizado  al  comienzo de esta sección, el formato de intercambio de tramas ha evolucionado de igual forma que  los algoritmos de seguridad en WebSockets. Inicialmente basado en la codificación del contenido del  mensaje (payload) UTF‐8 [272] con un sistema de señalización basado en caracteres de delimitación  (0x00  y  0xFF),  es  a  partir  de  la  versión  4  (draft‐ietf‐hybi‐thewebsocketprotocol‐04)  [273]  cuando  se  introducen  los  mecanismos  que  posibilitan  la  transmisión  binaria  mediante  la  introducción  del  concepto  de  Base  Framing  Protocol.  Este  formato  está  descrito  mediante  el  lenguaje  Augmented 

Backus‐Naur Form (ABNF) [274], que define la sintaxis y forma para la comunicación bidireccional. El  formato de una trama de WebSockets es el mostrado en la Figura 41.    Figura 41. Base Framing Protocol de WebSockets.  Donde los campos representados en la Figura 41 se describen en la Tabla 16.   

Tabla 16. Base Framing Protocol: descripción de campos.  Campo  Descripción  FIN  Indica si es el fragmento final en un mensaje.  RSV  Posibilita la introducción de extensiones sobre el protocolo.  OPCODE  Representa el tipo de mensaje, la interpretación del contenido del payload.  MASK  Indica si se emplea una máscara para la codificación del payload. Todos los  mensajes enviados desde el cliente han de ser enmascarados con un array  aleatorio de 4 bytes. En el caso del servidor, esta característica es opcional.  PAYLOAD  Contiene el tamaño del payload en  bytes.  MASKING KEY  Máscara de codificación, si usada.  PAYLOAD DATA  Datos efectivos o de aplicación.   

Dependiendo  del  código  de  control  (OPCODE),  los  tipos  de  mensaje  definidos  pueden  ser  los  mostrados en la Tabla 17:  Tabla 17. Base Framing Protocol: tipos de mensaje.  OPCODE  Descripción  0x0  Continuación, indicando que el frame forma parte junto con otros de un mismo  mensaje.  0x1  Formato de texto codificado en UTF‐8.  0x2  Formato binario, para la codificación directa de bytes.  0x3 – 0x7  Reservados.  0x8  Solicitud de finalización de la conexión.  0x9  Ping.  0xA  Pong.  0xB – 0xF  Reservados.   

Independientemente  del  tipo  de  codificación  empleada  para  la  transferencia  de  mensajes, 

WebSockets implementa además el uso de fragmentación. El objetivo principal es permitir el envío 

secuenciado  de  mensajes  cuyo  tamaño  es  desconocido  a  priori,  de  forma  que  el  receptor  pueda  ir  recibiendo  e  interpretando  la  información  en  su  caso.  Otra  de  las  razones  es  posibilitar  la  multiplexación sobre diferentes canales para que un mismo mensaje no haga un uso exclusivo de un  único canal, consiguiendo un balance de la carga de datos en la transferencia.