Port Authority Edition – Internet Vulnerability Profiling
by Steve Gibson,  Gibson Research Corporation.

Goto Port 442
Probe Port 443
Enter Port: 0-65535
Goto Port 444

Port Authority Database

Port 443


http protocol over TLS/SSL

This port is used for secure web browser communication. Data transferred across such connections are highly resistant to eavesdropping and interception. Moreover, the identity of the remotely connected server can be verified with significant confidence. Web servers offering to accept and establish secure connections listen on this port for connections from web browsers desiring strong communication security.

Once established, web browsers inform their users of these secured connections by displaying an icon — a padlock, an unbroken key, etc. — in the status region of their window.

Related Ports: 
80, 81, 82, 8080, 8090

Background and Additional Information:


Netscape designed the original SSL (Secure Sockets Layer) protocol to secure and authenticate Internet communications between cooperating clients and servers. After Microsoft's brief but failed attempt to overthrow SSL with their own STT (Secure Transaction Technology) as part of their "late to the party" introduction of Internet Explorer, SSL became the defacto industry standard for secure point-to-point Internet communications.

The "s" in "https" stands for "secure": Hyper Text Transfer Protocol, Secure. You may encounter other s-suffix protocols such as ftps or smtps. These, similarly, refer to secured-transport versions of the base protocol.

In the case of https, whereas the default port used for standard non-secured "http" is port 80, Netscape chose 443 to be the default port used by secure http. (They chose port 443 because it was not being used for any other purpose at the time.)

Observing SSL Certificates in Action:

SSL operates through the exchange of client and server credentials known as "security certificates". Security certificates are issued by trusted third parties, the largest of these being Verisign. All contemporary web browsers contain a collection of "certificates" issued by these third parties to enable their communication with remote servers which contain similar certificates issued by the same third parties.

The client certificates built into web browsers are "generic", long-lived (30 years or so), and identical among users (as is necessary for privacy). But web server certificates are short-lived (only a year or two) and must be individually purchased for each web site. Purchasers of web server certificates must perform a number of steps over a number of days to prove their authenticity and verify their identity. Thus there is some reasonable (through not absolute) credibility associated with holders of web server certificates.

The use of "Public Key Encryption" (PKE) allows each end of the secure connection to authenticate the validity of the other's certificate. (Note that although public key encryption is extremely cool, it is costly in computing effort and connection setup time. For this reason, SSL links are generally only used briefly while transaction security is required. After that, web connections are returned to standard, faster, non-secured http protocol.)

During a secure session, while the web page being displayed is showing its "secure" icon, the server's certificate and issuing details may be examined with the web browser to verify the identity and other details of the remote server. You may see this for yourself by switching this page into "secure mode" using this link:

Click the link below to view this page via SSL:


(Note the "https" in the link's URL and in your browser's Address display, rather than the usual "http".)

Remote Server Authentication

You will notice that your browser is now displaying its "security icon" to indicate that a secure page is being viewed. While this icon is present you may examine this page's properties, including the remote server's security certificate details. Right-click your mouse cursor on the page, then choose Properties, then Certificates.

When you are through, you may either press your browser's BACK button to return to the previous non-secure version of this page, which will be via standard non-SSL connection, or use this standard http link:


Is E-Commerce Safe and Secure?

There is no simple answer to the question "Is electronic commerce safe and secure?" However, if an "SSL Secured" connection was used to communicate the transaction's data — your name, credit card information, etc. — across the Internet, this secure communication is very likely to be the safest and most secure stage of any portion of a commercial transaction.

Many techniques, such as keystroke logging by resident Trojans, or spouse/employer-installed monitoring software, can be used to "capture" any data as it is being entered into your computer keyboard (thus before it is securely communicated). And once it has arrived at its destination, you inherently rely upon the staff and the security practices of the remote vendor for their continuing protection of your data's secrecy. Compared to these very real hazards, your data's brief and well-encrypted flight across the Internet is probably the most security it has ever enjoyed. (Certainly more than handing your credit card to an unknown attendant in a hotel, restaurant, or other retail establishment.) In other words, there is nothing about the technology of the Internet itself which makes eCommerce any less safe than any other sort of personal credit based commerce.

For information about non-secure web (http) connections, please see the Port Authority page for port 80.

For more information about the detailed operation of Netscape's SSL protocol . . .



The entire contents of this page is copyright © 2008 by Gibson Research Corporation.

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2020 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page