1 Raindrop

Neal Stephenson on Transport Level Security Versus Message Level Security

Update: see this post on REST Threat Models and Attack surface for more ideas

As a security architect, do not assume that you know all the intermediaries and endpoints your message will traverse. Let's go back to 1670 -- from Quicksilver:

The heat was too much. He was out in the street with Uncle Thomas, bathing in cool air.

"They are still warm!" he exclaimed.

Uncle Thomas nodded.

"From the Mint?"

"Yes."

"You mean to tell me that the coins being stamped out at the Mint are, the very same night, melted down into bullion on Threadneedle Street?"

Daniel was noticing, now, that the chimney of Apthorp's shop, two doors up the street, was also smoking, and the same was true of diverse other goldsmiths up and down the length of Threadneedle.

Uncle Thomas raised his eyebrows piously.

"Where does it go then?" Daniel demanded.

"Only a Royal Society man would ask," said Sterling Waterhouse, who had slipped out to join them.

"What do you mean by that, brother?" Daniel asked.

Sterling was walking slowly towards him. Instead of stopping, he flung his arms out wide and collided with Daniel, embraced him and kissed him on the cheek. Not a trace of liquor on his breath. "No one knows where it goes--that is not the point. The point is that it goes--it moves--the movement ne'er stops--it is the blood in the veins of Commerce."

"But you must do something with the bullion--"

"We tender it to gentlemen who give us something in return" said Uncle Thomas. "It's like selling fish at Billingsgate--do the fish wives ask where the fish go?"

"It's generally known that silver percolates slowly eastwards, and stops in the Orient, in the vaults of the Great Mogul and the Emperor of China," Sterling said. "Along the way it might change hands hundreds of times. Does that answer your question?"

Transport level security assumes good security on both endpoints in a point to point scenario and everything beyond those endpoints within the transaction span. Message level security lets the message traverse numerous business, organizational, and technical boundaries, with a modicum of security intact.

REST Security (or lack thereof) part deux

Update: see this post on REST Threat Models and Attack surface for more ideas

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 due to REST's reliance on HTTP, that message level security is an exercise left to the implementer with no open, proven standards to back them up. It doesn't always have to be this way. Maybe some smart software organization can build something that provides these properties for the REST crowd, and get them reviewed. For the time being it is still a gap for REST, which Don Park knew back in 2002:

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.

Right. we don't want the postal worker reading the contents of the envelope, just the addressing header to name on example. I don't have a dog in the REST vs. WS-* hunt, my main concern is the security issues. As Don Smith says - "The message is the king and the contract is the queen." If you want to shrink your perimeter to the message level you can use WS-Security or attempt to roll your own with REST.

Pete Lacey's post restates a bunch transport level security mechansism which offer no message level security:

The standard RESTful security approach is, of course, HTTP Basic or HTTP Digest or SSL certificate-based mutual authentication for propagating identity credentials (the actual act of authentication and authorization being the purview of the server) and SSL for data integrity (digital signatures) and data protection (encryption)

SSL helps with channel security (while rendering the IDS and NSM people blind I might add). He goes on to say

Gunnar notes that these technologies were state of the art in 1995, with the implication they are no longer sufficient for meeting the security needs of the 21st century. This is an example of what I call the “Gilligan, you can’t fly” argument; that is stating that something can’t be done even as somebody else is doing it. The fact is that billions of dollars of worth of business is conducted every year over because of SSL.

Yes, Pete, I honestly do believe that attacker have evolved since 1995. The above statement (and I have heard it many times so he is not alone) tells you what we are up against from a software security standpoint.

Luckily, Robert Sayre agrees that RESTians can learn from the AWS developer token example with regard to dealing with spoofing:

"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."

AWS is the best publicly used example I have seen so far. He also has a good post here that gets to one of the main issues:

When I read posts like that, I often wonder how the following sentence from the REST thesis fits in.

"REST component interactions are structured in a layered client-server style, but the added constraints of the generic resource interface create the opportunity for substitutability and inspection by intermediaries."

We have a thriving credential theft industry on our hands, so I'm not sure we can claim TLS is an undeniable success. It's true that many phishing sites don't bother turning on TLS. They don't have to, because lots of banks and things don't serve their credential forms over TLS. They don't have a pleasant choice. It should be obvious that a data stream opaque to intermediaries has several desirable properties, but scalability and reusability are not among them. Besides, it's not like it's impossible to improve on Basic, Digest, and Forms with Cookies. Here is a Python example.

"Both of these standards address identity propagation, message encryption, and message integrity only, and neither will protect you from the threats just mentioned."

Well, some of WS-Security might. I am afraid to read it. I can tell you that the example above will prevent hostile servers from reusing credentials, unless they have broken more than one cryptographic primitive.

