- The correct title of this article is https. The initial letter is shown capitalized due to technical restrictions.
https is a URI scheme which is syntactically identical to the http:// scheme normally used for accessing resources using HTTP. Using an https: URL indicates that HTTP is to be used, but with a different default port (443) and an additional encryption/authentication layer between HTTP and TCP. This system was designed by Netscape Communications Corporation to provide authentication and encrypted communication and is widely used on the World Wide Web for security-sensitive communication such as payment transactions and corporate logons.
|
Contents
- 1 How it works
- 2 Limitations
- 3 See also
- 4 External links
|
How it works
Strictly speaking, https is not a separate protocol, but refers to the combination of a normal HTTP interaction over an encrypted Secure Sockets Layer (SSL) or Transport Layer Security (TLS) transport mechanism. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided it is properly implemented and the top level certification authorities do their job.
The default TCP port of an https: URL is 443 (for unsecured HTTP, the default is 80).
To prepare a web-server for accepting https connections the administrator must create a public key certificate for the web-server. These certificates can be created for Unix based servers with tools such as OpenSSL's ssl-ca [1] or SuSE's gensslcert. This certificate must be signed by a certificate authority of one form or another, who certifies that the certificate holder is who they say they are. Web browsers are generally distributed with the signing certificates of major certificate authorities, so that they can verify certificates signed by them.
Organizations may also run their own certificate authority, particularly if they are responsible for setting up browsers to access their own sites (for example, sites on a company intranet), as they can trivially add their own signing certificate to the defaults shipped with the browser.
Some sites use self signed certificates. Using these provides protection against pure eavesdropping but unless the certificate is verified by some other method (for example, phoning the certificate owner to verify its checksum) and that other method is secure, there is a risk of a man-in-the-middle attack.
The system can also be used for client authentication, in order to restrict access to a Web server to only authorized users. For this, typically the site administrator creates certificates for each user which are loaded into their browser, although certificates signed by any certificate authority the server trusts should work. These normally contain the name and e-mail of the authorized user, and are automatically checked by the server on each reconnect to verify the user's identity, potentially without ever entering a password.
Limitations
The level of protection depends on the correctness of the implementation by the web browser and the server software and the actual cryptographic algorithms supported.
A common misconception among credit card users on the Web is that https: fully protects their card number from thieves. In reality, an encrypted connection to the Web server only protects the credit card number in transit between the user's computer and the server itself. It doesn't guarantee that the server itself is secure, or even that it hasn't already been compromised by an attacker.
Attacks on the Web sites that store customer data are both easier and more common than attempts to intercept data in transit. Merchant sites are supposed to immediately forward incoming transactions to a payment gateway and retain only a transaction number, but they often save card numbers in a database. It is that server and database that is usually attacked and compromised by unauthorized users.
Because SSL operates below http and has no knowledge of the higher level protocol, SSL servers can only present one certificate for a particular IP/port combination. This means that in most cases it is not feasible to use name-based virtual hosting with HTTPS. (This is subject to change in the upcoming TLS 1.1, which will enable name-based virtual hosting. As of December 2006, all major web browsers support TLS's Server Name Indication feature, but the feature is not widely used by web sites.)
