7.6 CREHMA
7.6.3 Use Cases
We present two examples use cases to further illustrate CREHMA. The use cases are crafted following the the two main caching approaches, namely caching with freshness lifetime and with freshness validation (see Section7.2).
Caching with Explicit Freshness Lifetime
Let’s assume the request and response message flow in the Figure7.1requires to be protected by CREHMA. Following the signature generation and verification policies of CREHMA and the templates for the request and response messages, the constructed strings are shown below (based on the first HTTP message shown in Figure7.1):
String to be signed/verified for request message String to be signed/verified for response message 2019-06-13T15:41:10.494ZCR LF
GETCR LF /rscCR LF HTTP/1.1CR LF text/plainCR LF CR LF
CR LF
example.orgCR LF CR LF
47DEQpj8HBSa-_TImW-5JCeuQeRkm5...
2019-06-13T16:41:21.233ZCR LF GET example.org/rscCR LF HTTP/1.1CR LF
200CR LF CR LF CR LF
max-age=360,no-transformCR LF 11CR LF
text/plainCR LF CR LF
CR LF CR LF
pZGm1Av0IEBKARczz7exkNYsZb8LzaMr...
The string representation of the request message shows that the TVP, the HTTP method, the target resource, and the HTTP version are appended according to the order of the template in Figure7.4. The remaining mandatory headers follow in alphabetical order. The headers that are not present are represented by an empty string value.
Figure7.5shows the HTTP message flow in which caching with an explicit freshness lifetime is used. The message flow is analogous to Figure7.1with the exception that these messages contain CREHMA signatures. For the sake of readability, we removed theDateheaders though.
All messages include theSignatureheader which contains the signature value and related metadata. As both messages do not require to integrate additional application-specific headers to the signature and verification process, theaddHeaderparameter contains the valuenull.
If both endpoints intend to integrate additional security-relevant headers to the signature and verification process, a list with the header names using semicolon as delimiter must be in-cluded to theaddHeaderparameter (e.gaddHeaders=Content-Security-Policy;
X-XSS-Protection).
The signed response message contains aCache-Controlheader with the directivemax-age
=360which indicates that this response message can be reused for the next six minutes. If a client receives a signed response twice, then the verification process needs to add the seconds of the max-age directive value to the timestamp of the TVP value. If this sum is greater than the current time, the reused signature is considered as fresh. Beside max-age=360 the Cache-Controlheader also contains no-transform, which prevents intermediate systems from modifying the message body.
Caching with Freshness Validation
Figure7.6shows an example HTTP message flow involving caching with explicit freshness validation. Although the messages have been protected using the CREHMA signature scheme, the flow and especially the HTTP messages are mostly similar to the one in Figure7.2. Again, we omitted the theDateheader for readability reasons.
When the response is requested subsequent times, the cache converts the request into a condi-tional one by adding theIf-None-Matchheader and forwards the conditional request to the origin server. Since theIf-None-Matchand theIf-Modified-Sinceheaders are not part of the mandatory request headers, they can be added by the cache without interfering with the request’s signature. If the conditional request is successfully processed by the origin server, it returns a signed response message with the status code304 Not Modifiedas shown in Figure7.6. This response message contains only the response line and theETagheader with
Web Client Web Caching System Web Server
GET /rsc HTTP/1.1 Host: example.org Accept: text/plain
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T15:41:10.494Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
<Empty Body>
GET /rsc HTTP/1.1 Host: example.org Accept: text/plain
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T15:41:10.494Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
<Empty Body>
HTTP/1.1 200 OK Content-Length: 11 Content-Type: text/plain Cache-Control: max-age=360
Signature: sig=HMAC/256,hash=SHA256, ↩ tvp= 2019-06-13T15:41:21.233Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
Hello World
HTTP/1.1 200 OK Content-Length: 11 Content-Type: text/plain Cache-Control: max-age=360
Signature: sig=HMAC/256,hash=SHA256, ↩ tvp= 2019-06-13T15:41:21.233Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
Hello World
GET /rsc HTTP/1.1 Host: example.org Accept: text/plain
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T15:45:10.494Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
<Empty Body>
HTTP/1.1 200 OK Content-Length: 11 Content-Type: text/plain Cache-Control: max-age=360
Signature: sig=HMAC/256,hash=SHA256, ↩ tvp= 2019-06-13T15:41:21.233Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
Hello World
Figure 7.5: This example HTTP messages flow shows caching with a freshness lifetime. The messages are integrity protected by CREHMA.
valuexyzindicating that the cached response message is still up-to-date. Once a cache receives such a message, it is allowed to reuse the cached response but it must update the header entries of the stored response with the ones of the304 Not Modifiedresponse.
CREHMA makes use of the header updating policy in order to refresh the expired signature value of the stored response message in the cache. To do so, the origin server has to compute two signatures: One to update the expired signature of the cached response and the other is required to verify the integrity and authenticity of the304 Not Modifiedresponse. The string to be signed of the first signature must be constructed under the assumption that the full response message with a header and the body is returned (see left column in the table below).
This string is almost identical to the one which was constructed for the initial response message in Figure7.6. The only difference is the updated TVP value. To accelerate signature generation time, this string to be signed without the TVP value should be stored in server-internal database.
The database index for this string could be theETagheader value. When creating this signature for the next time, a new TVP value needs to be added only. The second signature must be crafted according to the message elements of the304 Not Modifiedresponse message as shown by the right column in the table below.
Web Client Web Caching System Web Server
GET /rsc HTTP/1.1 Host: example.org Accept: text/plain
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T16:41:10.494Z,↩
addHeaders=null,sv=<sv>,kid=<Key ID>
<Empty Body>
GET /rsc HTTP/1.1 Host: example.org Accept: text/plain
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T16:41:10.494Z,↩
addHeaders=null,sv=<sv>,kid=<Key ID>
<Empty Body>
HTTP/1.1 200 OK Content-Length: 11 Content-Type: text/plain Cache-Control: no-cache ETag: xyz
Signature: sig=HMAC/256,hash=SHA256, ↩ tvp= 2019-06-13T16:41:21.233Z,
addHeaders=null,sv=<sv>,kid=<Key ID>
Hello World
HTTP/1.1 200 OK Content-Length: 11 Content-Type: text/plain Cache-Control: no-cache ETag: xyz
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T16:41:21.233Z,↩
addHeaders=null,sv=<sv>,kid=<Key ID>
Hello World
GET /rsc HTTP/1.1 Host: example.org Accept: text/plain
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T16:45:10.494Z,↩
addHeaders=null,sv=<sv>,kid=<Key ID>
<Empty Body>
HTTP/1.1 200 OK Content-Length: 11 Content-Type: text/plain Cache-Control: no-cache ETag: xyz
Signature: sig=HMAC/256,hash=SHA256, ↩ tvp= 2019-06-13T16:45:21.633Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
Validation-Signature: sig=HMAC/256, ↩ hash=SHA256, ↩
tvp= 2019-06-13T16:45:21.733Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
Hello World
GET /rsc HTTP/1.1 Host: example.org Accept: text/plain
Signature: sig=HMAC/256,hash=SHA256,↩
tvp= 2019-06-13T16:45:10.494Z,↩
addHeaders=null,sv=<sv>,kid=<Key ID>
If-None-Match: xyz
<Empty Body>
HTTP/1.1 304 Not Modified ETag: xyz
Signature: sig=HMAC/256,hash=SHA256, ↩ tvp= 2019-06-13T16:45:21.633Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
Validation-Signature: sig=HMAC/256, ↩ hash=SHA256, ↩
tvp= 2019-06-13T16:45:21.733Z, ↩ addHeaders=null,sv=<sv>,kid=<Key ID>
Figure 7.6: This example HTTP messages flow shows caching with freshness validation. The messages are integrity protected by CREHMA.
The signature value and the corresponding metadata which are intended to update signature value of the cached response message must be inserted theSignatureheader. The other signature value in conjunction with its meta information which protects the 304 Not Modified response message must be included the newly introducedValidation-Signatureheader as shown in Figure7.6.
The returned304 Not Modifiedresponse message requires the cache to update the header entries of the stored response with the headers of the304 Not Modifiedresponse. Accord-ingly, theSignatureheader of the stored response message gets updated too. All updated headers are marked in bold. The response with the updated header can now be returned to client.
As theSignatureheader is refreshed, the client can successfully verify the message signature.
The addition of two signatures in the304 Not Modifiedresponse message is mandatory, as the origin server does not know whether the client or what intermediate system includes the If-None-Matchheader to the request message. If client has inserted these headers by itself
string to be signed/verified of response message signature to be updated
string to be signed/verified of304 Not Modified re-sponse message
2019-06-13T16:45:21.633ZCR LF GET example.org/rscCR LF HTTP/1.1CR LF
200CR LF CR LF xyzCR LF
no-cache,no-transformCR LF 11CR LF
text/plainCR LF CR LF
CR LF
pZGm1Av0IEBKARczz7exkNYsZb8LzaMr...
2019-06-13T16:45:21.733ZCR LF GET example.org/rscCR LF HTTP/1.1CR LF
304CR LF CR LF xyz
CR LF CR LF CR LF CR LF CR LF CR LF
47DEQpj8HBSa-_TImW-5JCeuQeRkm5...
because it operates an own cache or the client is a caching middlebox by itself which supports CREHMA, it must validate the signature value in theValidation-Signatureheader, as this security information verifies the authenticity and integrity of the304 Not Modified response message. If a client decides to add to the If-None-Match to the request mes-sage, it should not include this elements as additional to be protected header entries in the addHeadersparameter. This is also true for theIf-Modified-Sinceheader. According to the RFC 7234, caches can append further opaque validation token to theIf-None-Match header or can change the value in the If-Modified-Sinceheader. Such modifications impair the signature value of the request. In real world scenario, a client does not know how many and what intermediate systems a request message traverses until it reaches the origin server. Therefore, theIf-None-Matchand theIf-Modified-Sinceheader should be excluded from the signature and verification process.