WebSocket

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

WebSocket è una tecnologia web che fornisce canali di comunicazione full-duplex attraverso una singola connessione TCP. L'API del WebSocket è stata standardizzata dal W3C e il protocollo WebSocket è stato standardizzato dall'IETF come RFC 6455.

WebSocket è progettato per essere implementato sia lato browser che lato server, ma può essere utilizzato anche da qualsiasi applicazione client-server. Il protocollo è un'implementazione basata sul protocollo TCP. La sua unica correlazione con l'HTTP è nel modo in cui fa l'handshake durante una Upgrade request tra server. Il protocollo WebSocket permette maggiore interazione tra un browser e un server, facilitando la realizzazione di applicazioni che forniscono contenuti e giochi in tempo reale. Questo è reso possibile fornendo un modo standard per il server di mandare contenuti al browser senza dover essere sollecitato dal client e permettendo ai messaggi di andare e venire tenendo la connessione aperta.

In aggiunta, le comunicazioni sono fatte attraverso la porta TCP 80, che è un vantaggio per gli ambienti che bloccano porte non standard utilizzando dei firewall. Il protocollo WebSocket è supportato da numerosi browser, incluso Google Chrome, Internet Explorer, Firefox, Safari e Opera.

Implementazione del browser

[modifica | modifica wikitesto]
Protocollo, versione Data del progetto Internet Explorer Firefox[1] (PC) Firefox (Android) Chrome (PC, Mobile) Safari (Mac, iOS) Opera (PC, Mobile) Android Browser
hixie-75 4 febbraio, 2010 4 5.0.0
hixie-76hybi-00 6 maggio

2010 23 maggio 2010

4.0 (disabilitato) 6 5.0.1 11.00 (disabilitato)
hybi-07, v7 22 aprile 2011 6[2]
hybi-10, v8 11 luglio 2011 7[3] 7 14[4]
Template:IETF RFC, v13 Dicembre

2011

10[5] 11 11 16[6] 6 12.10[7] 4.4

Handshake del protocollo

[modifica | modifica wikitesto]

Per stabilire una connessione WebSocket, il client invia una richiesta di handshake e il server invia una risposta come indicato nell'esempio[8].

Richiesta del client: 

GET /mychat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://example.com

Risposta del server: 

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

L'handshake ricorda l'implementazione HTTP così il server può gestirla come una normale richiesta di connessione sulla stessa porta. All'interno della richiesta vengono specificati degli opportuni campi che identificano una richiesta WebSocket.

Ognuna delle linee termina con un EOL, \n o \r\n e deve essere presente una linea vuota alla fine.

Il client invia un Sec-WebSocket-Key che è un valore casuale codificato con base64. Per generare un codice di risposta, il codice 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 è concatenato alla chiave ricevuta, che non viene decodificata. Il risultato viene dato in input alla funzione hash SHA-1 e il digest viene successivamente codificato con base64. Infine, la stringa risultante viene inserita nella risposta con l'header Sec-WebSocket-Accept.

Dettagli per generare la chiave di risposta:

  • Della stringa concatenata x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11 si calcola il digest SHA-1, che vale 0x1d29ab734b0c9585240069a6e4e3e91b61da1969.
  • Codificando i byte del digest con base64 si ottiene il codice HSmrc0sMlYUkAGmm5OPpG2HaGWk=, che è il valore inserito nella risposta.

Quando viene stabilita la connessione, il client ed il server possono inviare dati tramite il WebSocket in entrambe le direzioni[9][10][11][12].

Estensioni sperimentali

[modifica | modifica wikitesto]

Google Chrome ha un'opzione a riga di comando (--enable-websocket-over-spdy) che permette di abilitare una versione sperimentale dei WebSocket veicolati dal protocollo SPDY.[13]

Sviluppo

[modifica | modifica wikitesto]

Utilizzando il Google Chrome Developer Tools, lo sviluppatore può controllare l'handshake ed i pacchetti che vengono scambiati nel canale.[14]

Implementazione del server web

