Secure web page?

Discussion in 'Computer Security' started by Dave, Feb 22, 2006.

  1. Dave

    Dave Guest

    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, Feb 22, 2006
    #1
    1. Advertising

  2. 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, Feb 22, 2006
    #2
    1. Advertising

  3. Dave

    Todd H. Guest

    "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., Feb 22, 2006
    #3
  4. (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, Feb 22, 2006
    #4
  5. Dave

    Dave Guest

    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, Feb 23, 2006
    #5
  6. 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, Feb 23, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Phil
    Replies:
    7
    Views:
    1,050
    Wyatt M. Portendt
    Mar 4, 2004
  2. Colin Nowell

    Secure & nonsecure items on a web page

    Colin Nowell, Aug 22, 2005, in forum: Windows 64bit
    Replies:
    4
    Views:
    471
    Colin Nowell
    Aug 23, 2005
  3. Miss Mary
    Replies:
    1
    Views:
    1,438
    sean.archer
    Sep 21, 2007
  4. Replies:
    0
    Views:
    558
  5. Replies:
    0
    Views:
    601
Loading...

Share This Page