Port 4443 – HTTPS Alt (Hypertext Transfer Protocol Secure Alternate)

Port 4443 is a common alternate HTTPS port — a TLS-encrypted web service running on a non-standard port instead of the default 443. IANA registers 4443 to Pharos (print management), but in the wild it’s overwhelmingly used as a second HTTPS listener, most often for a security-appliance or device management web UI. Sophos Firewall’s User Portal, along with countless firewall, UTM, NAS, load-balancer, and IoT admin consoles, put their HTTPS panel on 4443 to keep 443 free for a proxied application. Because everything on 4443 is HTTPS, the port carries the exact same TLS-layer attack surface as 443 — the difference is what’s usually behind it: an internet-facing management interface rather than a public website. On an open 4443 the job is to identify the product first, then assess it like any other HTTPS/web endpoint.

Why It’s Open

Administrators move HTTPS to 4443 when 443 is already taken or reserved. The classic pattern is an appliance that reverse-proxies a customer-facing app on 443 and exposes its own admin or user portal on 4443 — Sophos Firewall’s User Portal defaults to exactly this. You’ll also find it fronting management consoles for firewalls and UTMs, NAS boxes, load balancers and reverse proxies, hypervisors, and IoT/embedded gear; Kubernetes and other cluster components expose metrics and API endpoints there; and developers pick 4443 (four before 443) as a memorable alt-HTTPS port that avoids conflicts. The same alternate-HTTPS role is shared by port 8443, and the plaintext siblings port 80 and port 8080 often sit nearby. The takeaway: an open 4443 is an HTTPS service on a non-standard port — and non-standard HTTPS ports disproportionately host management interfaces.

Common Risks

Port 4443 is just HTTPS on a different number, so its risks are the risks of whatever answers there — and that’s usually a management panel:

• Exposed management interface. The single biggest risk: 4443 is frequently an appliance admin or user portal reachable from the internet. Management UIs are top targets, and one that shouldn’t face the internet at all often does.
• Appliance-specific vulnerabilities. The CVEs that matter are the ones in whatever product answers on 4443 — auth bypasses, SQL injection, and RCE in firewall/UTM/NAS panels (see Sophos below), not a generic “port 4443” bug.
• Weak or default credentials. Device and appliance panels ship with vendor defaults (admin:admin, product-specific pairs) and rarely enforce MFA, so an exposed login is brute-forceable.
• The same TLS weaknesses as 443. Deprecated protocols (SSLv3, TLS 1.0/1.1), weak ciphers (RC4, 3DES), expired or self-signed certificates, and library bugs like Heartbleed all apply here exactly as they do on port 443 — and appliances are especially prone to shipping self-signed certs and old TLS stacks.
• Information disclosure. TLS certificates, HTTP headers, error pages, and login banners on 4443 readily reveal the product and version, handing an attacker the exact appliance and firmware to look up CVEs for.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Because 4443 has no single fixed service, testing starts with one question: what product is this? Fingerprint the app, grade the TLS, then assess whatever you find like any HTTPS endpoint.

Confirm the service and grab the certificate

nmap -sV -p 4443 --script ssl-cert,http-title <target>

The TLS certificate’s CN/SAN and issuer, plus the HTTP title, are usually enough to name the appliance — a Sophos, pfSense, or vendor-specific cert is a giveaway.

Pull headers and the page by hand

curl -kI https://<target>:4443/
curl -k https://<target>:4443/ | head

-k skips certificate validation, since appliances are usually self-signed. Server headers, redirects, and login-page markup fingerprint the product; a favicon hash (compared against a favicon database) often nails the exact vendor.

Grade the TLS layer (same as port 443)

sslscan <target>:4443
testssl.sh https://<target>:4443

Then test the web app behind the TLS

Once you know the product, point web tooling at it and assess the management interface itself — auth, session handling, and known-CVE checks for that appliance.

nikto -h https://<target>:4443
# Or drive it through Burp Suite / OWASP ZAP

Log the product, version, and every weak protocol or certificate you confirm so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no generic “port 4443” vulnerability — 4443 is just a transport for HTTPS, so the CVEs that matter are the ones in the specific product whose admin or user portal answers there. Because Sophos Firewall’s User Portal defaults to 4443, its critical portal bugs are the clearest example of what an exposed 4443 can mean; both entries below are NVD-verified. For the TLS-layer CVEs (Heartbleed, POODLE, DROWN, Sweet32) that apply to any HTTPS port, see the port 443 page.

