Comments: memes in infosec IV - turn off HTTP, a small step towards "only one mode"

an original HTTPS deployment requirement was that the end-user understand the relationship between the webserver they thot they were talking to and the corresponding (HTTPS) URL that they supplied. Another requirement was that *ALL* Certification Authorities selling SSL/HTTPS domain name digital certificates operate at the same (very high) level of integrity.

almost immediately, the original requirement was negated by merchant servers that dropped back to using HTTP for the most of the online experience (because HTTPS cut thruput by 90-95%) and restricting HTTPS use to pay/checkout portion, accessed by a "pay/checkout" button (supplied by the unvalidated website). Clicking on HTTPS URL buttons/fields from unvalidated sources invalidates the original requirement, since it creates a disconnect between the webserver the user thinks they are talking to and the corresponding URL (that is personally known to them). Since then, the use of "click-on" URLs have proliferated widely resulting in users having little awareness of the corresponding URL. The issue/short-coming is that browser HTTPS only validates the equivalence between the webserver being talking and the supplied URL (it does nothing to establish any equivalence between the supplied URL and what the end-user believes that may URL represent).

In this environment, nearly anybody can buy a SSL domain name digital certificate for a "front" website, induce the end-user to "click-on" a field that claims to be some other website (which supplies their HTTPS URL to the end-user browser), and perform a MITM-attack with a modified PROXY server that establises a (separate) HTTPS connection to claimed website. Their are a pair of HTTPS sessions with the fraudulent website in the middle (MITM-attack) with the modified PROXY providing the interchange between the two sessions (transparent to most end-users).

With the proliferation of zombie machines and botnets, their could be a sequence of paired sessions, so the valid website isn't seeing a large number of different sessions originating from the same IP address.

Of course, with the progress of zombie machine compromises, the attack can also be performed with a compromise of the end-user's browser (eliminating any requirement for intermediate PROXY server). The latest sophistication of such compromises target very specific online banking services ... performing fraudulent transactions and modifying the results presented to the user (so that the fraudulent transactions aren't displayed).

The compromise of the end-user machine was well recognized and researched threat in the 90s and contributed to the EU FINREAD standard in the later 90s. The EU FINREAD standard basically added a separate hardened box as the end-point for financial operations, with its own display and input. Each financial operation was (accurately) displayed on the box and required explicit human interaction (eliminating transactions w/o the user's knowledge or transactions different than what the end-user believed).

The EU FINREAD standard ran afoul of some deployments of other add-on "secure" boxes which were done with serial-port interfaces. The difficult consumer problems with add-on serial-port attachments had been well known since the days of dial-up online banking (before the migration to internet). The enormous consumer problems with the serial-port attachments led to quickly spreading opinion in the industry that all add-on secure boxes were impractical for consumers (when it actually was that add-on serial-port boxes were impractical for general market ... which was also major motivation behind creation of USB).

There is little evidence that internet in-transit evesdropping has been any kind of significant threat (HTTPS encrypting information as countermeasure to evesdropping information being transmitted). The major exploits have been end-point attacks of one sort or another.

Posted by Lynn Wheeler at August 21, 2010 11:55 AM

# If we need any special Directory permissions
<Directory "/var/www/sites/www.makeanexample.org/">
Options +ExecCGI
Order allow,deny
Allow from all
</Directory>
# If we need any special handlers for specific locations
<Location "/">
</Location>
# The non-secure VirtualHost
<VirtualHost *:80>
ServerName www.makeanexample.org
ServerAlias makeanexample.org
Redirect / https://www.makeanexample.org/
</VirtualHost>

# The secure VirtualHost
<VirtualHost *:443>
ServerName www.makeanexample.org
ServerAlias makeanexample.org
DocumentRoot "/var/www/sites/www.makeanexample.org/"
AddHandler cgi-script .cgi
</VirtualHost>

Posted by Kyle H at September 2, 2010 03:47 AM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x5585cbfb4658) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.