|
Posted by Dave on February 23, 2006, 2:25 pm
If you were Registered and logged in, you could reply and use other advanced thread options
I have not used the web site and will have a look through your
comments/suggestions.
No its not walmart but how does DRM files foul things up?
Dave
>
> comphelp@toddh.net (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/
| 
XML site map