What puzzles me is the one size fits all mentality I see everywhere.
The locks on my front door a pathetic joke compared to what Bank of America uses for their vaults. As is the monitored alarm system I have.
But a whole lot more door locks are sold than bank vaults. On the other hand, the margins on bank vaults are undoubtedly a lot higher. As are the liability implications, I can only presume.
I’m glad that there are vaults are out there, but I certainly don’t want to live in one.
You are going to love “Security Requirements for HTTP”, a soon to be released I-D.
The thesis is that any successful HTTP-based protocol will have implementations with differing security requirements, and security requirements will in turn influence other properties like scalability and graphic design. The converse is also true. Graphic design influences security implementation.
My hunch is that minimum security requirements make about as much sense as minimum graphic design requirements. But I’ll start by documenting every single trade off, and add prescriptive text to the introduction and conclusion when all the data is in.
Your post hits some good points. A lot of us write software for banks that have web security that is not even adequate for home protection for one thing.
Anyhow, I am no way suggesting there is only way to do this or that WS-Security came down on stone tablets. I am also not suggesting that a NSA level of security is appropriate for Google Maps. There are many shades of gray. “good enough” security is a big challenge, and it isnt about black and white security models, it is about risk management — I have a whole series of posts on this [link]
REST runs on the web and other distributed systems. There are bad people on the web who want to steal your stuff, I am sorry but that is the way it is. What I am saying is - if you blow off the things that WS-Security does because they are too hard then you really aren’t trying very hard. You don’t have to use WS-Security, write something better. But do it, and don’t roll out some tired old 1995 security model, because you know what? Attackers evolve. They don’t just sit there and say - “gee these guys have a firewall AND SSL, man I am going home.”
Amazon didn’t go to the trouble to putting tokens in their services because it was easy and fun, they did it because they didn’t want to participate in fraudulent transactions. You don’t have to live in a vault, but you do need to deal with security on some level.
...if you blow off the things that WS-Security does because they are too hard then you really aren’t trying very hard
I don’t believe anyone is blowing off what WS-Security does; I believe they’re mainly concerned with how. It is possible to improve security without sacrificing other key characteristics of your application.
Are you making a distinction between SSL Client-Certs for authentication and SSL for encryption Gunnar? It doesn’t appear so.
Is there some fundamental flaw with using SSL for authentication+encryption that WS-Security tries to address?
Or perhaps you’re referring to situations in which issuing client-certs would be problematic? I mean, I could imagine a public service having administrative overhead concerns... but B2B scenarios seem to be the chief target of WS-*, and in that realm it seems to me the obvious choice no?
James - sure it is possible to accomplish things different ways. One difference though is that WS-Security is reviewed by RSA and other security organizations to identify security flaws. The implementation you cook up for your REST app is not likely to undergo substantial peer review. We don’t write our own encyrption algorithms, right? Still I grant you that it is possible to screw up a WS-Security implementation and create a security hole. I am just saying that at least more parts of your solution have been proven out to a wider audience who has security skills.
Sam Smoot - I am referring to message level security so that you can protect the data end to end. SSL works as a point to point transport level security solution, in reality there are many more endpoints than just two, and there are lots and lots of intermediaries.
I am referring to message level security so that you can protect the data end to end.
Sure, but it’s turtles all the way down. At some point, the data is going to be separated from its integrity check. Message-level security hasn’t proved compelling with TLS yet, because those transfers are opaque to intermediaries. Sending reusable credentials and messages over HTTP+TLS is extremely common, so the goal of the discussion should focus on preventing the endpoint from impersonating the sender. That’s why I agree with you that AWS is a good example we should build on.
I realize your definition of “intermediary” includes the endpoint of an HTTP transfer, but I don’t think you’ll be able to communicate with HTTP implementors very well if you insist on your personal definiton.
Gunnar, I’m still not clear on how SSL client-certs fail where WS-Security presumably succeeds.
Client-certs are based on a public/private keypair AFAIK. In other words the data you would need to successfully intercept a transmission, and decrypt it, just isn’t present since it’s never sent. Much the same way you don’t transmit your private GPG key when sending an encrypted message.
I’m not sure how WS-Security is supposed to be anymore secure than that. It’s not like you’re going to be transferring around encrypted messages at the application level.
I could have the wrong impression of the mechanics of client-cert handshakes though... feel free to set me straight.
I think this is where quantative analysis comes in and a measured assessement of the risk is taken. What has to be protected and what’s the worthwhile cost of doing so? Being software people, that’s beyond the general state of the art. We do gut feelings, flames and opinions.
I agree that it’s important to listen to the other side but can the leopard see the sloth if it farts? For example, this is from 2002 [1] when I was still reading every XML-DEV message:
—
“It is not a key exchange issue. With SOAP, you can easily separate routing information and data so that you can encrypt head and body elements independently, REST does not. Cool thing about SOAP approach is that you can sign with multiple keys so that no only routers don’t know about the content, routers themselves don’t know where it will eventually end up.
If you do come up with some standard structure to do the same in REST, you are basically reinventing SOAP.”
—
I think listening isn’t the problem. It’s just that both sides have turned into fanatics with good hearing, who see each engagement as a battle to win over.
As far as I am concerned, REST and SOAP are both tools. It’s better to focus on what each tool is better at than fighting over which is better.
I completely agree with Don Park “As far as I am concerned, REST and SOAP are both tools. It’s better to focus on what each tool is better at than fighting over which is better.” In fact where I am trying to get this conversation is to look at REST using HMAC (as Amazon does) and other message level security design patterns. That is the sum total of my ask right now.
Don Smith said it best “The message is king ... and the contract is queen”
“Using the methods outlined by the researchers, a hacker could siphon off thousands of PIN codes and compromise hundreds of banks, said Odelia Moshe Ostrovsky, the report’s principal author. Criminals could then print phony debit cards and simultaneously withdraw vast amounts of cash using ATMs around the world, she said.
...
Word of the apparent security flaw first surfaced two weeks ago, when Ostrovsky and other researchers at Algorithmic Research (ARX) published a paper stating that it would be possible for someone with access to the ATM network to attack the special computers that transmit bank account numbers and PIN codes, called hardware security modules.
When consumers enter their personal identification numbers, or PINs, into an ATM, the PIN and account number must travel through several computers on a special network before they arrive at their home bank for verification. The data is encrypted immediately after it’s entered at the ATM into what is known as a PIN block, then sent on its way.
Rarely does the transmission go directly to a consumer’s bank. Instead, it is handed off several times on a banking network run by several third parties. Each time a bank passes the data along, it goes through a switch that contains the hardware security module and the PIN block is unscrambled and then rescrambled. It is at these intermediate points where hackers could trick the machines into divulging PINs, the ARX researchers said.
“We show in these attacks that using only (a single) function we can reveal the content of every PIN block as if it’s not encrypted,” said Ostrovsky.
PINs thought to be unassailable in transit
The attack theory is significant because it has long been considered impossible to access PINs as they are traveling through the ATM network without the encryption key used by the card-issuing bank. But the ARX report said issuer keys are not necessary because computers along the network can be tricked into revealing PINs through a series of electronic queries that would enable criminals to make educated guesses about – and possibly break — the encryption code.”
Any similarity to corporate data centers is strictly unintentional.
It seems to me that if you have a web front end to any critical part of your business, then it doesn’t matter if you use other security systems elsewhere. There needs to be a mechanism to make that simple HTTP interface secure. If it’s not, then you’ll get attacked that way. If you make it secure, then you may as well use the same mechanism throughout your system. Using more than one security mechanism in a business only increases the attack surface and development costs.
Some people in the REST community are able to see the need for message level security so this is heartening somewhat. If the data is distributed and the security model is point to point (at best), we have a problem. It is a gap in REST today that...
“What puzzles me is the one size fits all mentality I see everywhere.” - Sam echoes Roy Fielding; unsurprisingly, i agree - the one thing i’d add, however, is that REST has been forced to fight harder, b/c of the marketing around WS-*...
So the thing folks are talking about this week is security in REST. I figured it would be a good opportunity to once again highlight one of the cool features of Abdera… the fact that you can Digitally sign and/or Encrypt Atom feeds and entries with...
Sam Ruby: Equal Time “What puzzles me is the one size fits all mentality I see everywhere.” - Sam echoes Roy Fielding; unsurprisingly, i agree - the one thing i’d add, however, is that REST has been forced to fight harder, b/c of...
What puzzles me is that in this debate the good arguments and interesting issues are blured by branding icons. One of the good reference about these adorations is this weblog post. [link]
REST and SOAP are orthogonal.
Now indeed sometimes people are using tanks to deliver a pizza, and some others are using a bike to jump from the cliff. Not very useful in both cases.
Another bout of web services “religious war” has broken out again. We’ve been here before! This time it’s based on one funny and accurate diatribe about SOAP. The resulting frenzy in the blogosphere has yielded some quality comments, and even some declarations of victory by those who think REST is the one true way.......
[more]