Secure web page?

Can anyone confirm if a website is secure or not.

If the web adress start https I understand it should be secure, however the
padlock does not appear at the bottom. So I called the site by phone and was
advised if i right click on the page and check properties it will show if
its secure or not. sure enough this works. The site said they are aware of
problem but havnt fixed it yet.

I thought it was automatic that the padlock apears - any suggestions.

Web site is a supermarket doing music downloads
Thanks Dave.

Dave

Dave wrote:
> Can anyone confirm if a website is secure or not.
>
> If the web adress start https I understand it should be secure, however the
> padlock does not appear at the bottom.

Your assumption is incomplete.
1. All contents of the websites must be included with HTTPS, or they're
assumed to be insecure. Denote that this is usually why Mozilla doesn't
display the padlock, or displays it as broken.
2. The certificate must match the server, didn't expire and has required
formats for all fields.
3. You can somehow verify that the certificate tells the truth. This is
usually done by checking that some trusted CA signed it, using a level
of certification that is secure enough (means: don't trust any Level 3
oder Level 4 certs, be careful with Level 2). And be aware that most
seemingly trusted CAs like Verisign, GeoTrust or Thawte aren't worth any
trust.

> So I called the site by phone and was
> advised if i right click on the page and check properties it will show if
> its secure or not.

Actually this is pretty useless, see above.
Well, my online banking support wondered why I asked for a technican
telling me the correct fingerprint whereas their cert was already signed
by Verisign.

> The site said they are aware of problem but havnt fixed it yet.

Request to put them on <http://www.cs.biu.ac.il/~herzbea/shame> and then
avoid them entirely. This is an unacceptable problem.

> Web site is a supermarket doing music downloads

You mean Walmart, which is selling DRM files to **** up your computer?

Sebastian Gottschalk

"Dave" <> writes:

> Can anyone confirm if a website is secure or not.
>
> If the web adress start https I understand it should be secure,

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).

> however the padlock does not appear at the bottom. So I called the
> site by phone and was advised if i right click on the page and check
> properties it will show if its secure or not. sure enough this
> works. The site said they are aware of problem but havnt fixed it
> yet.
>
> I thought it was automatic that the padlock apears - any
> suggestions.

There are instances out there where a password form on a non-SSL page
does send the password securely in its POST action.

It's hard to say more without seeing the specific page though.

--
Todd H.
http://www.toddh.net/

Todd H.

(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/

Anne & Lynn Wheeler

Thanks all for the comments
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


"Anne & Lynn Wheeler" <> wrote in message
news:...
>
> (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/

Dave

Dave wrote:

> No its not walmart but how does DRM files foul things up?

1. DRMed WMA is no WMA at all, according to the SMPTE VC-1
specification. -> fraud
2. A DRM software is an fact a trojan horse. It intentionally cripples
the system and hides the user's data from himself to ensure limited
ability to copy data. -> computer fraud
3. Typical DRM software implementations allow remote control to the
distributor. -> computer fraud
4. DRM technically breaks Fair Use. Once you've lost your licenses
(machine crashed and the !§#$% DRM software doesn't want to reimport the
backup) and the distributer is gone, your files have become garbage. ->
copyright infringement of the other kind

Sebastian Gottschalk