TOC 
Network Working GroupM. Sporny
Internet-DraftDigital Bazaar
Intended status: Standards TrackJune 23, 2013
Expires: December 25, 2013 


Security Considerations for HTTP Signatures
draft-sporny-http-signatures-audit-00

Abstract

This document outlines the various security considerations that should be taken into account when utilizing the HTTP Signatures specification.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on December 25, 2013.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.



Table of Contents

1.  Introduction
2.  General Attacks
    2.1.  HTTP Attacks
    2.2.  HTTPS Attacks
3.  Passive Attacks
    3.1.  Confidentiality Violations
        3.1.1.  HTTP
        3.1.2.  HTTPS
    3.2.  Password Sniffing
    3.3.  Offline Cryptographic Attacks
        3.3.1.  HTTP
        3.3.2.  HTTPS
4.  Active Attacks
    4.1.  Replay
        4.1.1.  HTTP
        4.1.2.  HTTPS
    4.2.  Message Insertion
        4.2.1.  HTTP
        4.2.2.  HTTPS
    4.3.  Message Deletion
        4.3.1.  HTTP
        4.3.2.  HTTPS
    4.4.  Message Modification
        4.4.1.  HTTP
        4.4.2.  HTTPS
    4.5.  Man-In-The-Middle
        4.5.1.  HTTP
        4.5.2.  HTTPS
    4.6.  On-Path
        4.6.1.  HTTP
        4.6.2.  HTTPS
    4.7.  Off-Path
        4.7.1.  HTTP
        4.7.2.  HTTPS
    4.8.  Link-Local
        4.8.1.  HTTP
        4.8.2.  HTTPS
Appendix A.  Acknowledgements
5.  Informative References
§  Author's Address




 TOC 

1.  Introduction

The HTTP Signatures protocol is intended to provide a standard way for clients to sign HTTP requests. This document outlines the security considerations for that protocol along with various approaches for mitigating against known attacks on the protocol.



 TOC 

2.  General Attacks

The HTTP Signatures protocol is designed to protect developer-specified portions of an HTTP-based message. This means that full protection of the message contents at all times is not always a goal as some headers may not be in the list of signed headers. Developers should note that not signing a particular HTTP header is no worse than just using HTTP or HTTPS without signatures. Therefore, this section outlines the basic security considerations for HTTP and HTTPS-based communication in order to establish a "security floor" for the case where HTTP Signatures fail to secure the information intended to be secured by the developer.



 TOC 

2.1.  HTTP Attacks

HTTP is generally regarded as wide open to many different attack vectors, including but not limited to: information sniffing, phishing, insertion attacks, modification attacks, deletion attacks, spear-phishing, man-in-the-middle, DNS spoofing, header spoofing, and denial-of-service. It is should be assumed that all messages sent over HTTP are easily modified by peers on the network.

The Security Considerations for HTTP can be found in Section 15 of RFC 2616 (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) [RFC2617].



 TOC 

2.2.  HTTPS Attacks

The HTTPS protocol was developed in order to mitigate a large number of the attacks on HTTP. However, one drawback of HTTPS is the requirement to run a server with a valid TLS certificate. These certificates may be expensive or difficult to setup and configure correctly. For this reason, the HTTP Signatures specification is provided as an alternative mechanism for providing an acceptable level of security to certain applications that need to protect certain types of transactions on the network, but don't want to run those transactions over HTTPS.

While HTTPS is far more secure than HTTP, it is still susceptible to certain forms of attacks. For example, if a Certificate Authority is compromised, an attacker may mount man-in-the-middle attacks against any on-path traffic between the victim and the intended website. A class of these attacks may be mitigated by digitally signing the contents of the request or further encrypting the contents of the HTTP message.

The Security Considerations for HTTPS can be found in RFC 2818 (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818].



 TOC 

3.  Passive Attacks

Passive attacks consist of attacks that attackers can execute without writing to the network. These attacks are mainly used to steal information that may be used to mount an active attack at a later point in time.



 TOC 

3.1.  Confidentiality Violations



 TOC 

3.1.1.  HTTP

All of the known confidentiality violation attacks against HTTP are also applicable to signed HTTP messages with the following exceptions:

Replay attacks are mitigated using nonces as specified in the HTTP Signatures specification.

Headers that are signed using HTTP Signatures cannot be spoofed without considerable effort expended to break the cryptographic algorithm used to generate the digital signature. By default, the HTTP method, location, and Host header parameters are protected.



 TOC 

3.1.2.  HTTPS

All of the known confidentiality violation attacks against HTTPS are also applicable to signed HTTPS messages with the following exceptions:

It is possible to mitigate a replay attack using nonces as specified in the HTTP Signatures specification since two different verficiations will need to be performed on the data. The first is for the TLS server certificate, the second is for the digital signature on the data. This "double signature" would ensure that messages sent to a compromised on-path router would be able to be read, but not replayed. However, there are still dangers with this sort of approach. Namely, if a man-in-the-middle can convince a victim to generate multiple requests by notifying the victim of a faked error, then each one of those requests could be replayed. This attack, however, may be mitigated if the server also digitally signs its responses and the victim verifies those responses.

