« April 24, 2006 | Main | April 26, 2006 »
Tuesday, April 25, 2006
Fourmilab: HotBits Secure Server Request Form Now Delivered Via HTTPS
When I recently implemented secure HotBits requests via the https: protocol, I did not use HTTPS in the link to the secure request form from the main HotBits page. I figured that since nothing in that page was secure, there wasn't any reason to burden the server by requesting it with HTTPS; the random data would be requested and returned securely, and that's what mattered. Well, as is usually the case in questions of security, things are a bit more subtle. A few days after I posted the update to HotBits, this Handler's Diary from the SANS Internet Storm Center came to hand. While it focuses on bank login pages, the underlying issue applies to any site which receives or delivers sensitive data using HTTPS. Secure connections provide two things: protection against the data being intercepted, and authentication: confidence, based on verification of the site's certificate and the authority which issued it, that you're actually talking to the site you believe you are. While the former doesn't require the login page (or, in the case of HotBits, the request form) to be delivered via HTTPS, the latter does. Let's see how a malefactor might exploit non-secure delivery of the request form, using HotBits as an example. (Granted, the stakes with HotBits are so low this isn't likely to happen, but if you mentally replace a HotBits request with the user name and password of your on-line banking service, you'll see how serious this could be.) Suppose some chapeau noir discovered that HotBits were being used for a security application worth compromising. They might, then, throw out bait intended to lure the unsuspecting to a bogus site, perhaps with a name which is a simple misspelling of “fourmilab” likely to entrap elbow-typers who regularly strike out when posting messages on public discussion boards: “forumilab.ch”, say. Then, they might pollute the Web with “link farm” pages which wrapped the word “HotBits” with a link to a URL pointing to this impostor site, in the hope it would pop out of search engines. When a user arrived at the bogus site, everything would look precisely like the legitimate site, but when a secure data request was received, a copy of the data returned securely to the user would be saved, along with the requester's IP address, with the intent of nefarious exploitation in the future. By making the request form secure, the user is at least guaranteed that there is a certificate containing the name of the site they believe themselves to be accessing which their browser deems secure (or they've opted to accept after having been warned). In the case of the misspelled domain name, this doesn't help much, since if the user doesn't notice the spelling error in the URL, they probably won't notice it even if they choose to verify the certificate, but at least the information is there for the perspicacious. In the case of trolling for passwords, the stakes are much higher, since an innocent (but spelling-impaired) user might type his password into a non-secured page on a site named, say, “bankofamercia.com”, thinking they were connected to Bank of America. Indicative of the seriousness of this threat is that fact that Bank of America has registered this misspelling (among many others, including “bankofamerika.com”—hee, hee, hee) to preempt such entrapment of their customers.Posted at
00:16
