A trusted intermediary can do anything it likes and the recipient will
accept the data (provided that the trusted intermediary
re-authenticates it)
Now the trusted intermediary may not be trustworthy, but that is a
whole different thing entirely.
On Wed, Jul 25, 2012 at 8:43 PM, Grahame Grieve <grahame@kestral.com.au> wrote:
>> The objective should be to ensure that Web Services do not malfunction
>> in the presence of intermediaries, not to require them to attempt to
>> repair the damage.
>
> of course. But since we live in the real world too, we shouldn't prevent
> their use to repair the damage.
>
>> Where security is concerned the problem is that either something is
>> inside the authentication boundary or it is not. If it is inside the
>> boundary it must not be modified in any way whatsoever if the
>> integrity check is to work at all. If it is outside the boundary then
>> the dispatch service should probably not see it at all lest it end up
>> making assumptions that it is trustworthy.
>
> yes, quite. So currently there is a binary choice: you can have managed
> interactions, or secure interactions. As you say, in an ideal world, we
> would not need managed interactions (nor secure ones, really), But in
> the real world we do live in, we very much need secure interactions, and
> we also need managed ones. I'd like for the protocol to avoid making
> this a binary choice, though it smells ugly to me.
>
>> What it comes down to is that intermediaries that modify HTTP messages
>> can cause Web Services to stop working.
>
> oh yes, though they can also cause them to work in the first place.
>
>> Which is probably a good thing
>> since it is rather unlikely that an intermediary that does not
>> understand the semantics of the Web Service concerned is going to do
>> anything other than introduce breakage or worse introduce a subtle
>> error that it is not readily apparent.
>
> well, typically, in my world, the intermediary is a general purpose
> toolkit introduced over the exchange with the express purpose of
> bridging between two end-points that have very specific disagreements
> about how things work. This is a common requirement when actually
> integrating two off-the-shelf packages that both thought they'd implemented
> the same semantics, but in actual case haven't. In the context of a
> secure exchange, the general purpose toolkit gets to mount a MITM
> attack on them too. This works until the end-to-end security becomes
> part of the transaction semantics, at which point the MITM is no longer
> transparent, and there is no way forward.
>
> Grahame
>
> p.s. this is obviously about application to application web services, and
> the general argument doesn't make sense in a consumer web context.
--
Website: http://hallambaker.com/