forked from gaperik/sec_obj_cache
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft_sec_obj_cache
183 lines (117 loc) · 7.64 KB
/
draft_sec_obj_cache
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
No Working Group GE
December 20th, 2014
Content delivery from secure origins and caching
Status of document
This document gathers thoughts on requirements from a service provider perspective on delivering protected
objects to a web application assumed to be implemented in a browser using the Internet and using caches,
either controlled by the service provider or outsourced to a 3rd party, with whom the service provider
is assumed to have an agreement.
0. Terminology
Client An end user device with a W3C compliant web runtime and a web application supplied by a
service provider.
Origin Representation of the server side functionality of a service provider solution.
Cache proxy An intermediate node or set of nodes (CDN) providing the possibility to cache content from the
origin to be used by the web application.
Channel security Channel refers to a transport "channel", and security refers to the transport being encrypted
(using e.g. TLS).
Application level Content (including application logic) is encrypted. The only ones having access to unencrypted
security content (of any form) is the Origin and the Client (supplied by the Origin), and in the latter case
only for the purpose of rendering of content. Note: enabling the Cache proxy to transcode/adapt
content may break this assumption.
Secure origin A secure origing is an origin to which there is a secure communication of data to and from
the client. It is secure from an authentication, integrity and confidentiality perspective.
(Note that this definition is different from the one adopted by the webappsec WG in
https://w3c.github.io/webappsec/specs/mixedcontent/#terms)
Trusted origin A trusted origin is an origin associated to which there is a service provider with whom a user
has a trust relationship. The trust relationship includes the users data - or knowledge obtained
by the SP having access to the data - is protected and not redistributed without the consent of
the user and/or in accordance with regulations applicable to the users(!) locality.
1. Introduction
In the light of revelations of massive, pervasive monitoring and, in parts of the world, increased attention
to privacy concerns as well as regulations for handling customers and employees personal data, various forms of
means to protect data transfer from an origin to a client are applied and new technologies developed. The
concept of 'secure origin' has been brought up and are worked on in applicable mailling lists such
as webappsec, etc.
To further our understanding, this document attempts to explore the requirements on the solution from a
service provider perspective as well as drafting potential solutions to the problems that are identified
covering client, origin and caching proxies.
In doing so, the scenarios where the service provider is operating the caching proxies himself or outsourcing
it from a 3rd party- sometimes referred to as a CDN- are discussed.
In this context, both passive and active caching are considered, active caching meaning pushing content to a
cache including device caches before the content having been requested by a user or rather the web application.
Passive caching is the case where content having been delivered to user A is cached and later used when same
content is requested by user B (or user A again).
2. Problem statement
2.1 General
Consider a web service service provider with a client, an origin server and intermediate, reverse proxies.
The content ingestion is assumed to happen in the back-end of the origin server. The content delivery process
stretches from the origin server via intermediate caches proxies to the web client or directly origin- client
or a combinatione thereof.
The service provider (SP from now on) have the following set of considerations:
R1) Control of the user experience, to the extent the device and transport capabilities allow for it, meaning
that the actual experience of the user should match the intended experience as is/was assumed in the
composition of the Web application.
R2) Parts of the experience may come from content to which Digital Rights are associated, rights that need to
be protected.
R3) Fulfilling the commitments to the user as stipulated in the privacy policy.
R4) Compliance to local regulations.
R5) Delivering on the promise of a UI 'secure origin'.
R6) High quality of experience utilizing the available transport and device capabilities optimally.
R7) Production cost minimized...(certificates, storage, computing, networking, etc.).
2.2. Sample problem example
<Do we need an example?>
3. Drafting a solution
3.1. From the perspective of the SP
Assume the SP wants to take considerations R1.R7 into account, in particular R3, that is providing a 'secure
origin' feeling.
One approach is to use HTTPS between the client and the origin. That one however may incur considerable delays or
high transport costs. A typical solution today is the SP using a cache proxy. But using HTTPS requires the SP
to provide the certificate to the proxy where the HTTPS will be terminated. In case the proxy is deployed
remotely from the origin server, further actions are required, such as having the proxy setting up a secure
transport towards the origin servers, for instance a new HTTPS connection.
This may however not be enough in cases where the cache is either provided by a 3rd party or deployed in a
computing context where the control of the cache by the SP is not sufficient, e.g. the certificate can be
obtained by the local IAAS provider, potentially creating a risk for the content delivery to be compromised.
For these reasons- an presumably more- the SP may also need to apply application level security on the content
passing the proxy using an end-to-end security association making the risk vector for the data passing or
being cached in the proxy smaller.
The above means the SP has a set of tools available for delivering content from its origin for an individual
session:
* E2E HTTPS connection(s).
* Multi-layer caching enabled secure transfer- a combination of application level encryption of data and
hop-by-hop HTTPS connections between client-proxy-origin.
And combinations of the above.
To further clarify the need of application level security, consider the case where HTTPS only is used and a 3rd
party cache proxy shall be used; This scenario requires the certificate of the HTTPS connection between the
client and origin domain to be given to the CDN provider. But at the same time, the implied expectation in
'secure origin' and possibly a padlock icon in the UI is that the is a secure connection between client and origin,
an expectation that is not reflected in the actual situation. One could argue that this indirectly violates the
expectations associated with 'TLS', similar to if TLS protocol would be designed to allow intermediate,
transparent MITM's.
3.2 Application level security per content type and different types of web app data
<Placeholder for going through web app data and various content types
Web app data:
* Javascript
* 'data to DOM, see content types.
Content types:
* images
* audio element
* video element
* JSON
* ...
>
4. Example use case
<Placeholder:
1. User initiates web app
2. Web app connects to origin using HTTPS bootstrap. Client authentication
3. Download via bootstrap HTTPS connection of keys for caching enabled connection
4. First view downloaded via bootstrap connection(?)
5. From then on, in selected cases, content pushed or pulled, from origin to cache, origin or cache to device
cache>
To be continued....
Acknowledgements
About the authors
GE
SH
...
...