HTTPS Default Port: SSL/TCP Port Number Guide
HTTPS (Hypertext Transfer Protocol Secure) uses port 443 as its default port for SSL/TLS connections. This secure protocol encrypts data between web browsers and servers. Common TCP ports include port 80 for HTTP, port 21 for FTP, port 22 for SSH, port 25 for SMTP, and port 53 for DNS. Port 443 provides secure communication by creating an encrypted tunnel for data transfer. Web browsers show a padlock icon when connecting through HTTPS, indicating a secure connection. Network administrators and developers need to know these port numbers for proper server configuration and security implementation.
Default Port for HTTPS
The default port for HTTPS communication is TCP port 443. If you do not specify a port in an HTTPS URL, it will automatically connect to the server on port 443 to establish a secure SSL/TLS connection.
For example:
https://www.example.com
Will connect to:
https://www.example.com:443
Here, port 443 is implied.
This default TCP port 443 for HTTPS was officially assigned by the Internet Assigned Numbers Authority (IANA) for this purpose. However, HTTPS can use other ports if required by specifying the port number in the URL.
Using the standard port 443 for HTTPS connections provides the following benefits:
- It optimizes network infrastructure, as this port is open by default on all major servers and firewalls for HTTPS traffic.
- Web clients like browsers automatically look for HTTPS certificates on port 443 to validate secure connections.
- It prevents collisions with other application protocols using other standard ports by default.
- Administrators can easily identify HTTPS traffic based on port 443 for monitoring bandwidth usage, security, etc.
- The port number does not have to be remembered or included in URLs for HTTPS sites using the default.
However, some web servers may choose to implement HTTPS on non-standard ports for specific reasons, such as running HTTP and HTTPS on the same IP address. In that case, the port number needs to be explicitly specified, like https://www.example.com:8443.
Common TCP Ports Used by HTTPS
While HTTPS uses port 443 by default, it can also be implemented on other TCP ports based on the requirements. Some commonly used non-standard ports for HTTPS include:
- Port 8443
- Port 1443
- Port 4443
- Port 9443
- Ports in Range 10000-20000
- Non-Standard Ports < 1024
- Port 443 with Different Protocols
Port 8443: Used by web servers running both HTTP and HTTPS on the same IP address. HTTP uses standard port 80, and HTTPS can run on 8443 to avoid conflicts. Some examples are Apache Tomcat’s default SSL connector and Oracle WebLogic’s default SSL port.
Port 1443: Used by Microsoft Internet Information Services (IIS) on Windows when both HTTP and HTTPS need to co-exist on one server. IIS runs HTTP on 80 and HTTPS on 1443.
Port 4443: Used by Oracle Demantra web servers for HTTPS connections by default instead of the standard 443 port.
Port 9443: Some applications, such as Atlassian Crowd and Apache OFBiz, use this port instead of 443 for HTTPS communication.
Ports in Range 10000-20000: Corporate firewalls sometimes block default ports like 443 for security purposes. In that case, HTTPS can run on any random higher port in this range.
Non-Standard Ports < 1024: Though not common, HTTPS can use a privileged port below 1024 if the web server is running with root privileges. However, regular HTTP cannot run on privileged ports.
Port 443 with Different Protocols: In very rare cases, port 443 may be used but with non-HTTPS protocols for specific reasons. For example, SOCKS5 proxies can listen on port 443.
How HTTPS Uses TLS/SSL for Secure Connections
HTTPS is built on top of HTTP and converts unsecured HTTP communication into encrypted HTTPS traffic using TLS/SSL protocols. Here is how a typical HTTPS connection works
- The client browser requests an HTTPS page like https://sslinsights.com/.
- The client and server perform a TLS handshake to establish a secure encrypted session:
- The server presents its SSL certificate containing its public key and domain name.
- The client’s browser verifies the certificate is valid, issued by a trusted Certificate Authority and matches the website domain.
- The client and server negotiate a cipher suite to determine the encryption algorithms to use.
- The client and server generate session keys used to encrypt the data flow in both directions.
- The client and server communicate securely using symmetric encryption with the session keys negotiated in the TLS handshake.
- When the session ends, the connection is terminated, and session keys are discarded. New keys are generated for every session.
Some key points regarding how HTTPS establishes secure communication using SSL/TLS:
- HTTPS is not a protocol itself but rather HTTP over an encrypted SSL or TLS connection.
- TLS uses asymmetric encryption to exchange keys and authenticate the server, followed by symmetric encryption for the session data transfer.
- Encryption prevents eavesdropping. Integrity checks prevent tampering of messages.
- In the initial handshake, the client and server mutually authenticate each other and negotiate encryption parameters before any HTTP data is exchanged.
- Public key infrastructure (PKI) with digital certificates provides authentication of websites.
- Regular HTTPS re-keying and changing session keys periodically enhances security.
SSL vs TLS: What is the Difference?
HTTPS was traditionally implemented with the Secure Sockets Layer (SSL) protocol, which Netscape created in the mid-1990s. However, modern websites use the more secure Transport Layer Security (TLS) protocol for HTTPS connections.
SSL stands for Secure Sockets Layer. It was originally developed by Netscape to secure transactions between their web browsers and web servers. The first version, SSL 1.0, was never publicly released because it had security flaws. SSL 2.0 and 3.0 were released in 1995 and 1996, respectively.
TLS stands for Transport Layer Security. It is the successor to SSL developed by the Internet Engineering Task Force (IETF), which took over the responsibility from Netscape. TLS 1.0 was first defined in 1999 based on SSL 3.0 and had incremental improvements with TLS 1.1 and 1.2.
Here is a comparison between SSL and TLS protocols:
| SSL | TLS |
|---|---|
| Introduced by Netscape in 1995 | Standardized by IETF in 1999 based on SSL 3.0 |
| SSL 1.0 to SSL 3.0 versions | TLS 1.0 to 1.3 (ongoing development) |
| Used proprietary implementation | Open-source protocol implementations |
| Vulnerable to attacks like BEAST, CRIME | Fixes vulnerabilities present in SSL |
| Linked to RSA encryption | Not limited to a particular encryption algorithm |
| Supports MD5 and SHA-1 hashes | Uses stronger hash functions like SHA-256 |
| No support for encryption modes like AES, key lengths >256-bit | Supports improved encryption like AES, etc. |
| Handshake exposes key information | Renegotiation vulnerability fixed in TLS handshake |
How Browsers Validate HTTPS Connections
For secure HTTPS connections, web browsers need to validate the server’s digital certificate and confirm the website’s identity before communicating any sensitive data. Browsers use the following process to authenticate HTTPS connections:
- When attempting to connect to a HTTPS website, the browser receives the server’s digital certificate as part of the initial TLS handshake.
- The browser checks whether the certificate is correctly signed by a trusted third-party Certificate Authority (CA) like Comodo, DigiCert, etc. The CA’s public key is pre-installed in the browser.
- It verifies the domain name in the certificate matches the website the user is trying to access. This ensures there is no man-in-the-middle (MITM) attack.
- The browser checks the certificate validity period to confirm it has not expired.
- Certificate revocation lists maintained by the CAs are checked to confirm that the certificate has not been revoked.
- The certification path is validated to ensure the chain of trust back to the root CA certificate.
- Advanced browsers also check for Certificate Transparency logs, key usage flags, extended validation details, etc.
- If any verification fails, the browser displays certificate error messages and prevents access to the HTTPS site to protect the user.
- Warnings may also be shown for invalid certificates, mismatched domain names, or other irregularities that do not necessarily prevent access.
- Only after successful validation is complete will the browser trust the website’s identity and proceed with setting up an encrypted HTTPS connection.
The validation process depends on the Certificate Authority ecosystem and ensures browsers only communicate securely with authentic websites.
Final Thoughts
The HTTPS protocol is critical for securing sensitive data transmitted over the Internet. By encrypting HTTP traffic using SSL/TLS and providing identity verification through certificates, HTTPS enables secure ecommerce transactions, banking activities, and the transfer of private information online.
Although HTTPS comes with some drawbacks like increased complexity, when used properly, it protects user data from interception and tampering. As threats to security and privacy grow, websites handling user logins, financial data, or personal info should mandate HTTPS. With performance optimizations in recent versions, HTTPS delivers security with minimal impact on speed and user experience.
Frequently Asked Questions
What is the main difference between HTTP and HTTPS protocols?
The main difference is that HTTPS uses TLS/SSL encryption to secure HTTP communication, while HTTP sends data in plain text without encryption. HTTPS keeps data secured from network attacks.
Is HTTPS used only for login pages?
No, HTTPS should be used across the entire website, not just login pages, to prevent the snooping of user data. Google also ranks HTTPS sites higher.
Is HTTPS slower than HTTP?
In the past, HTTPS was slower due to encryption overhead. However, modern optimizations like HTTP/2 multiplexing and TLS 1.3 make HTTPS performance almost as fast as HTTP in most cases.
What encryption algorithms are used in HTTPS?
Some common encryption algorithms used for TLS/SSL connections include AES, ECC, RSA, etc. During the handshake, the server and browser negotiate the strongest mutually supported cipher.
Can you have HTTP and HTTPS on the same website?
Yes, you can have both HTTP and HTTPS running on the same website on different ports like HTTP on 80 and HTTPS on 443. The browser will upgrade HTTP links to HTTPS automatically.
Is HTTPS important for all websites?
HTTPS is recommended for all websites handling user logins, payment transactions, personal data, etc., to protect against network sniffing attacks. However, static sites may not need HTTPS.
What is forward secrecy in HTTPS?
Forward secrecy uses keys that cannot be derived from long-term server private keys. This ensures past encrypted data cannot be decrypted even if long-term keys are compromised in the future.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
