48 captures

26 May 2009 - 06 Dec 2022

Jan	FEB	Mar
	12
2009	2010	2011

success

fail

About this capture

COLLECTED BY

Organization: Alexa Crawls

Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.

Collection: alexa_web_2010

this data is currently not publicly accessible.

TIMESTAMPS

Client Update Protocol

Status: Deployed

Objective

Omaha and various other client products ping our servers for updates on a periodic basis. SSL provides the freshness and authenticity needed but comes with substantial overhead, both on the server- and client-side. We have empirical evidence that some clients are able to ping for updates over HTTP, but fail to do so over HTTPS. For embedded devices, requiring a SSL stack just to perform secure updates might not be feasible.

Client Update Protocol goals are:

• Provide more efficient yet secure alternative to SSL for update checks and similar client-server requests.
• Use HTTP transport layer, including traversing proxies.
  
• Have a small, self-contained implementation suitable for resource constrained deployments.
  

Non-goals:

• Replace SSL everywhere.
• Provide privacy of the communication. 
  
• Authenticate clients / DRM.
  

Background

To securely check for and download updates we need to protect the communication. The protection needs to cover:

• Authenticity. An attacker should not be able to replace or modify message content on the wire.
  

• Freshness. An attacker should not be able to trick a client into upgrading to an authentic but stale and vulnerable version.

Overview

• For fresh, authenticated update checks we do not need all of the SSL features:
  • The PKI part is not needed since we control both the client and the server and need not confer trust with anyone else.
    
  • Privacy of the download data is not needed since we do not intend to deliver private content; the downloads are free for all.
  • Integrity of requests and message meta-data (headers etc) might not be needed as long as the meta-data we act on is authentic.
    
  • We only need a few of the cryptographic primitives and need not negotiate.
  • Request replay protection (request freshness from the server perspective) is not essential for update checks and similar idem-potent interactions.
    
• We control all of the client code and communication stack, unlike the typical web-application scenario involving browsers.
• For thin clients, the SSL requirement comes with a lot of code bloat.
• We can achieve better handshake amortization than non-rfc5077 SSL stacks offer.
• When relaxing request replay protection, we can achieve reply authenticity in a single round-trip.

Detailed Design

There are two distinct parts that need to be designed:

• A protocol. 
  
• How to combine the protocol with the HTTP transport layer.

Protocol

Cryptographic primitives

• SYMsign_key(data) := HMAC-SHA1

• HASH(data) := SHA1

• RSApad_|keybits|(data) := (r | SHA1(r))[0..keybits-1]; msb (keybits-1-160) bits random; lsb 160 bits SHA1 of the random bits.
• RSAencrypt_key(data) := Raw RSA encrypt; Public exponent 3.
  
• RSAdecrypt_key[](data) := Raw RSA decrypt.
• RSAcheckpad(data) := Verify lsb 160 bits are SHA1 of remaining bits.
  
• SYMencrypt_key(data) := key version | HMAC | AES-CTR, using HMAC as IV.
  
• SYMdecrypt_key[](data) := key version | HMAC | AES-CTR, using HMAC as IV.
  

Protocol observations

Freshness is achieved by having the client pick a fresh w for every request.

The client operations are efficient enough to always both RSAencrypt and SYMsign. The client accepts authenticated responses for either sk or sk'.

We can amortize the cost of RSAdecrypt on the server-side over many requests. Either the client or the server can initiate roll-over to a fresh shared secret by not sending or not honoring the cookie. Typically our client will always send the cookie and our server manages the length of the exposure. 

An attacker could replay a request to the server and would get a valid response; this could pollute server statistics. Care must be taken to make sure our request handling remains essentially idem-potent. 
If idem-potency is not feasible, a server-side challenge, synchronous time or server-side bookkeeping can be used to make requests be one-time events. For the envisioned update protocols this is not required. Note this is due to the protocol not authenticating the client in any shape or form.     

RSApad / RSAcheckpad are not cryptographically required (compared to using |keybits| of random) but do provide a signal whether clients have the public key they claim they have and/or whether the client library is able to RSAencrypt properly.

cp (client proof) is used to tell whether the client knows the sk associated with cookie c. Having the server test this allows for more graceful fail over to a fresh sk in case the client state somehow got out of sync.

If c nor w decrypts correctly the server could return a specific response which triggers a fall-back to a SSL update protocol.

The server need not use the same ss[x] for every c' it hands out. And different servers could use different ss[x] as long as all servers in the server pool know all ss[] in circulation. Note there is no real security benefit to doing this.

An attacker could try to DoS the update servers by triggering the expensive RSAdecrypt for many requests in parallel. When under attack, the servers could throttle or reject requests that do not offer valid c and cp. Note validating c and cp requires knowledge of ss[].

Whenever a cookie (c or c') is sent over the wire, the sender includes it in the cryptographic proof along with it (cp or sp). An intermediary stuffing or removing a cookie on the wire will not achieve anything beyond failing of the proofs. The client will not store a cookie that the server did not intend to be associated with the shared secret.

The hash of the request (req) is carried through the cryptographic proofs. Results from requests for resource A cannot be mistaken for results for requests for resource B.

RSAdecrypt takes about 3 msec on a single 32-bit core. Less than half that on a 64-bit core in 64-bit mode. All other primitives (SYMdecrypt, SYMsign) take orders of magnitude less time. RSAencrypt happens on the client but is a lot less computationally intensive to start with. Probably less than 0.1 msec.

HTTP transport mapping

• w is URL parameter (e.g. /update?w=hhrk2hkjh23r2rkjhfdkjhas)
• c is sent as a regular cookie (e.g. Cookie: c=kjdlkajdla; Set-Cookie: c=kjasldkjalksdj)
• cp is sent as If-Match field (e.g. If-Match: "jksdflsjfl2h23t2")
• p is sent as ETag field (e.g. ETag: "lkajsdlkajflkjg2iljt2tlkjsdflj12341")
• content gets sent using the regular Content-Length header and HTTP message body.
  

HTTP transport mapping observations

Code Location

Caveats