[
Lists Home |
Date Index |
Thread Index
]
> Your real world example is based on SAML, a system which is not
> actually used in browsers today
Not true. They're using browser artifacts, which are essentially
cookies from the SAML server, added as a URL query-string parameter,
and then fetched and cache by the target server. As I said in another
message, it all works without support of browser vendors.
> I'm talking about
> browsers and web servers, and you're off into web services
Oh? I thought there was lots of architectural REST discussion going
on, too. And anyway, my example is browser-based. I mentioned WS,
but nothing in the concrete discussion would be invalid for WS. After
all, I'm talking about cookies for holding references to server
credential state, which is really all about browsers. So I don't think
I was moving the goal posts, honest.
> Yes. 3K extra per page doesn't set off my alarm bells
Really? 3K vs 256 bytes? It certainly bothers me.
> Not all protocols have to be stateless. But HTTP is.
So you don't consider the cookie RFC to be part of HTTP, okay, that's
certainly your right. HTTP gets lots of things right, unfortunately
not the security part. (I think I've used enough list bandwidth
by now so that folks understand what I mean by that.) As an engineer,
I can "fix" HTTP or I can start from scratch to avoid violating the
architectural purity. I can use most of REST, addressing what it
got wrong in one area, or I can throw it all out. Was the thesis
graven on stone tablets? :)
> 2ms. I would have guessed more. That's why measuring is important.
> Again, this is not large enough that making a compromise in the name
> of increased speed at the cost of architecture seems wise to me.
It's all relative. As I said, it's more-than-doubling the amount of
crypto, SSL-like, work the server must supply on messages that are
now 12 times the size. And many folks would make the same compromise
as me.
> I'm understanding this attack correctly, using state would only
> remove the need to verify after the initial, verified transaction.
> Can the attacker not send just as many initial, malformed requests?
> How does maintaining state present this attack?
It narrows down where you have to do DoS
> I see you're thinking here more about the DOS than key theft. For key
> theft, the good guys and the bad guys do not benefit equally from
> increased efficiencies.
Not at all. If I get a more powerful processor, I can use a bigger
nonce in my digest-auth. If the adversary gets a more powerful
processor, he can do more dictionary, password-guessing, attacks.
> In practice, DOS is a problem today with HTTP irregardless of
> encryption. In practice, DOS attacks are dealt with by cutting off
> attacking hosts at the router.
But it's not really DoS, but DDoS, a zillion zombie machines.
That's because the workload is equally divided between client and
server -- sending the bad packets is as costly as receiving them
in a SYN flood, e.g. In a crypto DOS attack, it's one machine, one
bad message, and I've doubled the load on your server. The asymmetry
of creating bogus crypto versus detecting it is inherent.
> >services exchange real value or real liability (e.g., your doctor's
> >office sending a prescription renewal the pharmacy closest to your
> >conference hotel)
> >compromise will have to tip toward security and away from REST.
>
> Anything like this should be done with SSL.
SSL isn't appropriate. SSL provides data privacy *while the data
is in transit.* It does not provide any offline validation,
authentication, or privacy. There is a real important reason why
the IETF renamed it TLS. It's transport security, not application
data security. SSL is hop-by-hop, not end-to-end.
> Compare the
> case today where the doctor's office calls the pharmacy on the phone.
Or million-dollar contracts being legal by faxing "signature on
letterhead." The point here is that the legal system (through
things like UCC, the Uniform Commercial Code, UN treaties, etc),
has decided that those things are acceptable. Not surprisingly,
legal and business practices haven't yet caught up to the technology,
and (just because I can't resist although I probably should :),
neither has REST.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
|
