STUN è progettato per scoprire l'indirizzo IP pubblico del client se il client si trova dietro NAT.
Da wikipedia:
STUN messages are usually sent in User Datagram Protocol (UDP) packets. Since UDP does not provide reliable transport guarantees, reliability is achieved by application-controlled retransmissions of the STUN requests. STUN servers do not implement any reliability mechanism for their responses. When reliability is mandatory, the Transmission Control Protocol (TCP) may be used, but induces extra networking overhead. In security-sensitive applications, STUN may be transported and encrypted byTransport Layer Security (TLS). The standard listening port number for a STUN server is 3478 for UDP and TCP, and 5349 for TLS.
Significa che la tua connessione con il server STUN può essere o non essere sempre crittografata. Dipende dal tipo di applicazione.
Una volta che il client ha scoperto il suo IP pubblico e dietro quale tipo di NAT è seduto, la connessione con il server STUN viene interrotta per risparmiare risorse di rete. STUN utilizza 2 indirizzi IP.
Come comunicano i pari?
Il lavoro di STUN è finito e ora è il momento di iniziare una sessione tra peerA e peerB. Per la comunicazione P2P , protocollo Session Initiation (SIP) come VoIP & Vengono utilizzati i protocolli (SDP) della sessione.
If the STUN isn't encrypted, does that mean any protocol communicating through the UDP also won't be encrypted?
No. Non dipende dal fatto che tu abbia usato o meno un canale protetto per comunicare con STUN. La sessione tra entrambi i peer sarà end-to-end crittografata indipendentemente dalla connessione protetta / non protetta con STUN. È responsabilità del fornitore di servizi P2P garantire la crittografia e l'amp; canale protetto per la tua sessione P2P .
Se la tua connessione con STUN non è privata, le uniche informazioni che possono essere acquisite sono il tuo IP pubblico e privato, le porte esterne e interne e il tipo di NAT che stai utilizzando.