simonebortolin Cioè tu stai implicitamente dicendo che tutto ciò che usa wss è insicuro perché a tuo dire non c'è uno scambio di chiavi
Mai detto niente di simile:
lo scambio di chiavi c'è altrimenti non andrebbe su la sessione TLS, però un conto è se io e te ci scambiamo delle chiavi e cifriamo la connessione. Questo rende la connessione difficile da decifrare per terzi, ma non dice niente su me e te.
Il motivo per cui c'è una differenza sostanziale tra un semplice scambio di chiavi, dei certificati self-signed e dei certificati trusted da una certification authority è proprio che se tu semplicemente cifri una connessione con uno scambio di chiavi non hai la certezza di parlare con l'interlocutore giusto.
Lo stesso dicasi per i certificati self-signed: tu dichiari di essere tu e io dichiaro di essere io.
Mentre se usi dei certificati emessi da una CA entrambi gli interlocutori possono verificare se c'è corrispondenza tra i nomi DNS dell'host con cui parli e il certificato che dichiarano di avere. Peraltro esistono anche diversi tipi di certificati: i wildcard sono meno sicuri, ma puoi addirittura trustare un certificato che punta ad un FQDN ed una porta precisa (ma non lo fa nessuno perché poi la cosa va gestita ed è una delle cose più antipatiche da gestire in assoluto).
La sessione TLS dove avviene uno scambio di certificati è più complessa di questa (vedi che ho reso pubblico il capture dei dati se non ti fidi), in questa sessione avviene unicamente uno scambio di chiavi DH e viene negoziata la cifratura TLS_AES_128_GCM_SHA256
Questo non garantisce all'applet di sapere se sta veramente parlando con test.eolo.it, si deve fidare della chiave che questi gli manda perché non c'è scambio di certificati.
Poi se a livello applicativo avvengano ulteriori controlli questo non lo possiamo sapere salvo fare una retroingegneria del protocollo, ma a quanto pare è a sorgenti aperti, serve qualcuno che sappia leggere del Java e ne abbia voglia.
