Re: Secure web page?


comphelp@xxxxxxxxx (Todd H.) writes:
For what it's worth this is a common fallacy and doesn't tell the
whole truth.

All SSL ensures is that the transport of data between your web browser
and the server is securely encrypted and safe from man in the middle
eavesdropping (assuming the certificate you accept is valid, and
issued by a trusted authority to the website you think you're
connected to, blah blah blah).

the original SSL for web commerce and the payment gateway
http://www.garlic.com/~lynn/aads5.htm#asrn2
http://www.garlic.com/~lynn/aads5.htm#asrn3

had the browser checking that the URL domain name typed in by the user
matched the domain name in the domain name digital certificate
.... after otherwise validating the digital certificate as valid. some
of the exploits might be considered partially because certification
authorities continuelly stressed the integrity and value of these
digital certificates (at the expense of recognizing that digital
certificates were a very small part of an overall end-to-end process,
as well as not the only possible implementation).

one vulnerability that opened up was that e-commerce websites found
that SSL encryption introduced an 80-90 percent overhead (i.e. they
could handle 5-10 times as much web activity with the same equipment
if they didn't use SSL). as a result, majority of SSL use was moved
from the initial webserver connection (from the URL that the user
entered as part of connecting to the website) ... to just being used
for handling the payment process (in the overall webserver
experience).

what you saw was the user getting into a purchase screen and being
asked to click on a "payment" (or check-out) button. this button
supplied the URL to the browser for doing payment SSL operation.

the threat is that SSL is no longer being used to validate the URL
domain name connection to the webserver that the user entered ... it
is only be used to validate the domain name connection to a payment
webpages ... using a URL and domain name supplied by the remote
webserver. Now, if the user had originally connected to a fraudulent
website because SSL is no longer being used to validate the original
connection (which the original use of SSL caled for), then the
fraudulent website will probably provide a URL and domain name for
which the crook actually has a valid certificate for i.e. the attacker
registers some valid domain name and then obtains a valid certificate
for that domain name. then they design a payment button that supplies
a domain name URL for which they have a matching digital certificate.

this exploit can even be implemented as a man-in-the-middle attack
.... the fraudulent webserver (that the user is directly talking to) is
simulating a second session with the real website (so the user is
actually seeing real-time information coming off the real website).

misc. past posts on MITM-attacks
http://www.garlic.com/~lynn/subpubkey.html#mitmattack

misc. past posts on general subject of SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

recent posting discussing what SSL encryption is addressing
by hiding account numbers for transactions transmitted
over the internet
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
.

Quantcast