Hypertext Transfer Protocol over Secure Socket Layer (HTTPS)

From Computing and Software Wiki

Revision as of 18:17, 11 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.You can tell if the web site uses this security by looking for the HTTPS in front of the address and the "lock" icon, which may appear in different locations depending on your choice of web browser:

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

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. RFC 2818

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

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. RFC 2818

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. RFC 2660

Client Behavior

Because HTTP uses connection closure to signal end of server data,client implementations MUST treat any premature closes as errors and the data received as potentially truncated.RFC 2616 While in some cases the HTTP protocol allows the client to find out whether truncation took place so that, if it received the complete reply, it may tolerate such errors following the principle to "[be] strict when sending and tolerant when receiving" [RFC1958], often truncation does not show in the HTTP protocol data; two cases in particular deserve special note:

• A HTTP response without a Content-Length header. Since data length in this situation is signalled by connection close a premature close generated by the server cannot be distinguished from a spurious close generated by an attacker.

• A HTTP response with a valid Content-Length header closed before all data has been read. Because TLS does not provide document oriented protection, it is impossible to determine whether the server has miscomputed the Content-Length or an attacker has truncated the connection.

• There is one exception to the above rule. When encountering a premature close, a client SHOULD treat as completed all requests for which it has received as much data as specified in the Content-Length header.

• A client detecting an incomplete close SHOULD recover gracefully. It MAY resume a TLS session closed in this fashion.

• Clients MUST send a closure alert before closing the connection.Clients which are unprepared to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side.RFC 2660

Server Behavior

Permits an HTTP client to close the connection at any time,and requires servers to recover gracefully. In particular, servers SHOULD be prepared to receive an incomplete close from the client,since the client can often determine when the end of server data is.Servers SHOULD be willing to resume TLS sessions closed in this fashion.

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

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.[1] 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.[1] 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.[1][2]

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.

Browser implementations

Mozilla Firefox supports TLS 1.0 since version 2.

The Internet Explorer 8 in Windows 7 and Windows Server 2008 R2 supports TLS 1.2.

As of Presto (layout engine)Presto 2.2, featured in Opera (web browser)|Opera 10, Opera supports TLS 1.2

See Also

Transport Layer Security

External Links

The current approved version is 1.2, which is specified in:

• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.

The current standard obsoletes these former versions:

• RFC 2246: “The TLS Protocol Version 1.0”.
• RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.

Other RFCs subsequently extended TLS, including:

• RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).
• RFC 2818: “HTTP Over TLS”, distinguishes secured traffic from insecure traffic by the use of a different 'server port'.
• RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for negotiating protocol extensions during session initialisation and defines some extensions. Made obsolete by RFC 4366.
• RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the framework for compression methods and the DEFLATE compression method.
• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.
• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4279: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds three sets of new ciphersuites for the TLS protocol to support authentication based on pre-shared keys.
• RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works over datagram protocols (such as UDP).
• RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of specific extensions, and a generic extension mechanism.
• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.
• RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.
• RFC 4680: “TLS Handshake Message for Supplemental Data”.
• RFC 4681: “TLS User Mapping Extension”.
• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.

References

1. Named-based SSL virtual hosts: how to tackle the problem, SWITCH.
2. Mozilla (2008-08-06/). "Security in Firefox 2". https://developer.mozilla.org/en/Security_in_Firefox_2.
3. Microsoft (2009-02-27/). "MS-TLSP Appendix A". http://msdn.microsoft.com/en-us/library/dd208005%28PROT.13%29.aspx.
4. OpenSSL Contributions http://www.openssl.org/contrib/