Hypertext Transfer Protocol over Secure Socket Layer (HTTPS)

From Computing and Software Wiki

Revision as of 18:30, 10 April 2009

Abstract

The secure hypertext transfer protocol (HTTPS) is a communications protocol designed to transfer encrypted information between computers over the World Wide Web. HTTPS is http using a Secure Socket Layer (SSL). It connections are often used for payment transactions on the Web and for sensitive transactions in corporate information systems. It is relative simple and efficiency way to transfer information through HTTP. Since its own property, it is bound by Web browser software and Secure Sockets Layer (SSL). Therefore it inherits their shortcoming. On the other side, with those two kinds of technology developing, HTTPS also extend itself to new solution to face varied application problem.

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.

History and development

Early research efforts toward transport layer security included the Secure Network Programming (SNP) API, which in 1993 explored the approach of having a secure transport layer API closely resembling sockets, to facilitate retrofitting preexisting network applications with security measures. The SNP project received the 2004 ACM Software System Award.

The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 was released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0", which was released in 1996 (Rescorla 2001). This later served as the basis for TLS version 1.0, an Internet Engineering Task Force (IETF) standard protocol first defined in RFC 2246 in January 1999. Visa, MasterCard, American Express and many leading financial institutions have endorsed SSL for commerce over the Internet.

SSL operates in modular fashion. It is extensible by design, with support for forward and backward compatibility and negotiation between peers.

Applications

TLS runs on layers beneath application protocols such as HTTP, FTP, SMTP, NNTP, and XMPP and above a reliable transport protocol, TCP for example. While it can add security to any protocol that uses reliable connections (such as TCP), it is most commonly used with HTTP to form HTTPS. HTTPS is used to secure World Wide Web pages for applications such as electronic commerce and asset management. SMTP is also an area in which TLS has been growing and is specified in RFC 3207. These applications use public key certificates to verify the identity of endpoints.

An increasing number of client and server products support TLS natively, but many still lack support. As an alternative, users may wish to use standalone TLS products like Stunnel. Wrappers such as Stunnel rely on being able to obtain a TLS connection immediately, by simply connecting to a separate port reserved for the purpose. For example, by default the TCP port for HTTPS is 443, to distinguish it from HTTP on port 80.

TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN. Many vendors now marry TLS's encryption and authentication capabilities with authorization. There has also been substantial development since the late 1990s in creating client technology outside of the browser to enable support for client/server applications. When compared against traditional IPsec VPN technologies, TLS has some inherent advantages in firewall and NAT traversal that make it easier to administer for large remote-access populations[citation needed].

TLS is also increasingly being used as the standard method for protecting SIP application signaling. TLS can be used to provide authentication and encryption of the SIP signalling associated with VoIP and other SIP-based applications.

How it works

A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.

   * The handshake begins when a client connects to a TLS-enabled server requesting a secure 
     connection, and presents a list of supported ciphers and hash functions.
   * From this list, the server picks the strongest cipher and hash function that it also 
     supports and notifies the client of the decision.
   * The server sends back its identification in the form of a digital certificate. The 
     certificate usually contains the server name, the trusted certificate authority (CA), 
     and the server's public encryption key.

The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is authentic before proceeding.

   * In order to generate the session keys used for the secure connection, the client encrypts a random number 
     (RN) with the server's public key (PbK), and sends the result to the server. Only the server can decrypt 
     it (with its private key (PvK)): this is the one fact that makes the keys hidden from third parties, since only 
     the server and the client have access to this data. The client knows PbK and RN, and the server knows PvK 
     and (after decryption of the client's message) RN. A third party may only know PbK, unless PvK has been compromised.
   * From the random number, both parties generate key material for encryption and decryption.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails, and the connection is not created.

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.[2] 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.[3] 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.[4][5]

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.