• CVE-2020-12271 — Sophos XG Firewall (Asnarök). A pre-auth SQL injection in the Administration (HTTPS) service and User Portal, reachable when either is exposed on the WAN zone, that led to remote code execution and exfiltration of local usernames and hashed passwords. Exploited in the wild in April 2020. CVSS 9.8 (CWE-89); listed in CISA’s Known Exploited Vulnerabilities catalog.
• CVE-2022-1040 — Sophos Firewall User Portal / Webadmin. An authentication bypass in the User Portal and Webadmin lets an unauthenticated remote attacker execute code on Sophos Firewall v18.5 MR3 and older. CVSS 9.8 (CWE-287); CISA KEV-listed, with a public exploit available.

The pattern is the point: neither bug is about the number 4443. Both are appliance-management flaws that happened to be internet-reachable because the portal was on 4443 and exposed. Identify the product on 4443 and check that product’s advisories.

Mitigation

• Never expose appliance/admin UIs to the internet. Restrict 4443 management portals to a management VLAN or VPN; the Sophos Asnarök and auth-bypass incidents both hinged on the portal being reachable from the WAN.
• Patch the appliance. The real risk on 4443 is the product’s own CVEs — keep firewall/UTM/NAS/hypervisor firmware current and watch the vendor’s advisories.
• Strong, unique credentials + MFA. Replace vendor defaults and require multi-factor authentication on every management interface.
• Harden the TLS exactly as on 443. Serve TLS 1.2/1.3 only, cut RC4/3DES and export ciphers, and install a valid CA-signed certificate instead of the shipped self-signed one — see port 443 for the full TLS checklist.
• Disable unused admin services and lock down the rest. If a management portal doesn’t need to be on 4443 (or at all), turn it off; if it does, restrict it to known source IPs.
• Identify what’s actually listening. You can’t secure 4443 until you know which product owns it — fingerprint it, then apply that vendor’s hardening guide.

Real-World Example

In April 2020, attackers exploited a then-unknown SQL-injection flaw (CVE-2020-12271) in Sophos XG Firewalls whose Administration or User Portal — the latter defaulting to port 4443 — was exposed on the WAN. The campaign, dubbed Asnarök, chained the injection into remote code execution, dropped malware on the device, and exfiltrated local usernames and hashed passwords before Sophos pushed an emergency hotfix. It’s the definitive port-4443 lesson: the vulnerability had nothing to do with the port number and everything to do with a management/user portal being reachable from the internet. An HTTPS admin panel on a non-standard port is still an admin panel — the alternate port buys no security, and exposing it is the whole risk.

FAQ

What is port 4443 used for?

Port 4443 is a common alternate HTTPS port — a TLS-encrypted web service on a non-standard port instead of 443. IANA registers it to Pharos print management, but in practice it most often hosts a security-appliance or device management web UI (for example, Sophos Firewall’s User Portal) or a second HTTPS service sitting behind a proxy.

Is port 4443 secure?

Port 4443 is HTTPS, so traffic is encrypted — but “encrypted” isn’t “secure.” It commonly exposes an appliance’s management interface, which can run weak or default credentials, an unpatched product with its own CVEs, or a broken TLS config (old protocols, self-signed certs). Those are the same risks as port 443, plus a higher chance that what’s behind it is an admin panel.

What is the difference between port 443 and port 4443?

Port 443 is the standard, default HTTPS port that public websites answer on; port 4443 is an alternate HTTPS port used when 443 is taken or reserved — most often for an appliance or device admin/user portal. Both carry HTTPS with the identical TLS attack surface; 4443 is just far more likely to front a management interface.

How do I find out what service is running on port 4443?

Fingerprint it: nmap -sV -p 4443 --script ssl-cert,http-title <target> reads the TLS certificate and page title, and curl -kI https://<target>:4443/ shows server headers and redirects. The certificate’s issuer/CN, HTTP headers, and login-page markup usually identify the exact appliance (Sophos, pfSense, VMware, and so on).

Is port 4443 TCP or UDP?

Alternate HTTPS on 4443 runs over TCP, like standard HTTPS. Enumeration and TLS testing target TCP 4443.

TL;DR

• Service: alternate HTTPS — HTTP over TLS on a non-standard port, most often an appliance/device management web UI
• Default use: 4443/TCP (IANA-registered to Pharos; widely reused as alt-HTTPS)
• Biggest risk: an internet-exposed management/admin portal on an unpatched appliance, plus the same TLS weaknesses as port 443
• Mitigation: keep management UIs off the internet (VPN/mgmt VLAN), patch the appliance, strong creds + MFA, valid cert + TLS 1.2/1.3, and identify the exact product before hardening