Evidence From the Web: How to Prove That That Data Was Actually There
Some years ago the servers of my preferred online game went down for some days and I already feared my in-game character to be lost and dead with all its achievements. Fortunately they solved their problems and some days later everything was online again. I wanted to be prepared for the next incident of this type, so I logged in on their website and made a screenshot of all my character’s properties.
For a moment I was happy. Next time – even if all data was lost – I could prove what I had won and would get all my stuff back. Then I looked at my screenshot and realized that I equally easily could modify it to get even better in-game items. So it basically was worthless. Digitally signing it myself would not improve on that.
This scenario is not limited to online gaming. Being able to prove that an order has been placed, an offense has been made or any task has been fulfilled seems to be worthwhile to invest some general consideration.
Obviously you can not make and sign such a screenshot yourself. One needs the help of some trustworthy third party, but often the issue is too trivial to involve or even pay a “real world” lawyer. Your first thought might be to check if some web archiving sites like archive.org by chance could have a copy of that page. Often they don’t. And even if so, they could never have accessed the parts protected by login.
No automatic tool can master the steps of the login process and if the website owners consider using a captcha there is little hope that a program could ever bypass it. This has to be done by hand and by a web browser. So some people try using plug-ins saving and digitally signing all data sent from the server.
Again, this is not the solution. It is relatively easy to manipulate DNS or routing on your machine to have another computer or even a virtual machine play the role of “the server”. Browsers protect against this type of fraud by using SSL and certificates, but this only applies to encrypted traffic and installing your own “root-certificate” to allow man-in-the-middle manipulations is common practice.
Carefully checking the keys used might expose such methods. If all data transmitted was encrypted by asymmetric codes like RSA this could even be considered already signed by the originating server almost annihilating the problem. But for performance reasons in SSL asymmetric methods are only used to transmit key phrases for faster symmetric encryption. So faking a log of the encrypted code of the data actually transmitted is theoretically possible for the client, as it knows that symmetric key (while probably being even more difficult than reverse engineering some plug-in).
To avoid all these problems the browser must not run on your own computer. What one needs is a so called “remote controlled browser” (ReCoBS) as it is used – for completely different reasons – in high security facilities. This is a browser running on a different computer, controlled by a third party, sending only a video stream of its windows to the client and only accepting a limited set of commands. This remote browser can perform all the logging and signing operations as it cannot be manipulated by its user.
What paths of attack against this system have to be considered? First there is a chance of actually hacking the whole ReCoBS. Having a browser being controlled by some remote and possibly unknown user is of cause a risk in itself. The browser has to run inside a tightly locked down sandbox, not only protecting the system against hacking, but also preventing interdependences between parallel or subsequent sessions on the same computer,
When it comes to faking results of web sessions DNS cache poisoning seems to be the most dangerous option. This can be addressed by using DNSSEC when this someday includes whole the web, or possibly by having a net of machines around the globe and routing the DNS request by a random one. Script injections on the websites visited are a second way to get manipulated results, but there cannot be a working countermeasure by the ReCoBS if the injection comes from a fourth party, and being open to such an attack in the first place should be a bigger problem to the affected site than the logs created by this.
Even considering these issues ReCoBSes still appear to be the only option at least offering a theoretical chance of believable evidence. If implemented correctly they may work. Most other technologies are flawed by design and it’s just a question of time until public exploits will be available.