Port 5061 – SIP-TLS (Secure SIP)

Port 5061 is the default port for SIP over TLS (Secure SIP) — the encrypted version of SIP signaling. It carries the same REGISTER, INVITE, and BYE call-control messages as plain SIP on port 5060, but wraps them in a TLS session so the signaling can’t be read or tampered with on the wire. IP-PBXs like Asterisk, FreePBX, Kamailio, and 3CX, and platforms like Microsoft Teams / Skype for Business, use 5061 to protect call setup, registration, and the SIP digest-auth exchange; the audio and video media are encrypted separately with SRTP. In short, 5061 is what 5060 should be — so the questions on this port are “is TLS actually configured correctly?” and “what still needs protecting once the transport is encrypted?”

Why It’s Open

Any VoIP deployment that takes security seriously terminates SIP over TLS on port 5061. You’ll find it on the same IP-PBXs and SBCs that run plain SIP — Asterisk, FreePBX, FreeSWITCH, Kamailio, and 3CX — plus enterprise unified-comms platforms such as Microsoft Teams / Skype for Business and hosted cloud PBXs, and on SIP trunks to carriers that support TLS. Desk phones, softphones, and ATAs register to it, and remote workers connect to it across the internet precisely because it encrypts the session.

5061 is the encrypted sibling of plain SIP on port 5060: where 5060 sends everything in cleartext, 5061 negotiates TLS first and only then speaks SIP. It follows the same “secure variant on a dedicated port” pattern as HTTPS on 443 and LDAPS on 636. Where 5061 is open, plain 5060 is very often still listening too — check both, because an attacker who can force a fallback to 5060 gets the cleartext channel back.

Common Risks

Using TLS defeats the passive sniffing and extension enumeration that plague cleartext 5060 — an attacker on the path can no longer read the signaling or lift the digest-auth challenge. The residual risks are mostly about how well the TLS is configured, plus everything that TLS was never meant to protect:

• Weak or misconfigured TLS. A listener that still allows SSLv3, TLS 1.0/1.1, or weak CBC/3DES ciphers can be downgraded or attacked (POODLE, BEAST, Sweet32), undermining the encryption you deployed 5061 for.
• Certificate problems and MITM. Expired, self-signed, or wrong-hostname certificates — and endpoints that don’t validate the server certificate — let a man-in-the-middle terminate the TLS, read the signaling, and relay it on. Encryption without verified certificates is theater.
• No client-certificate / weak endpoint validation. If the server accepts any client into the TLS tunnel and doesn’t require mutual TLS, an attacker simply connects, and every 5060-style attack (enumeration, registration, brute force) resumes inside the encrypted channel.
• Same PBX auth and toll fraud once inside. TLS protects the transport, not the password. Weak or default per-extension secrets still allow registration hijacking and toll fraud after the tunnel is up — the 5060 page covers this exposure in depth.
• TLS-library and PBX parser bugs. A flaw in the underlying TLS library (Heartbleed) or in the SIP parser sitting behind the TLS listener (Kamailio/Asterisk CVEs below) is reachable over 5061 regardless of encryption.
• TLS-handshake DoS. TLS handshakes are more expensive than plain UDP, so a flood of half-open handshakes can exhaust the PBX and drop live calls.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The goal on 5061 is different from 5060: you’re inspecting the TLS layer — is it there, is the certificate valid, are the protocol and ciphers strong — because the SIP layer behind it is hidden until you complete a TLS handshake.

Detect the service and version

nmap -sV -p 5061 <target>

Complete the TLS handshake and read the certificate

openssl s_client -connect <target>:5061

The certificate’s Common Name / SAN, issuer, and validity almost always reveal the PBX or platform (for example an Asterisk/FreePBX hostname or a Microsoft edge FQDN) — cross-reference it against the CVEs on the matching product. This is also where you spot self-signed or expired certificates.

Enumerate TLS versions and ciphers

nmap --script ssl-cert,ssl-enum-ciphers -p 5061 <target>