[modifica | modifica wikitesto]

Nginx supporta WebSocket dal 2013, implementato nella versione 1.3.13 inclusa la funzione di proxy inverso e bilanciamento del carico delle applicazioni WebSocket[15].

Apache HTTP Server supporta WebSocket da luglio 2013, implementato nella versione 2.4.5[16][17].

Internet Information Services ha aggiunto il supporto per WebSocket nella versione 8 che è stata rilasciata con Windows Server 2012[18].

Lighttpd supporta WebSocket dal 2017, implementato nella versione 1.4.46.[19] lighttpd mod_proxy può fungere da proxy inverso e bilanciatore del carico delle applicazioni WebSocket. lighttpd mod_wstunnel può facilitare un tunnel WebSocket, consentendo a un client di utilizzare WebSocket per eseguire il tunneling di un protocollo più semplice, come JSON, a un'applicazione di backend.

Considerazioni sulla sicurezza

[modifica | modifica wikitesto]

A differenza delle normali richieste HTTP tra domini, le richieste WebSocket non sono limitate dalla politica della stessa origine. Pertanto i server WebSocket devono convalidare l'intestazione "Origin" rispetto alle origini previste durante la creazione della connessione, per evitare attacchi di dirottamento WebSocket tra siti (simili alla contraffazione di richieste tra siti), che potrebbero essere possibili quando la connessione è autenticata con cookie o autenticazione HTTP. È preferibile utilizzare token o meccanismi di protezione simili per autenticare la connessione WebSocket quando vengono trasferiti dati sensibili (privati) su WebSocket[20]. Un esempio dal vivo di vulnerabilità è stato visto nel 2020 sotto forma di Cable Haunt.

Attraversamento proxy

[modifica | modifica wikitesto]

Le implementazioni del client del protocollo WebSocket tentano di rilevare se l'agente utente è configurato per utilizzare un proxy durante la connessione all'host e alla porta di destinazione e, in tal caso, utilizza il metodo HTTP CONNECT per impostare un tunnel persistente.

Sebbene il protocollo WebSocket stesso non sia a conoscenza dei server proxy e dei firewall, presenta un handshake compatibile con HTTP che consente ai server HTTP di condividere le loro porte HTTP e HTTPS predefinite (443 e 80) con un gateway o un server WebSocket. Il protocollo WebSocket definisce un prefisso ws: // e wss: // per indicare rispettivamente una connessione WebSocket e WebSocket Secure. Entrambi gli schemi utilizzano un meccanismo di aggiornamento HTTP per eseguire l'aggiornamento al protocollo WebSocket. Alcuni server proxy sono trasparenti e funzionano bene con WebSocket; altri impediranno a WebSocket di funzionare correttamente, causando il fallimento della connessione. In alcuni casi, potrebbe essere necessaria una configurazione aggiuntiva del server proxy e alcuni server proxy potrebbero dover essere aggiornati per supportare WebSocket.

Se il traffico WebSocket non crittografato passa attraverso un server proxy esplicito o trasparente senza il supporto di WebSocket, è probabile che la connessione non riesca[21].

Se viene utilizzata una connessione WebSocket crittografata, l'utilizzo di Transport Layer Security (TLS) nella connessione WebSocket Secure garantisce che un comando HTTP CONNECT venga emesso quando il browser è configurato per utilizzare un server proxy esplicito. Questo imposta un tunnel, che fornisce comunicazioni TCP end-to-end di basso livello attraverso il proxy HTTP, tra il client WebSocket Secure e il server WebSocket. Nel caso di server proxy trasparenti, il browser non è a conoscenza del server proxy, quindi non viene inviato alcun CONNECT HTTP. Tuttavia, poiché il traffico cablato è crittografato, i server proxy trasparenti intermedi possono semplicemente consentire il passaggio del traffico crittografato, quindi è molto più probabile che la connessione WebSocket riesca se viene utilizzato WebSocket Secure. L'utilizzo della crittografia non è privo di costi in termini di risorse, ma spesso fornisce la più alta percentuale di successo poiché viaggerebbe attraverso un tunnel sicuro.