I cannot remember an app since 1998-99 that didn't have layers and layers of intermediaries.

Paul Downey says:

I trust the water piped directly to my house, but I’m more careful when it comes to packages which flop through my letterbox. A signed-sealed envelope delivered by a courier boosts my confidence, but helps a lot more if I know who sent it. So whilst WS-Security offers a little more than just TLS, it’s the thought and effort being expended to establish and exchange identity that currently gives WS-* the security edge over REST. It’s great to see that RESTians are starting to at least see the issue

And I totally agree with Don Park's assertion that:

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.

If I need message level security today, my choices are limited. So just in case people are sitll wondering why we'd need message level security in some cases perhaps this story is helpful

“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.

Any similarity between this and corporate data centers is strictly uninentional

“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.”

Ostrovsky said her company shared the research with the Visa credit card association’s risk management team and other U.S. financial industry security experts six months ago, and recommended systemwide ATM network changes. But U.S. banks weren’t reacting fast enough to the risk, she said, so ARX decided to go public with its information and two weeks ago published a paper titled “The Unbearable Lightness of PIN cracking,” which is now available on the Internet (in Adobe Acrobat format).

Kim Bruce, a spokeswoman for the Secret Service, confirmed that the agency had been in contact with ARX to discuss the paper’s findings, but declined to provide additional detail.

Some questions to ponde. Where does your app terminate SSL? AT the firewall? At F5? At the web server? What is the lifecycle of the data that your REST app sent? How is the message itself protected?

Russian-language Web sites are abuzz with discussions about ATM network attacks, including discussion of the Israeli report, according to data gathered by the Secret Service and viewed by MSNBC.com.

“In the fall of 2005 work for everyone was so successful because an employee of one of America's processors sold a database of material that went through its processing center,” wrote a hacker who belongs to an online gang called Mazafaka, according to an English translation of a Russian Web site compiled by the Secret Service. “This material was then successfully exploited by our carder friends. The consequences of this deal could even be monitored on CNN, as well as in our own work (this applies to cashers). You may have noticed that after this event, ATMs more and more frequently give ‘transaction declined’ notices or give a small sum on the first transaction and then block the card.”

In another exchange cited in the Secret Service memo, a hacker offers to pay for databases of encrypted PINs, which theoretically should be useless someone had discovered a way to translate the data into valid PINs. In still another post, one claims to have recovered account data by “hijacking” hardware security modules

The biggest issue beyond he point to point nature of SSL is that it is an all or nothing proposition

The attacks described in the ARX paper could not be conducted remotely over the Internet. They would require a criminal to be on the same local network as the hardware security module. Because ATM switches are heavily guarded and monitored, such access is unlikely, argued a BITS representative, who spoke on condition of anonymity.

But such ATM switches can be located anywhere in the world, Ostrovsky countered. That creates a “weakest link” vulnerability in which one poorly guarded switch could theoretically be used to compromise every bank whose debit cards have flowed through that switch, she said.

Each switch contains a hardware security module, which is a simple computer in a tamper-proof box designed to perform a few PIN-related functions, beginning with decrypting and encrypting. But the boxes also contain other small programs, or functions, which allow the machines to change a customer’s PIN or calculate other PIN-related values. Most ATM switches don’t need these tools; however, they are often available by default.

This unnecessary software is exploited in some of the attacks described by ARX, which recommends that switch operators turn off the unnecessary functions. But even that’s not enough, Ostrovsky said. The one essential function of a switch -- encrypting and decrypting, a process known as “translate” -- is all an attacker needs to trick the machine into divulging PINs, a hack that would put nearly every ATM switch at risk, she said.

“This is not an attack on a certain configuration or installation. This is an attack on the protocol itself. It must be updated,” Ostrovsky said.

There are competing protocols, or PIN block formats, in use in the ATM network, and each machine must support all those formats, she explained. In one version, the 16-digit PIN block contains two formatting characters, four PIN characters, and 10 additional slots with information about the customer’s account number. That’s the standard used in the U.S. Another standard combines the formatting characters and PIN characters with random digits, and sends the account number separately.

The translate function not only assists in encrypting – it also allows the machine to translate the PIN block from one format to another. This allows an attacker to take advantage of the weaknesses of both, creating“least-common denominator” vulnerability, Ostrovsky said.

The BITS representative who spoke on condition of anonymity conceded such attacks are feasible, but called the risk “very, very, very, very remote.” He added that bank robbers have much easier ways of stealing money than complicated PIN prediction tactics.

Litan is not so sure. She said the research paper undermines the basic premise of ATM network security – the idea that only a computer loaded with the encryption key created by the issuing bank can reveal a PIN.

“The premise was ‘It doesn't matter what happens along the path,’ so even people who could access the PIN blocks couldn’t do anything with them,” she said. “This blows that out of the water.”