ssl-enum-ciphers grades every protocol and cipher the listener accepts — a quick way to flag SSLv3 / TLS 1.0 / 1.1 or weak suites.

Reaching the SIP layer through TLS

The SIP enumeration that works on cleartext 5060 — nmap --script sip-methods,sip-enum-users, SIPVicious (sipvicious_svwar), and raw sipsak — generally can’t reach the SIP layer through TLS: that’s the whole point of 5061. To speak SIP over TLS you need a TLS-capable SIP client such as sipexer (or a softphone configured for TLS). If the server doesn’t require or validate a client certificate, you can open the tunnel and then run the same enumeration and registration tests as on 5060 — so always test whether the endpoint enforces mutual TLS.

Log every weak cipher, bad certificate, and any SIP account you can register inside the tunnel so it lands in the final pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

Because 5061 is a TLS listener speaking SIP, its relevant CVEs come from two places: the TLS library/stack, and the SIP parser sitting behind it. This is the TLS/secure-signaling angle — for the broader set of SIP authentication and toll-fraud CVEs, see the port 5060 page.

• CVE-2014-0160 — Heartbleed. The OpenSSL 1.0.1–1.0.1f TLS/DTLS heartbeat over-read lets a remote attacker read up to 64 KB of process memory per request from any TLS listener — including a SIP-TLS service on 5061 built against the vulnerable OpenSSL. That memory can contain the server’s private key and in-flight SIP credentials, defeating the entire purpose of encrypting 5061. CVSS 7.5. The textbook case of a TLS-library flaw undermining Secure SIP.
• CVE-2014-3566 — POODLE. SSL 3.0’s nondeterministic CBC padding allows a man-in-the-middle to recover cleartext via a padding-oracle attack after forcing a downgrade to SSLv3. A SIP-TLS listener that still permits SSLv3 fallback is exposed — this is the concrete reason to disable SSLv3 and legacy TLS on 5061. CVSS 3.4 (MITM, on-path).
• CVE-2026-39863 — Kamailio core out-of-bounds read in TCP data processing. A specially crafted packet crashes the process (DoS), and the advisory explicitly notes it impacts Kamailio instances with TCP or TLS listeners — so a 5061 SIP-TLS front end is directly in scope. Unauthenticated, remote. Fixed in 6.1.1 / 6.0.6 / 5.8.8. CVSS 7.5.
• CVE-2020-27507 — Kamailio before 5.5.0 mishandles INVITE requests with duplicated fields and an overlength tag, causing a buffer overflow that crashes the server (and potentially worse). It illustrates the key point: TLS encrypts the pipe, but the SIP parser behind the TLS listener is still exposed once a client connects — encryption is not a substitute for patching. CVSS 9.8.
• CVE-2023-49786 — Asterisk DoS via a race condition in the DTLS hello-handshake when negotiating DTLS-SRTP for media. This is the secure-media companion to SIP-TLS: sent continuously, it blocks all new encrypted calls. Fixed in 18.20.1 / 20.5.1 / 21.0.1 / 18.9-cert6. CVSS 5.9 (NIST) / 7.5 (CNA).

Mitigation

• Use SIP-TLS (5061) with SRTP instead of plaintext 5060. This is the core recommendation: encrypt signaling on 5061 and media with SRTP so credentials and calls can’t be sniffed or replayed. Once TLS is live, disable or tightly restrict plain 5060 so no one can force a downgrade.
• Use valid CA-signed certificates and enforce TLS 1.2+ with strong ciphers. Retire SSLv3 and TLS 1.0/1.1, drop weak CBC/3DES suites, and monitor certificate expiry. A correct certificate is what makes the encryption trustworthy.
• Enforce certificate validation to prevent MITM. Configure endpoints to verify the server certificate (in Asterisk PJSIP, verify_server=yes), and require client certificates / mutual TLS where the platform supports it so an attacker can’t simply open the tunnel.
• Set strong, unique per-extension secrets and use fail2ban. TLS doesn’t fix weak passwords — the same authentication hardening the 5060 page describes still applies inside the tunnel to stop registration hijacking and toll fraud.
• Put the PBX behind an SBC or firewall and don’t expose it to the whole internet. Restrict 5061 to your carrier’s TLS trunk IPs and known endpoints, and rate-limit handshakes to blunt TLS-handshake floods.
• Patch the PBX and its TLS library. Keep Asterisk, Kamailio, FreeSWITCH, and the underlying OpenSSL current — the Heartbleed and Kamailio bugs above are all fixed in newer releases.

