I am brand new to WebRTC and am trying to wrap my head around what the STUN protocol exactly does and the risks of data leakage on an unencrypted transmission.

From my understanding, the STUN protocol helps programs sitting behind NATs find each other. Once they have found each other, then these programs communicate via UDP.

Does the STUN protocol simply act as a "matching service" and then some other protocol goes over the provided UDP? If the STUN isn't encrypted, does that mean any protocol communicating through the UDP also won't be encrypted? Would it be the responsibility of the protocol to provide encryption? (if so desired)


1 Answer 1


STUN is designed to discover client's Public IP Address if the client is sitting behind NAT.

From 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.

It means that your connection with the STUN server may or may not be always encrypted. It depends on the type of application.

Once the client has discovered its public IP and behind what type of NAT it is sitting at, the connection with the STUN server is terminated to save network resources. STUN uses 2 IP Address.

How STUN works

How do peers communicate then?
The work of STUN is over and now it's time to start a session between peerA and peerB. For P2P communication, Session Initiation Protocol (SIP) like VoIP & Session Description Protocol (SDP) are used.

If the STUN isn't encrypted, does that mean any protocol communicating through the UDP also won't be encrypted?

No. It doesn't depend on whether or not have you used secured channel for communicating with STUN. The session between both the peers will be end-to-end encrypted regardless your secured/unsecured connection with STUN. It is the responsibility of P2P service provider to ensure encrypted & secured channel for your P2P session.

If your connection with STUN is not private then the only information that can be captured is your public&private IP, external and internal ports and the type of NAT you are using.

  • Thank you for the detailed answer! This cleared up a lot of confusion.
    – Dave
    Commented Oct 14, 2016 at 14:13
  • And for unencrypted TURN server, the risk is the same or there are other things?
    – baptx
    Commented Mar 4, 2021 at 22:50
  • @baptx TURN only relays VoIP traffic. If your VoIP packets are not encrypted, they can be viewed.
    – defalt
    Commented Mar 5, 2021 at 7:11
  • @defalt I meant with WebRTC, it is encrypted by default so I guess the only leak with unencrypted TURN is the public / private IP address of the other peer, like STUN.
    – baptx
    Commented Mar 5, 2021 at 15:02
  • @baptx TURN is not used for public IP Address discovery. It only acts as a relay for P2P traffic for clients behind Symmetric NAT.
    – defalt
    Commented Mar 5, 2021 at 16:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .