Port 443 – HTTPS (Secure Web Traffic)

Port 443 is the default port for HTTPS (HTTP over TLS/SSL), the encrypted version of the web. It carries the same web pages, API calls, and form data as plain HTTP on port 80, but wraps every byte in a TLS session, so anyone on the network path sees ciphertext instead of readable traffic. That encryption is why 443 is now the default for nearly every public site, login page, VPN portal, and API. For anyone testing a host it’s a double target: the TLS layer itself — protocols, ciphers, and certificates that can be deprecated, weak, or outright broken — and the web application behind it, which HTTPS protects in transit but does nothing to make secure.

Why It’s Open

Port 443 is one of the most commonly open ports on the internet because encrypted HTTP is now the baseline. Browsers warn on anything that isn’t HTTPS, search engines rank it, and HSTS preload lists force it, so every real site answers on 443. Beyond public web servers you’ll find it fronting REST and GraphQL APIs, single sign-on and OAuth endpoints, and — critically for a pentester — SSL-VPN and remote-access appliances (FortiGate, Cisco ASA/AnyConnect, Palo Alto GlobalProtect), mail and Exchange front-ends, and the management consoles of routers, firewalls, hypervisors, and IoT gear. The same TLS stack also shows up on alternate HTTPS ports like 8443, and the plaintext port 80 usually sits alongside it to 301-redirect visitors up to 443. Note that classic HTTPS is TCP; HTTP/3 negotiates the same service over QUIC on UDP 443.

Common Risks

The encryption on port 443 protects data in transit — it does not protect the server. Most 443 findings come from the TLS layer being misconfigured or the service behind it being unpatched:

• Deprecated protocols still enabled. SSLv2, SSLv3, and TLS 1.0/1.1 are broken but frequently left on for “compatibility.” They open the door to DROWN, POODLE, and BEAST, and fail PCI-DSS outright.
• Weak and export ciphers. RC4, DES/3DES, and export-grade key exchange enable Sweet32, FREAK, and Logjam. A cipher list that grades below A is a finding on its own.
• Implementation bugs in the TLS stack. Heartbleed (OpenSSL) and Ticketbleed (F5 BIG-IP) leak raw process memory — private keys, session tokens, and credentials — straight off the wire, with no login required.
• Certificate problems. Expired, self-signed, wrong-hostname, weak-key (RSA < 2048), or SHA-1-signed certificates break the authentication half of TLS and make man-in-the-middle interception realistic instead of theoretical.
• No HSTS / downgrade exposure. Without Strict-Transport-Security, an attacker on the path can SSL-strip the victim back down to cleartext HTTP on port 80 before the encrypted session ever starts.
• Encryption hides the payload. TLS terminates at 443, so the same web-app attack surface — SQL injection, XSS, SSRF, path traversal — rides inside the tunnel where a WAF or IDS inspecting cleartext can be blind to it. Those application-layer attacks are covered on the port 80 page; on 443 they arrive pre-encrypted.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Testing 443 splits in two: audit the TLS transport, then test the web app it wraps.

Confirm the service and grab the certificate

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

Enumerate protocols and cipher grades

ssl-enum-ciphers lists every accepted protocol and ciphersuite and grades each A–F — the fastest way to spot SSLv3, TLS 1.0, RC4, or 3DES.

sslscan <target>:443
testssl.sh https://<target>
sslyze <target>:443

Check for the named TLS bugs

nmap -p 443 --script ssl-heartbleed,ssl-poodle,ssl-dh-params <target>

Inspect the handshake and cert by hand

openssl s_client -connect <target>:443 -servername <target>
curl -vI https://<target>/

Metasploit — Heartbleed memory dump

msfconsole -q
use auxiliary/scanner/ssl/openssl_heartbleed
set RHOSTS <target>
set ACTION DUMP
run

Then test the web app behind the TLS

Once you’ve graded the transport, point the app-layer tooling at the same port — TLS is just the wrapper, and the web application is where most findings live.

nikto -h https://<target>
# Or drive it through Burp Suite / OWASP ZAP for auth, session, and injection testing

Log every weak protocol, failing cipher, and expired 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

Vulnerabilities on port 443 fall into two families: flaws in the TLS layer itself (protocol design, cipher, and implementation bugs) and flaws in the service listening behind it (SSL-VPNs, mail, and management appliances). Every entry below is NVD-verified.

TLS/SSL layer:

• CVE-2014-0160 — Heartbleed. A missing bounds check in the OpenSSL 1.0.1–1.0.1f heartbeat extension lets an unauthenticated attacker read up to 64KB of server process memory per request — private keys, session cookies, and credentials. CVSS 7.5 (CWE-125, out-of-bounds read). Ready-made as Metasploit’s auxiliary/scanner/ssl/openssl_heartbleed and Exploit-DB 32745; detect with nmap --script ssl-heartbleed.
• CVE-2014-3566 — POODLE. SSLv3’s nondeterministic CBC padding is a padding oracle: a man-in-the-middle who can force a downgrade to SSLv3 decrypts one byte of ciphertext at a time. CVSS 3.4 (CWE-310). A protocol-design flaw, not a bug — the fix is to disable SSLv3 entirely. Detect with nmap --script ssl-poodle.
• CVE-2016-0800 — DROWN. A cross-protocol attack: if a server (or any server sharing its RSA key) still speaks obsolete SSLv2, a Bleichenbacher oracle over SSLv2 decrypts modern TLS sessions. Affected OpenSSL before 1.0.1s / 1.0.2g. CVSS 5.9 (CWE-200). The reason SSLv2 must be off everywhere, not just on the main host.
• CVE-2016-9244 — Ticketbleed. F5 BIG-IP’s TLS session-ticket handling returns up to 31 bytes of uninitialized memory when Session Tickets are enabled — a vendor-specific Heartbleed analog that leaks session IDs and memory contents. Affects BIG-IP 11.6.1 before HF1 and 12.1.x before 12.1.2. CVSS 7.5 (CWE-200).
• CVE-2016-2183 — Sweet32. 64-bit block ciphers (3DES, Blowfish) hit a birthday bound after ~32GB of a long-lived HTTPS session, letting an attacker recover plaintext such as auth cookies. CVSS 7.5 (CWE-200). Flagged automatically by ssl-enum-ciphers grading 3DES down — the fix is to remove 3DES from the cipher list.