And finally

Bank industry officials point out that the attacks must be carried out by someone with direct access to an ATM switch, limiting the potential for abuse. But Litan said the limitation is hardly reassuring.

“It’s not much comfort that they have to be on the inside,” she said. “As we’ve already seen, it’s easy for criminals to open up their own ATM network. And banks do have insiders with flaws.”

I think a technology that is geared towards interoperability, should be able to have an end to end security model which accepts there will be multiple intermediaries in play. Brian Snow termed this "if we cannot trust, how can we safely use?"

REST Security (or lack thereof)

Update (since this post is linked from multiple places): see this post on REST Threat Models and Attack surface for more ideas on REST current state security options

So the whole REST security thing just gets funnier, the S for Simple folks forget that S also stands for security. Here was a response to my post on the fact that people who say REST is simpler than SOAP with WS-Security conveniently ignore things like, oh message level security:

HTTP Basic or HTTP Digest or SSL (certificate-based) for authentication. SSL for encryption and digital signatures. You know, the way we've been doing things since 1995.

Where to start? Right, it was state of the art in 1995. no bout a doubt it. The world has moved on slightly since then. You know a couple 97 million stolen identities, endless phishing/pharming (growing double digit pct each month), malware taking 60% cpu utilization on consumer desktops. You know little stuff like that

HTTP Basic? The hell you say. Here is a round up of ways to break and/or bypass that. There are only 5 listed however.

Report:

Warning of Al Qaeda cyber attack on finance sites
The US government has warned financial services companies of an Al Qaeda call for a cyber attack against online stock trading and banking websites beginning today

Don't worry about that boss, I put HTTP Basic in front of our apps!

SSL? My friend Daniel opined thusly about the wisdom of SSL and REST:

It's nice to run it all over HTTPS, so now the
gigantic hole you made in the firewall will provide some privacy for
me as I dig through your customer's credit card numbers...

You just have to love a point to point security model in a system that last time I checked is supposed to be about interoperability.

Hey boss, where should I put that SSL thingie again?

Now if you are at all serious about putting some security mechanisms in to your REST there are some good examples. One being Amazon's developer tokens using HMAC for authentication at the message level (you know where the data is). But if you are going to say that REST is so much simpler than SOAP then you should compare REST with HMAC, et. al. to the sorts of encryption and signature services WS-Security gives you and then see how much simpler is. And, you know, maybe even see, oh golly gee I don't know, which one protects your customers' data better? Until then, we'll just continue (as Gene Spafford said) using an armored car to deliver between someone living in a cardboard box and someone living on a park bench.

Update: Part 2 (in which we achieve after fashion and many comments something resembling consensus and an action plan to improve REST security) is here

Weak Post from a Smart Guy

I have learned a lot from Tim Bray but this is just so weak and lame::

S for Simple
I feel guilty sometimes about the lull in my WS-Rants, because the forces of WS-Complexity and WS-Darkness are out there evangelizing tirelessly.

Weak.

S also stands for "Security" please wake me up when the REST people actually put security mechanisms in their stuff. Then we'll see how much simpler it is. Until then this is strictly amateur hour. "Look Ma, I can throw a bunch of random unauthenticatable, unauthorizable bits across the wire! Soooo much simpler than worrying about security. You should be proud! Oh wait, was that your bank account information I just posted? Dang."

C'mon Tim, you are better than this. I am all for bashing bloatware or whatever, but let's compare apples to apples. TIA.

Is it really that hard to have Web 2.0 and security, too?

WResting Security Interop

Andre Durand posted some thoughts of mine WS-* and REST

WS-* and REST are often portrayed as competing technologies. While the use cases they deal with do overlap in some cases, there are many instances where each will have its logical place in a given system architecture. Both WS-* and REST are focused on interoperability, so if any two technologies should be able to work together, it is these two.

REST's approach gives developers an efficient way to build and deploy web services using existing technologies that are typically already deployed and scaled out in the enterprise. REST does not provide frameworks to handle the declarative, configuration driven qualities like security, QoS, etc. that WS-* does, but that is not the point of REST. REST style services benefit from integration with security services such as authentication services that can provide increased assurance and security through strong authentication mechanisms like two factor, OTP, etc., as long as these services plug into the existing infrastructure that REST deals with.

Many of the core WS-* use cases are designed for transactional middleware systems like an enterprise service bus. REST was not designed for this purpose, though there are many cases where architects will want their REST services to integrate with their ESB. The goal of this integration is to enable the development and deployment efficiency gains that REST to plug into systems like an ESB and other WS-* systems by bridging the protocols with a STS that brokers communications and allows for a robust, integrated security model.