Real-World Example

The most common failure on port 5061 isn’t a broken cipher — it’s the false confidence that “we moved to TLS, so we’re secure.” A team migrates SIP to 5061, sees the padlock of an encrypted session, and leaves the rest of the deployment exactly as it was: extension secrets set to the extension number, no client-certificate requirement, and plain 5060 still listening as a fallback. An attacker who reaches the service opens the TLS tunnel (which the server hands out to anyone, because mutual TLS isn’t enforced), and inside that encrypted channel runs the very same SIPVicious-style extension enumeration and brute force that works on 5060 — then registers a weak extension and routes premium-rate international calls, the International Revenue Share Fraud pattern that runs up huge bills overnight. TLS protected the wire; it did nothing for the weak password behind it.

The other classic case is the library flaw: when Heartbleed dropped in 2014, every Asterisk and Kamailio instance built against vulnerable OpenSSL and listening on 5061 could have its private key and in-memory SIP credentials read remotely — a single unauthenticated request quietly defeating the encryption. Both stories point the same way: 5061 is a genuine improvement over cleartext 5060, but only when the certificates, cipher suite, endpoint validation, and extension passwords are all done right.

FAQ

What is port 5061 used for?

Port 5061 is the default port for SIP over TLS (SIP-TLS), the encrypted version of SIP call signaling. It carries the same REGISTER, INVITE, and BYE messages as plain SIP on 5060 but inside a TLS session, so call setup, registration, and the digest-auth exchange can’t be read or altered on the wire. The audio and video are encrypted separately with SRTP.

What is the difference between port 5060 and 5061?

Port 5060 carries plain, unencrypted SIP — signaling and credentials travel in cleartext and can be sniffed or enumerated. Port 5061 carries SIP over TLS: the session is encrypted first, which defeats passive sniffing and extension enumeration. For any SIP exposed beyond a trusted network, 5061 with TLS — paired with SRTP for the media — is the secure choice.

Is port 5061 secure?

It’s much safer than cleartext 5060, but “encrypted” isn’t automatically “secure.” A 5061 listener is only as strong as its TLS configuration (modern protocol versions and ciphers), its certificates (valid, CA-signed, verified by endpoints), and the SIP authentication behind the tunnel. Weak certs, SSLv3 fallback, no client-certificate validation, or default extension passwords all leave it exploitable.

Does SIP-TLS use TCP or UDP?

TCP. TLS runs over a reliable stream, so SIP-TLS on 5061 uses TCP (unlike plain SIP on 5060, which is most often UDP). The related media encryption, DTLS-SRTP, uses DTLS over UDP on the separate RTP ports.

How do I secure port 5061?

Use CA-signed certificates, enforce TLS 1.2+ with strong ciphers (disable SSLv3/TLS 1.0/1.1), require endpoints to validate the server certificate and use mutual TLS where possible, set strong unique per-extension secrets with fail2ban, keep the PBX behind an SBC or firewall, disable or restrict plain 5060, and patch the PBX and its TLS library.

TL;DR

• Service: SIP over TLS (Secure SIP) — encrypted VoIP call signaling
• Default port: 5061/TCP (the encrypted counterpart to plain SIP on 5060; media is protected separately by SRTP)
• Biggest risk: weak TLS config, bad/unverified certificates and MITM, no client-cert validation, and the same weak-password toll fraud once inside the tunnel
• Mitigation: prefer 5061 + SRTP over cleartext 5060, valid CA certs + TLS 1.2+ with strong ciphers, enforce certificate validation, strong per-extension secrets + fail2ban, SBC/firewall, and patch the PBX and TLS library