HTTPS

Encyclopedia : H : HT : HTT : HTTPS

The correct title of this } is }}}. The initial letter is capitalized due to [Naming conventions #Lower case first lettertechnical 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 and an additional encryption/authentication layer between HTTP and TCP. This system was invented by Netscape Communications Corporation to provide authentication and encrypted communication and is widely used on the Web for security-sensitive communication, such as payment transactions.

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 socket layer (SSL) or 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.

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 Linux based servers with tools such as OpenSSL's ssl-ca [link] 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 such as 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 evesdropping 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 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 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.)

External links

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

HTTPS

How it works

Limitations

See also

External links