8

On Linux, Firefox is listening on UDP port, usually on ports 30000 and higher. What is the reason for this and why not just localhost, but 0.0.0.0, i.e. the interface exposed to the network as well?

1 Answer 1

12

UDP is not connection-based, so both ends have to be listening for two-way communication. Thus if Firefox wants to receive any responses from UDP services it is talking to, it needs to have open ports bound to a routable interface.

Since Firefox 88, HTTP/3 has been enabled by default, using UDP for web browsing with servers that support it. DNS lookups may involve remote UDP requests from Firefox (but not usually on Linux systems). Many P2P systems like WebRTC also use UDP.

13
  • 2
    and this can be tested by running ss -aunp | grep -i firefox while browsing this URL: http3check.net . The browser has to enable HTTP/3.
    – A.B
    Commented Feb 19 at 12:40
  • 5
    @CigaretteSmokingMan Note that whether or not you consider Firefox to have "open listening ports" is just a matter of semantics. With ordinary TCP connections, Firefox still has to listen for replies on the source port, but this does not appear in netstat/ss as it is implicit in the connection-based nature of the protocol. HTTP/3 basically performs a similar bidirectional packet conversation, but the listening source port happens to show up in netstat/ss because that's the convention for UDP (it would be hard to hide it).
    – TooTea
    Commented Feb 19 at 20:45
  • 4
    Note that technically, HTTP/3 does not use UDP, it uses QUIC. QUIC is a Layer 3 protocol just like UDP or TCP. Rightfully, it should be implemented as an L3 protocol on top of IP, but for reasons of backwards-compatibility with existing firewalls, home routers, NAT boxes, and other middle boxes, it was decided to implement QUIC on top of UDP. So, it is a Layer protocol implemented on top of another Layer 3 protocol, so to speak. But the open UDP ports are really a technicality, functionally, HTTP/3 uses QUIC, not UDP. Commented Feb 19 at 22:54
  • 2
    @CigaretteSmokingMan That's the same thing. Anyone can spoof a "reply" packet with the right addresses and ports for an existing TCP connection, just like they can send a "reply" UDP packet to a "listening" port. It is up to the receiver to discard any such spoofed packets, and that's one of the main tasks done by the TCP or QUIC stack, respectively. Unless there are critical security bugs in those stacks, it should be quite hard to successfully get a spoofed reply all the way to the application layer. Whether or not you see a "listening" port in ss has very little effect on that.
    – TooTea
    Commented Feb 20 at 10:36
  • 2
    @CigaretteSmokingMan FWIW, QUIC replies are much harder to spoof than TCP replies. The former cryptographically authenticates all packets, so it should be nearly impossible to forge a reply. The latter relies purely on the addresses&ports plus a 32-bit sequence number to validate if a reply should be accepted as part of a connection. So in the absence of TLS, it is quite easy for a man-in-the-middle to inject a reply into an HTTP connection. So on average, seeing a listening UDP port is a sign of better security than running over TCP.
    – TooTea
    Commented Feb 20 at 10:47

You must log in to answer this question.

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