Una bozza di metà 2010 (versione hixie-76) ha rotto la compatibilità con proxy inversi e gateway includendo otto byte di dati chiave dopo le intestazioni, ma non pubblicizzando tali dati in un'intestazioneContent-Length: 8[22]. Questi dati non sono stati inoltrati da tutti gli intermedi, il che potrebbe portare al fallimento del protocollo. Le bozze più recenti (ad esempio, hybi-09[23]) inseriscono i dati chiave in Sec-WebSocket-Keyun'intestazione, risolvendo questo problema.

Voci correlate

[modifica | modifica wikitesto]

Collegamenti esterni

[modifica | modifica wikitesto]
  1. ^ WebSockets (support in Firefox), su developer.mozilla.org, Mozilla Foundation, 30 settembre 2011. URL consultato il 10 dicembre 2011 (archiviato dall'url originale il 26 maggio 2012).
  2. ^ Bug 640003 - WebSockets - upgrade to ietf-06, su bugzilla.mozilla.org, Mozilla Foundation, 8 marzo 2011. URL consultato il 10 dicembre 2011.
  3. ^ Bug 640003 - WebSockets - upgrade to ietf-07(comment 91), su bugzilla.mozilla.org, Mozilla Foundation, 22 luglio 2011.
  4. ^ Chromium bug 64470, su code.google.com, 25 novembre 2010. URL consultato il 10 dicembre 2011.
  5. ^ WebSockets in Windows Consumer Preview, in IE Engineering Team, Microsoft, 19 marzo 2012. URL consultato il 23 luglio 2012.
  6. ^ WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17, su trac.webkit.org. URL consultato il 10 dicembre 2011.
  7. ^ A hot Opera 12.50 summer-time snapshot, su my.opera.com, Opera Developer News, 3 agosto 2012. URL consultato il 3 agosto 2012 (archiviato dall'url originale il 5 agosto 2012).
  8. ^ Template:Cite IETF
  9. ^ Main Goal of WebSocket protocol, su trac.tools.ietf.org, IETF. URL consultato il 25 luglio 2015.
    «The computation [...] is meant to prevent a caching intermediary from providing a WS-client with a cached WS-server reply without actual interaction with the WS-server.»
  10. ^ Template:Cite IETF
  11. ^ Template:Cite IETF
  12. ^ Template:Cite IETF
  13. ^ List of Chromium Command Line Switches, su peter.sh. URL consultato il 10 dicembre 2011.
  14. ^ Vanessa Wang, Frank Salim e Peter Moskovits, APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools, in The Definitive Guide to HTML5 WebSocket, Apress, febbraio 2013, ISBN 978-1-4302-4740-1. URL consultato il 19 luglio 2013 (archiviato dall'url originale il 31 dicembre 2015).
  15. ^ Using NGINX as a WebSocket Proxy, su NGINX, 17 maggio 2014.
  16. ^ Overview of new features in Apache HTTP Server 2.4, su Apache.
  17. ^ Changelog Apache 2.4, su Apache Lounge.
  18. ^ IIS 8.0 WebSocket Protocol Support, in Microsoft Docs, 28 novembre 2012. URL consultato il 18 febbraio 2020.
  19. ^ [1]
  20. ^ Christian Schneider, Cross-Site WebSocket Hijacking (CSWSH), in Web Application Security Blog, 31 agosto 2013.
  21. ^ Peter Lubbers, How HTML5 Web Sockets Interact With Proxy Servers, su Infoq.com, C4Media Inc., 16 marzo 2010. URL consultato il 10 dicembre 2011.
  22. ^ Willy Tarreau, WebSocket -76 is incompatible with HTTP reverse proxies (email), su ietf.org, Internet Engineering Task Force, 6 luglio 2010. URL consultato il 10 dicembre 2011.
  23. ^ Template:Cite IETF
  Portale Internet
Estratto da "https://it.wikipedia.org/w/index.php?title=WebSocket&oldid=139848118"