Socket.IO e WebSocket non forniscono informazioni di connessione sottostanti (come il certificato o la chiave pubblica del canale SSL / TLS) e sto cercando di capire il ragionamento.
Il contesto per questa domanda è un'applicazione web caricata lateralmente che desidera interrogare il certificato o la chiave pubblica della sua connessione sottostante. La query verrebbe utilizzata per il blocco della chiave pubblica o del certificato. Qui, il caricamento laterale fornisce un canale di distribuzione affidabile, quindi la manomissione di HTML / CSS / Javascript non è un problema o una minaccia.
Coloro che dichiarano il suo stato non necessario (1) la piattaforma esegue controlli quindi non necessari; (2) CSS o Javascript potrebbero utilizzare il certificato del server o la chiave pubblica per tracciare gli utenti, quindi è una potenziale perdita; e (3) la sua inefficienza, quindi non è gradita.
Penso che ci siano alcuni problemi con gli argomenti. Innanzitutto, abbiamo visto una serie di problemi in passato, come Diginotar e recentemente Turchia manomissione DNS . La piattaforma / browser non ha rilevato i problemi (sans Chrome a causa del blocco), quindi i browser non eseguono i controlli corretti . Capisco che il browser non possa sapere queste cose (è una "caratteristica" o una limitazione nel modello di sicurezza), ed è la ragione per cui voglio che le app siano di mia competenza.
In secondo luogo, il malware vuole raccogliere e inviare dati. Quindi le parti più pericolose di Socket.IO e WebSocket API sono open e write . Dubito che la possibilità di interrogare il certificato o la chiave pubblica di un server superi il rischio di open e write .
In terzo luogo, sono abbastanza sicuro che ci siano migliori vettori per CSS o Javascript per tracciare gli utenti o la loro navigazione (come il CSS che traccia il cambio di colore su un link visitato), quindi non lo considero una minaccia immediata o ad alta priorità . Se si tratta di una minaccia, ritengo che i benefici dell'indurimento del canale superino la possibile perdita. (Soprattutto nell'era post-Snowden).
Infine, per quanto riguarda l'efficienza, devo rimandare al Dr. Jon Bentley: "Se non deve essere corretto, posso farlo velocemente come vorresti che fosse". Immagino che includa tutti i tipi di ottimizzazioni intelligenti, come eNull quando si utilizza TLS.
Ecco la mia domanda chiusa: è davvero considerata una potenziale perdita per consentire a Javascript di chiedere il certificato del server? Il timore di una "perdita" del certificato del server supera di gran lunga i vantaggi dell'indurimento e del blocco dei canali?
Ecco la domanda a risposta aperta: cosa non capisco correttamente o cosa mi manca? Sento che c'è una grande disconnessione tra quello che voglio e quello che mi aspetto e quello che la gente che scrive gli standard è disposta a fornire.
Per completezza, "web application" è il termine generico e coprirebbe, ad esempio, App Sys, App in hosting, App di Chrome, App pacchettizzate, App installabili, ecc. Non coprirebbe altre app Web, come le App con segnalibri perché ciò richiederebbe un recupero.
Correlati: un'altra buona domanda sulla sicurezza WebSocket: Elaborazione della sicurezza dei Websocket , ma non discuti le funzionalità mancanti.