Https
From Wikipedia, the free encyclopedia
Jump to: navigation (http://en.wikipedia.org/wiki/Https#column-one), search (http://en.wikipedia.org/wiki/Https#searchInput)
<!-- start content --> <dl><dd>The correct title of this article is https. The initial letter is capitalized due to technical restrictions (http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28technical_restrict ions%29#Lower_case_first_letter).</dd></dl> https is a URI scheme (http://en.wikipedia.org/wiki/URI_scheme) which is syntactically identical to the <tt>http:</tt> scheme normally used for accessing resources using HTTP (http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol). Using an <tt>https:</tt> URL (http://en.wikipedia.org/wiki/Uniform_Resource_Locator) 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 invented by Netscape Communications Corporation (http://en.wikipedia.org/wiki/Netscape_Communications_Corporation) to provide authentication (http://en.wikipedia.org/wiki/Authentication) and encrypted (http://en.wikipedia.org/wiki/Encryption) communication and is widely used on the World Wide Web (http://en.wikipedia.org/wiki/World_Wide_Web) for security-sensitive communication, such as payment transactions, and corporate logons.
<script type="text/javascript"> //<![CDATA[ if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); } //]]> </script>
How it works
Strictly speaking, https is not a separate protocol, but refers to the combination of a normal HTTP (http://en.wikipedia.org/wiki/HTTP) interaction over an encrypted (http://en.wikipedia.org/wiki/Encryption) Secure Sockets Layer (http://en.wikipedia.org/wiki/Secure_Sockets_Layer) (SSL) or Transport Layer Security (http://en.wikipedia.org/wiki/Transport_Layer_Security) (TLS) transport mechanism. This ensures reasonable protection from eavesdroppers and (provided it is implemented properly and the top level certification authorities do their drop properly) man-in-the-middle attacks (http://en.wikipedia.org/wiki/Man-in-the-middle_attack).
The default TCP (http://en.wikipedia.org/wiki/Transmission_Control_Protocol) port (http://en.wikipedia.org/wiki/List_of_well-known_ports_%28computing%29) of an <tt>https:</tt> 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 (http://en.wikipedia.org/wiki/Public_key_certificate) for the web-server. These certificates can be created for Linux (http://en.wikipedia.org/wiki/Linux) based servers with tools such as OpenSSL (http://en.wikipedia.org/wiki/OpenSSL)'s <tt>ssl-ca</tt> [1] (http://www.openssl.org/contrib/) or SuSE (http://en.wikipedia.org/wiki/SuSE)'s <tt>gensslcert</tt>. This certificate must be signed by a certificate authority (http://en.wikipedia.org/wiki/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 such as VeriSign (http://en.wikipedia.org/wiki/VeriSign), 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 (http://en.wikipedia.org/wiki/Man-in-the-middle_attack).
The system can also be used for client authentication (http://en.wikipedia.org/wiki/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 (http://en.wikipedia.org/wiki/Implementation) by the web browser (http://en.wikipedia.org/wiki/Web_browser) and the server software and the actual cryptographic algorithms (http://en.wikipedia.org/wiki/Cipher) 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 financial 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 (http://en.wikipedia.org/wiki/Secure_Sockets_Layer) 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 (http://en.wikipedia.org/wiki/Virtual_hosting#Name_based) with HTTPS. (This is subject to change in the upcoming TLS 1.1 - which will enable name-based virtual hosting.)