It is also possible to mitigate an attack where the Certificate Authority is compromised by digitally signing all information that is intended for the client and the server. This ensures that even in the event of a compromised HTTPS channel, that the information can be transmitted without concern that the data will be modified by an attacker.



 TOC 

3.2.  Password Sniffing

All sensitive information sniffing vulnerabilities that apply for HTTP apply for HTTP Signatures used over HTTP. That said, since there are no passwords used when performing HTTP Signatures, there is no risk for a HTTP Signature-specific password to be stolen via HTTP or HTTPS.



 TOC 

3.3.  Offline Cryptographic Attacks



 TOC 

3.3.1.  HTTP

Offline cryptographic attacks require knowledge of the inputs that went into a particular message that was digitally signed. If a signed message is sent over HTTP, then the attacker has full access to the inputs, except for the private key, that went into the signature. In this case, the difficulty of attacking the signature or the private key is no different than the standard literature about attacks against RSA.

It should be noted that not including enough randomness in a message could be used as an attack vector. For example, digitally signing thousands of messages that only differ in the timestamp could be (theoretically) used in a statistical attack against the key. Application authors are urged to ensure that enough randomness is injected into the text being digitally signed in order to protect against statistical attacks against the private key.



 TOC 

3.3.2.  HTTPS

Offline cryptographic attacks against a signature transmitted over HTTPS would have to defeat the HTTPS encryption scheme before an attack can be performed on the signature or private key associated with the message. If HTTPS is defeated, HTTP message integrity is still protected by the signature. An attack that assumes that HTTPS is defeated would have the same attack characteristics as if HTTPS were not used to protect the message in transit.



 TOC 

4.  Active Attacks

Active attacks consist of attacks that attackers execute by writing to the network. These attacks are mainly used to modify messages in a way that temporarily or permanently place parts of the system under the control of the attacker.



 TOC 

4.1.  Replay



 TOC 

4.1.1.  HTTP

Replay attacks over HTTP are fairly trivial to accomplish. An attacker would typically capture network traffic, including the HTTP message, and then re-transmit the HTTP message at a later time (within the HTTP message time window). A victim would not be able to detect the attack if there is no mechanism employed to determine if the message was previously recorded.

A mitigation for the replay attack is to use the nonce mechanism outlined in an extension specification to the HTTP Signatures specification. While nonces have traditionally been a pain to implement, the HTTP Signature nonce approach utilizes a mechanism that is fairly easy to implement and requires very little memory on both the client and the server.

Even if nonces are employed, there is a class of application attack where the attacker relays traffic between the victim and the server. When the victim sends a signed message, the attacker captures the message and prevents it from reaching the intended server. The attacker then sends a failure response back to the victim. If the victim's software is set to automatically re-send requests, the attacker can continue to send failure responses and can queue up a series of valid requests from the victim (For example: "Send $10 to Alice"). The attacker would then replay all of these queued requests to the server, within the time window, and the server would accept them as valid requests from the victim.

To mitigate this sort of application attack, application authors are urged to require digital signatures from both the client and the server.



 TOC 

4.1.2.  HTTPS

Replay attacks on messages encapsulated in the HTTPS protocol are much more difficult to achieve because replay protection is a feature that is built into HTTPS. In order to attempt a replay attack, an attacker must first defeat the replay protection mechanism in HTTPS. If HTTPS is broken, the replay attack concerns become the same as for HTTP Signatures over HTTP.



 TOC 

4.2.  Message Insertion



 TOC 

4.2.1.  HTTP

Message insertion attacks over HTTP are easily accomplished for HTTP headers that are not included in the signature. It is advised that both clients and servers should not trust HTTP headers that are a part of a request that are not included in the signature.

To prevent message insertion attacks, both clients and servers should digitally sign all important portions of an HTTP message (headers and body).



 TOC 

4.2.2.  HTTPS

Message insertion attacks over HTTPS are protected because the entire message stream is protected, including each individual HTTP message. If HTTPS protection is compromised, the same concerns as exist for HTTP message insertion attacks apply.



 TOC 

4.3.  Message Deletion



 TOC 

4.3.1.  HTTP

It is possible for an attacker to entirely remove a signed message from the network if the message is traveling over HTTP. This attack can be performed by inserting an attacker as a relay between the client and the server. An attacker may then choose to drop messages that result in giving them an advantage on the network.

There are two ways to mitigate deletion attacks over HTTP. The first is to implement a message counter at the application layer. If a server and client agree to use a sequential counter, that counter can be included in every message between the server and client. The drawback to this approach is additional overhead on both the client and the server as each has to keep a counter associated with each peer on the network.

The second approach to mitigating a deletion attack over HTTP is to ensure that both the request and response are digitally signed. If an attacker successfully deletes a message from the network, it will be unable to forge a response to the victim that is verifiable as having come from the responder. It is important to note that a response should contain enough randomness to ensure that a replay attack is not possible for the response over HTTP. The use of a nonce in the response message is a minimum requirement to ensure protection against replay that could result in a deletion going unnoticed by the victim.



 TOC 