Services behind 443:

• CVE-2023-27997 — “XORtigate”. A heap-based buffer overflow in the FortiOS / FortiProxy SSL-VPN gives an unauthenticated attacker remote code execution via crafted requests to the HTTPS SSL-VPN portal. CVSS 9.8 (CWE-122 / CWE-787). A reminder that a perfectly configured TLS stack means nothing if the appliance terminating it is unpatched.
• CVE-2020-3452 — Cisco ASA / FTD WebVPN. A path-traversal flaw in the web services interface lets an unauthenticated attacker read arbitrary files from an ASA or Firepower device over 443. CVSS 7.5 (CWE-22). Public PoC as Exploit-DB 48871.

Mitigation

• Disable everything below TLS 1.2. Turn off SSLv2, SSLv3, TLS 1.0, and TLS 1.1; serve TLS 1.2 and 1.3 only. This alone closes POODLE, DROWN, BEAST, and most downgrade attacks.
• Cut weak ciphers. Remove RC4, DES/3DES, and export-grade suites; prefer forward-secret AEAD ciphers. Aim for an A grade in sslscan / testssl.sh.
• Patch the TLS stack and the appliance. Keep OpenSSL current (Heartbleed and Sweet32 are library bugs), and treat SSL-VPN, mail, and management portals on 443 as high-priority patch targets — that’s where the 9.8s live.
• Use valid certificates and rotate keys. Trusted-CA certs, RSA ≥ 2048 or ECDSA, SHA-256 signatures, correct hostnames — and reissue any key that was live during a Heartbleed-era exposure.
• Enforce HSTS. Send Strict-Transport-Security (ideally with preload) so browsers never make the cleartext hop, and 301-redirect port 80 to 443.
• Don’t trust the tunnel to hide the app. TLS encrypts transit; it doesn’t stop SQLi, XSS, or SSRF. Put a TLS-terminating WAF in front so the app layer is actually inspected, and harden the web application itself.

Real-World Example

In April 2014 the Heartbleed bug (CVE-2014-0160) turned port 443 — the port everyone trusted because it was encrypted — into a memory-disclosure faucet. A one-line missing bounds check in OpenSSL’s heartbeat extension let anyone send a small “keep-alive” request that claimed a large response, and vulnerable servers replied with up to 64KB of whatever happened to be in memory: session cookies, POSTed passwords, and — as Cloudflare’s public challenge proved within days — the server’s own TLS private key. Roughly half a million trusted HTTPS sites were exposed. The cleanup wasn’t just patching OpenSSL; every affected certificate had to be revoked and reissued because the private keys had to be assumed stolen. It’s the definitive example of the port-443 lesson: encryption protects data on the wire, but a flaw in the software terminating that encryption can hand an attacker the keys to all of it.

FAQ

What is port 443 used for?

Port 443 is the default port for HTTPS — HTTP wrapped in a TLS/SSL session. It carries encrypted web pages, API calls, login forms, and VPN traffic between a client and a server. When you visit a site with https://, the browser connects to port 443 and negotiates a TLS session before any web data moves.

Is port 443 secure?

Port 443 is far safer than plain HTTP because traffic is encrypted, but “HTTPS” is not automatically “secure.” A server on 443 can still run broken protocols (SSLv3, TLS 1.0), weak ciphers, or a vulnerable TLS library (Heartbleed), and the encryption does nothing to fix bugs in the web application behind it. Encrypted traffic can still carry an attack.

What is the difference between port 80 and port 443?

Port 80 carries plain HTTP; port 443 carries HTTPS — the same web content wrapped in TLS encryption and authenticated with a certificate. On 80 the traffic is readable and modifiable on the wire; on 443 it’s encrypted. Most sites keep 80 open only to redirect visitors up to 443.

Is port 443 TCP or UDP?

Standard HTTPS uses TCP 443. The newer HTTP/3 protocol runs the same service over QUIC on UDP 443, so a full scan of a modern host should check both. Enumeration and the classic TLS attacks focus on TCP 443.

How do I test port 443 for vulnerabilities?

Start with the TLS layer: sslscan, testssl.sh, or nmap --script ssl-enum-ciphers,ssl-cert,ssl-heartbleed,ssl-poodle -p 443 <target> to grade protocols, ciphers, and the certificate. Then test the web application behind it with Burp Suite, OWASP ZAP, or Nikto — TLS is only the wrapper.

TL;DR

• Service: HTTPS (HTTP over TLS/SSL) — encrypted web traffic
• Default port: 443/TCP (HTTP/3 uses QUIC on UDP 443)
• Biggest risk: broken TLS config (old protocols, weak ciphers, Heartbleed/Ticketbleed) plus unpatched services behind it — encryption hides the payload, it doesn’t secure the server
• Mitigation: TLS 1.2/1.3 only, strong ciphers, valid certs, patch the TLS stack and any SSL-VPN/appliance on 443, enforce HSTS, and still test the web app inside the tunnel