Hi John, Am Freitag den, 21. Juni 2002, um 18:31, schrieb John Stracke: > I disbelieve. All he would've had to do would be to modify the login > form handler instead of the form itself. As you've described it, > SigHTTP does nothing for dynamic content. I told the case too short. In real it was a combination of two servers. The one central server, highly secured, used by multiple banks, containing the programming, database and so on. A normal webserver as a starting portal for the bank clients, not very secure because 'they' thought it is of no security importance. The intruder managed to change the starting html pages and direct the users to his own copy of the above mentioned central server. These start pages are mostly of a static nature, only minor dynamic parts like timestamp, etc.. I think it may be better so sign these pages too, so a changed link to a fake server would not be possible. The real link was only an ip number, as was the changed one, so a normal user would not recognise the change. > So how does the browser distinguish between a page whose signature was > deleted by an attacker and one whose maintainer has stopped using > SigHTTP? I see now way of telling the difference between something missing intentionally and deleted. It would be the duty of the user to check for the status of the page. In case of https/SSL he has to check for the existence of the https:// or gets some browser popups informing him or sees the keylock symbol in the browser. In case of SigHTTP he would have to look for some similar sign of a SigHTTP plugin or stand alone tool in the tast bar to check for him. Otherwise: Are there any positive comments available for pushing up my weekend? :-) with kind regards -- Think Saftey www.security-gui.de & www.sighttp.org