4.3.2.  HTTPS

HTTPS contains protections against deletion attacks by utilizing a message counter in the protocol. In order to achieve a deletion attack in HTTPS, an attacker would have to compromise the HTTPS protocol. If an attacker is able to compromise the HTTPS protocol, the concerns related to deletion attacks over HTTP apply.



 TOC 

4.4.  Message Modification



 TOC 

4.4.1.  HTTP

Message modification attacks over HTTP are easily accomplished for HTTP headers that are not included in the signature. It is advised that both clients and servers should not trust HTTP headers that are a part of a request that are not included in the signature.

To prevent message modification attacks, both clients and servers should digitally sign all important portions of an HTTP message (headers and body).



 TOC 

4.4.2.  HTTPS

Message modification attacks over HTTPS are protected because the entire message stream is protected, including each individual HTTP message. If HTTPS protection is compromised, the same concerns as exist for HTTP message modification attacks apply.



 TOC 

4.5.  Man-In-The-Middle



 TOC 

4.5.1.  HTTP

The Man-In-The-Middle attack, where an attacker relays messages for an unknowing victim, is possible on any unsigned HTTP message. The state of HTTP is such that there is no protocol-level protection against this sort of attack.

Two of the protections that HTTP Signatures provides is the ability to protect against insertion and modification attacks with a signature (as long as all of the fields that need to be protected are included in the signature). Detection of deletion attacks may also be achieved using a simple nonce mechanism. With these three HTTP Signature-based protections in place, all known Man-In-The-Middle attacks on HTTP can be detected such that an application can determine that it may be under attack and act accordingly.



 TOC 

4.5.2.  HTTPS

The HTTPS protocol provides multiple protections against Man-In-The-Middle attacks. In order to remove these protections, the HTTPS protocol must be compromised. If the HTTPS protocol is compromised, the same Man-In-The-Middle concerns that are outlined for signatures over HTTP apply.



 TOC 

4.6.  On-Path



 TOC 

4.6.1.  HTTP

The HTTP protocol is susceptible to on-path attacks.

On-path attacks can be mitigated using HTTP Signatures by utilizing the HTTP Signature-based protections for message insertion, modification, and deletion. It is important to note that the origin of a message is not a concern for HTTP Signatures. In fact, HTTP Signatures are agnostic to network topology. The only information that matters is the sender and receiver of the message, which is cryptographically established via the signature.



 TOC 

4.6.2.  HTTPS

The HTTPS protocol provides multiple protections against on-path attacks. In order to remove these protections, the HTTPS protocol must be compromised. If the HTTPS protocol is compromised, the same on-path concerns that are outlined for signatures over HTTP apply.



 TOC 

4.7.  Off-Path



 TOC 

4.7.1.  HTTP

The HTTP protocol is susceptible to off-path attacks.

Off-path attacks can be mitigated using HTTP Signatures by utilizing the HTTP Signature-based protections for message insertion, modification, and deletion. It is important to note that the origin of a message is not a concern for HTTP Signatures. In fact, HTTP Signatures are agnostic to network topology. The only information that matters is the sender and receiver of the message, which is cryptographically established via the signature.



 TOC 

4.7.2.  HTTPS

The HTTPS protocol provides multiple protections against off-path attacks. In order to remove these protections, the HTTPS protocol must be compromised. If the HTTPS protocol is compromised, the same off-path concerns that are outlined for signatures over HTTP apply.



 TOC 

4.8.  Link-Local



 TOC 

4.8.1.  HTTP

The HTTP protocol is susceptible to link-local attacks.

Link-local attacks can be mitigated using HTTP Signatures by utilizing the HTTP Signature-based protections for message insertion, modification, and deletion. It is important to note that the origin of a message is not a concern for HTTP Signatures. In fact, HTTP Signatures are agnostic to network topology. The only information that matters is the sender and receiver of the message, which is cryptographically established via the signature.



 TOC 

4.8.2.  HTTPS

The HTTPS protocol provides multiple protections against link-local attacks. In order to remove these protections, the HTTPS protocol must be compromised. If the HTTPS protocol is compromised, the same link-local concerns that are outlined for signatures over HTTP apply.



 TOC 

Appendix A.  Acknowledgements

The following individuals made major contributions to the contents of this document: Mark Cavage, Dave Longley, and David I. Lehn.



 TOC 

5. Informative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, June 1999 (TXT, HTML, XML).
[RFC2818] Rescorla, E., “HTTP Over TLS,” RFC 2818, May 2000 (TXT).
[RFC3339] Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).


 TOC 

Author's Address

  Manu Sporny
  Digital Bazaar
  1700 Kraft Drive
  Suite 2408
  Blacksburg, VA 24060
  US
Phone:  +1 540 961 4469
Email:  msporny@digitalbazaar.com
URI:  http://manu.sporny.org/