Ovviamente TLS è un must per qualsiasi autenticazione sicura. Si prega di trasformare le impostazioni di paranoia fino a 11 per questo.
Sfondo : (Nel caso in cui le persone non conoscano il protocollo WebSocket (WS) e le sue idiosincrasie) La connessione WebSocket TLS (WSS) è una connessione diversa dalla connessione TLS HTTP. Ciò significa che non è possibile autenticare automaticamente l'altro. A causa dei proxy, in particolare di uno malintenzionato che esegue un attacco MitM, semplicemente lo stesso indirizzo IP remoto (o anche lo stesso ID di sessione) non garantisce che le due connessioni provengano dallo stesso browser.
WS è una connessione TCP persistente con un'API molto limitata sul lato client che non consente l'ispezione dei dettagli TLS per le connessioni WSS. È progettato per funzionare bene con firewall e proxy (non dannosi) che limitano il traffico solo al traffico HTTP ed è desiderabile a causa della sua ubiquità nei browser Web moderni.
In PHP, WS viene (in genere) implementato utilizzando uno script CLI (command line), che esegue il proprio server accettando e gestendo le connessioni socket direttamente, anziché essere mediato attraverso un server HTTP. (Se è coinvolto un server HTTP, è solo per inoltrare il traffico dopo l'aggiornamento riuscito e diventa un proxy trasparente per tutti gli scopi dopo l'handshake.) Quindi, i tipici superglobali di PHP non hanno significato nella CLI di PHP.
Il passaggio dei cookie è possibile durante l'handshake WS, incluso un ID di sessione. Nella CLI di PHP è possibile (ma sgraziato) accedere ai dati della sessione corrente, anche dopo un cambiamento di stato innescato dal lato HTTP delle cose, se si conosce l'ID di sessione. Tuttavia, poiché i cookie vengono passati solo durante l'handshake WS, il server WS non riceve notifica delle modifiche ai cookie, come l'ID di sessione.
AJAX rimane autenticato tramite la connessione HTTPS, ovviamente, e sono sicuro che c'è un modo per sfruttare le richieste AJAX per autenticare le connessioni WSS usando lo stesso browser.
Esempio di dirottamento della sessione : Alice accede a bob.com tramite i normali mezzi HTTPS, ma ha un proxy malevolo tra di loro, di proprietà di Mallory, che esegue un attacco di intercettazione MitM che ha compromesso la sessione ID.
Mallory quindi usa l'ID di sessione nel proprio cookie di sessione per connettersi al server WSS, che è dove mi imbatto nei miei problemi, perché non so chi distinguere tra il browser aperto e completamente autenticato di Alice e Mallory's browser completamente diverso su un computer completamente diverso.
Quindi, sapendo che l'ID di sessione è potenzialmente insicuro, è un obiettivo primario ed è immutabile una volta avviata la connessione WS, come posso autenticare che una determinata connessione WSS sia in esecuzione nella stessa istanza del browser sullo stesso computer di una determinata connessione HTTPS?
Modifica : una volta avviata la connessione HTTPS, Mallory non tenta di interferire per evitare di essere rilevato. Quindi, una volta stabilito TLS, la connessione HTTPS è protetta da Mallory da questo punto in poi, ma Mallory avrebbe ancora l'ID di sessione.
Giustificazione per questo requisito limite : Sto scrivendo il software WebSocket open source, quindi non sono in grado di proteggere l'ID della sessione attraverso mezzi come garantire che il cookie di sessione abbia il flag di sicurezza impostato, che l'ID di sessione viene rigenerato, ecc., ma può imporre che l'implementatore includa uno script client che aiuti a garantire l'autenticazione su entrambi i mezzi.