Signed HTTP with static and dynamic content as a security enhancement against silent defacements
In case a webserver gets defaced a black hat might change vital information with massive danger for the normal surfer. If for example a banking web portal site containing a link to the online banking login screen gets changed pointing to the black hats identical mirror of the login screen (as happend here some times already) he will get his hands on real banking accounts. The encryption via SSL of already defaced data will be no solution at all. SSL is only a counterpart in this scenario to ensure the connected web server is the right one and to dis- able data sniffing on the wire. The solution to this case might be signing all HTTP-accessable con- tent including static and dynamic HTML pages. This solution even keeps an eye on dynamic portal content, as most starting pages now have dynamic content on it, starting from the current time to brokerage news. Best solution would never the less be to have the critical data within static pages. We can sign any URL based content because the signature doesn't get into the content sent, but into the HTTP reply headers. So we don't modify any data. The HTTP reply doesn't need any change within the web- server source code but can most times be configured by standard configu- ration ways. Signing not only HTML but possibly any critical data is needed for example with a flash movie who display critical data like online broker- age data. This data might be forged by replacing a lying flash movie with possibly bad consequences to stock rates. One shouldn't underesti- mate the criminal energy in these cases.