HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol and a network security protocol.

HTTP operates at the highest layer of the TCP/IP Internet reference model, the Application layer; but the security protocol operates at lower sublayer, encrypting an HTTP message prior to transmission and decrypting a message upon arrival.

HTTPS has also been known as "Hypertext Transfer Protocol over Secure Socket Layer", but now HTTPS may be secured by the Transport Layer Security (TLS) instead of Secure Sockets Layer (SSL) protocol.

To invoke HTTPS, one replaces "http://" with "https://" in the URI, or Web address.

HTTPS connections are often used for payment transactions on the Web and for sensitive transactions in corporate information systems.

Function

Further information: Transport Layer Security § 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) connection. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted.

An https: URL may specify a TCP port. If it does not, the connection uses port 443 (unsecured HTTP typically uses port 80).

To prepare a Web server to accept 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 or SuSE's gensslcert. This certificate must be signed by a certificate authority of one kind or another. The authority certifies that the certificate holder is indeed the entity it claims to be. 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). They can easily add copies of their own signing certificate to those shipped with the browser.

Some sites, especially those operated by hobbyists, use self-signed certificates on public sites. Using such certificates provides protection against simple eavesdropping, but the prevention of man-in-the-middle attacks entails the use of some other secure method of verifying the certificate.

The system can also be used for client authentication in order to limit access to a Web server to authorized users. To do this, the site administrator typically creates a certificate for each user, a certificate that is loaded into his/her browser. Normally, that contains the name and e-mail address of the authorized user and is automatically checked by the server on each reconnect to verify the user's identity, potentially without even 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.

Also, HTTPS is unsecured when applied on publicly-available static content. The entire site can be indexed using a Web crawler, and the URI of the encrypted resource can be inferred by knowing only the intercepted request/response size. This allows an attacker to have access to the plaintext (the publicly-available static content), and the encrypted text (the encrypted version of the static content).

Because SSL operates below HTTP and has no knowledge of higher-level protocols, SSL servers can only strictly 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. RFC-3546 TLS Extensions describes a solution called Server Name Indication (SNI), although many older browsers don't support this extension. Support for SNI is available since Firefox 2.0, Opera 8, Mozilla 1.8, and Internet Explorer 7 on Windows Vista.

With the newer Internet Explorer 7 browser, Microsoft has increased the warnings sent when certificates are not registered. Whereas previously only a "security advice" pop-up appeared (which differentiated between name, source, and run time of the certificate), now a warning is displayed across the entire window, which recommends not using the Web site. Therefore, a certificate that is not registered in the browser is not usable for mass applications. Certificates that are registered in the root chains cost between US$10 and $1,200 per year.

Mozilla Firefox 3.0 introduced Secure Website Certificate Verification. When you visit a secure website, Firefox will check with the certificate provider to validate that website's certificate. Firefox sends only the certificate identification to the certificate provider, not the exact URL you are visiting. If the certificate is not valid, you will receive an error page that states the certificate was revoked and you will not be able to access that website. The technical name for this process is OCSP or On-line Certificate Status Protocol. You may completely turn off the secure website certificate verification feature in Firefox's preferences under the encryption tab.

See also

• Computer security
• AAA protocol
• List of file transfer protocols
• Secure hypertext transfer protocol, an alternative to https that is not widely supported (defined in RFC 2660)

External links

• SSL 3.0 Specification (IETF)
• Apache-SSL homepage (No longer actively developed)
• Apache 2.2 mod_ssl documentation
• RFC 2818 - HTTP Over TLS
• HTTPS Protocol in Internet Explorer Development - MSDN
• Manually Configuring Windows Communication Foundation (WCF) when using HTTP and HTTPS - MSDN
• HTTPS Security Improvements in Internet Explorer 7 & its Compatibility Impact - MSDN