So what does all this mean to security architects? WS-* has a very useful set of security standards and tools. REST does not. WS-* has ways to deal with securing identity, messages, tokens, etc. while securing REST is more analogous to securing a web app - things are likely to be much more unstructured and customized. Each requires an unique security model, the integration point between the two security realms benefits from interoperability in the security service like a STS that exchanges tokens between the two realms.

Is AJAX Security DOA? Amit Klein at OWASP

I hope that all the AJAX and REST people will take the opportunity to review Amit Klein's work [1] on XMLHttpRequest among other attack patterns, so that the Web 2.0 people understand how absolutely trivial it is to subvert these schemes. SOAP/WS-*/SAML has added a lot of useful security mechanisms, but AJAX may be DOA looks to be security standpoint.

Since Web 2.0 has improved on lots of Web 1.0 features, can they also please update their not sufficient for Web 1.0 security model while they are it?

Andrew van der Stock has some slides on the litany of problems that is the Ajax security oxymoron.

Web 2.0 and Security Too?

Luke Razzell points to an article by Dion Hinchcliffe on REST vs. SOAP. Of course, everyone loves to compare SOAP and REST, but the comparison is usually based on what is best (read:easiest) for the developer. This is certainly a concern, but it is far from the only one. The article on REST's security model:

The actual XML message is contained in the HTTP request and security is provided by HTTPS, which is the secure version of HTTP. This, in a nutshell, is virtually everything that a Web service user or creator needs to know about REST.

SSL? Ok, deep breath. How can you say this Web 2.0 when your security model is not even sufficient for Web 1.0? Of course, there are ways of writing more secure code in a REST-ful way but they depend heavily on the correctness of the developer's implementation, and since we have 10+ years of evidence as to developer's "ability" to write secure web apps, this should cause concern. So when you need to deal with a REST vs. SOAP question, one of the things to analyze is how is REST going to deal with what WS-Security, WS-Trust, and SAML already do in a WS-* architecture, like encrypt and sign messages, and suppot multiple token types.

When it comes to security, SOAP v. REST is not a zero sum game. Security support can be:

a) in the framework (declarative)
b) in the code (programmatic)
c) both of the above
d) none of the above

Simply ruling out choice a for developer convenience is not a fair tradeoff.

WS-* and REST Security Interop

The WS-* v REST debate rumbles along, one thing I have never understood is why when a new technology or language comes into play it suddenly has to answer all existing use cases? There are some use cases which are better suited to WS-* and some that are better suited to REST, there are even some where it makes sense to use both at different layers in the system. From a security standpoint REST has a ways to go to deal with the use cases that WS-* does, however one of my "real world" architectural rules of thumb is that "working code trumps all", and so REST gives a more efficient path to that and so you have cases where you may need interoperate becasue REST is already there and it did not require a bunch of infrastructure.

For example, how about a case of bridging a REST client that needs to speak through some app to get some data from a back end speaking SOAP/XML/WS-Secruity? WS-Trust can exchange the REST credentials for SAML assertions that may be used by the WS-Security message for access control by back end services.

Secure Your SOA: Web Services and XML Security at OWASP Europe

4/30 is the last chance for early registration for OWASP Europe. I will be teaching a one day class on Web Services and XML security -- the class focuses on the risks inherent in this programming model, what the standards are, how to use them, and where you still need to use custom code and configs to deal with the security issues. This is a variation of the classes that I provide for customers onsite

REST v SOAP debate impact on security services architecture

Mark O'Neill's RSA Presentation on Security for REST Web Services makes an important point for security architects who are dealing with developing security services for budding SOA initiatives - how will your security services (which rely on WS-* functions and SOAP) be able to deal in a RESTful web services paradigm? This is not a trivial question because while enterprise architects may design and purchase solutions that rely and mandate the former, developers can easily circumvent with a HTTP Get. Part of this gets back to a framework versus roll your own debate that I blogged awhile back.

Security architects cannot afford to take enterprise architect's whiteboard and Visios mandating a WS-* (or any technology) world at face value instead they must engage developers, BAs and other stakeholders to deal with the reality of runtime as opposed to policy and design time. XML in and XML out may be the design, but the runtime reality could well be HTTP Get in and XML Out under REST rendering the shiny new XML security based solution blind to large amounts of traffic.

Maximum flexibility to deal with different tactical deployment realities is an important property in security tools, not just compliance with Visio drawings. The ability to enable security protocols in integration scenarios composed of hetergeneous technologies and usage paradigms yields the widest risk management coverage. In this case it pays for security architects to be the fox not the hedgehog.

This is also why I think STS technology will be very successful, because the security protcols that STS and WS-Trust integrate: SAML, X.509, Kerberos, are generally putting arbitrary boundaries around technical domains while the business reality is the opposite - more integration not less. Protocols which continue to enforce isolation ultimately fail when their subjective, isolated concepts meets up with the integration objectives reality rendering the system as a whole less secure.