]> Digital Bazaar

1700 Kraft Drive Suite 2408 Blacksburg VA 24060 US +1 540 961 4469 msporny@digitalbazaar.com http://manu.sporny.org/

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

The HTTP Signatures specification is intended to provide a standard way for clients to add origin authentication and message integrity to HTTP-based messages. The HTTP Signature Nonces specification describes a way to use the HTTP Signatures protocol over an unsecured channel like HTTP. This document outlines the security considerations for HTTP Signatures along with various approaches for mitigating against known attacks on the protocol whether it is used over unsecured or secured channels.

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.

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 should be assumed that all messages sent over HTTP are easily viewed or modified by attackers. The Security Considerations for HTTP can be found in Section 15 of RFC 2616.

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 Signature Nonces 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.

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.

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 Signature Nonces 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 request line, Host, and Date header parameters are protected.

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 Signature Nonces specification since two different verifications 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.

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.

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 the utilized digital signature scheme. 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.

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.

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.

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 mechanism described in the HTTP Signature Nonces 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 for both requests and responses. Both the client and the server should validate digital signatures if they are included in the message. As the default scheme is to include the `Date` header in the signature, service providers SHOULD protect against logged replay attacks by enforcing a clock skew. The server SHOULD be synchronized with NTP, and the recommendation is to allow 300 seconds of clock skew (in either direction).

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.

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).

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.

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.

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.

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). In order to ensure protection on the message body, a hash of the contents of the message should be included in an HTTP Header that is included in the signature for the message.

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.

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 application-based message counter. 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.

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.

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.

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.

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.

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.

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.

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.

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

&rfc2119; &rfc2616; &rfc2818; &rfc2617; &rfc3339; &rfc5246;