[
Lists Home |
Date Index |
Thread Index
]
>All the state must be in the client:
> http://groups.yahoo.com/group/rest-discuss/message/3594 (Baker)
> http://groups.yahoo.com/group/rest-discuss/message/3583 (Fielding)
That's an oversimplification. The resources referred to by the URI
can have state and this state is stored on the server. The server
does not have to expose the complete resource state to the client.
>The server cannot trust the client to not modify the session state,
>and it may have privacy concerns about exposing the entire state to
>the client in the first place. Therefore the server must encrypt
>the entire session state (if it even has it all) and encrypt it. It
>then gives this to the client so that the client can present it back
>on future requests.
In a properly designed system, it doesn't have to encrypt very much.
For instance shopping cart contents would normally be stored as part
of the resource state on the server. I'm not certain I know exactly
what you mean by "entire state", but if you're including resource
state in the "entire state", then the server does not need to give
the entire state to the client, nor does it need to worry about
client modification of that state. The only questions the server
needs to ask itself are:
1. Do I know how to return a representation of the resource for which
the client has presented me a URI?
2. Did the client also present the necessary authorization
credentials for this resource?
The server responds based on the answers to those two questions.
(Actually that's GET. POST and PUT are a little more complicated but
not greatly so.)
> (Let's ignore if that's done via Cookies or via querystring
>parameters in a URL.) In order to do this, we must use public-key
>encryption. For security (and REST state:) reasons, we cannot use a
>faster symmetric algorithm like 3DES or AES. We could use https to
>protect the content, but then we're back to shared state (the SSL
>context, but maybe REST doesn't care since that's just a transport
>issue).
You're right. REST doesn't care about the transport protocol. SSL is fine.
>Therefore, the server has to do a public-key decryption on every
>single incoming request in order to authenticate the client. That
>is not scalable. It makes the server completely susceptible to
>trivial DoS attacks, for example.
What feels wrong about this to me is that there are scalable, secure
sites in existence today that use SSL to encrypt sensitive
transactions. It's not obvious to me why this is more expensive than
those sites. It may be more expensive for sites that are not using
SSL. However, I'm not convinced it's cost-prohibitive or subject to
DOS attacks. Perhaps there's some point I'm missing here. Is it that
SSL uses public key encryption only to exchange a symmetric key, and
actually uses 3DES or some such symmetric algorithm for most data?
But digest authentication does not require the encryption of
everything, so it's cheaper than decrypting the entire page, and you
can still use HTTP over SSL with basic authentication if you prefer.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
