Secure Insecure Post



  •  at the bottom of the form they offer a "click to secure" button.  Clicking the button seems to trigger a POST action, to the SSL secured version of the page.  In order to not piss off users who already typed in their information, it posts that too so it can pre-fill the form.


    Thus their method of securing the form sends an insecure post with all the information you wish to secure first.

     



  • Well that's ok - nobody will notice them doing that because they do it quietly, so it's ok ;)

     



  • What is even the point of having the insecure version? It's not as if given an informed choice, any person will say "yes please I'll use the version that isn't secure". Perhaps the insecure version is there for people using some DOS-based browser that doesn't do SSL, but if aso, it shouldn't be the default!

    And to then POST any pre-entered data over an insecure connection for someone who has clicked the "yes please I want to be secure button"?

    Idiots. 



  •  Clicking the button seems to trigger a POST action, to the SSL secured version of the page.

    if the target of the POST action is https, there is nothing inherently wrong with this. A secure connection is established before any data is transmitted...



  • @herminator said:

     Clicking the button seems to trigger a POST action, to the SSL secured version of the page.

    if the target of the POST action is https, there is nothing inherently wrong with this. A secure connection is established before any data is transmitted...

    Nope. Look at the source of the page. The form submits to a normal non-SSL page. The "Click to Secure" icon is just a regular link that takes you to the SSL version of the page. i.e. If you don't  do the "click to secure" first, you're submitting all your information in the clear.

    Now the funny thing is that if you do "secure" the page, you get a nice little lock icon saying "Site is Secured", which is a link back to.... the non-secured page. "Damn, I didn't mean to hide my info. I *DO* want it visible to any and all who want to sniff the link..."
     



  • Also just noticed the disabled Ad banner links in the source. They're present in both the secure and in-secure versions of the page. Following a couple manually gets me a "Campaign Expired" page, but I'm guessing at some point they were live and active on both versions of the page. They're non-SSL links, so on the secure version of the page, people were probably getting "secure page contains non-secure content" warnings too.

     

    .... I wish security wasn't just a checkbox on marketroid features lists.

     



  • That little lock icon in the corner is all your average end user needs to feel secure.  In high school, I was "contracted" (read: forced) to build and maintain the schools web page.  What was on this web page?  Well the student handbook, this month's cafeteria menu, and any announcements of school closings.  Got an email from a parent chastising me for not making the site "secure" because the URL was http://vt_mruhlins_school.edu, not https://vt_mruhlins_school.edu.

    Yeah, I didn't reply.
     



  • I find it very disturbing that sites like amazon.com still don't secure the login process. Unless POSTing to an SSL page from a non-SSL page secures it before sending info, you are sending your login info (and therefore access to your account info) unsecured, with a button saying "Log in using our secure server." This is almost lying to the user!



  • @boolean said:

    I find it very disturbing that sites like amazon.com still don't secure the login process. Unless POSTing to an SSL page from a non-SSL page secures it before sending info!
    Which it does.  Research the HTTP/HTTPS spec.  You might find it enlightening.



  • Except that without encryption, the non-SSL page could be transparently rewritten to POST the data to an SSL site that the attacker controls. Apparently many banks in the US do this so they can have the Internet banking login on the home page, but don't have to setup an SSL connection for every connection. Very nasty stuff, especially when they tell you it's secure!


  • Winner of the 2016 Presidential Election

    I might be completely wrong about this, but as I understand it, HTTPS uses a public key to encrypt data on the way to the server, and a private key to sign data on the way back.  That is, only one direction is secured.  I've seen many sites that echo back the sensitive data you just sent encrypted, under the assumption that this will also be encrypted.

     Someone please tell me I've got this wrong.



  • @joe.edwards@imaginuity.com said:

    Someone please tell me I got this wrong.

    Yup.  Completely.



  • @joe.edwards@imaginuity.com said:

    I might be completely wrong about this

    And you are.  SSL and TLS start with a handshake phase where a private session key is generated.  That session key is used to encrypt traffic in both directions.



  • @joe.edwards@imaginuity.com said:

    I might be completely wrong about this, but as I understand it, HTTPS uses a public key to encrypt data on the way to the server, and a private key to sign data on the way back.  That is, only one direction is secured.  I've seen many sites that echo back the sensitive data you just sent encrypted, under the assumption that this will also be encrypted.

     Someone please tell me I've got this wrong.

    You don't understand public and private key encryption.

    Let's explain it a bit by using a conversation between you and me.

    Me: Generates a public/private key pair.

    You: Generates a public/private key pair.

    Us: trade our public keys, encrypt data to send using the others public key, decrypt received data using out private key.

    Basically what this does is anything you send to me you encrypt using my public key which I handed you.  The data is now secured and can only be read by someone that has the private key that is part of the pair.  No one else can decrypt this information, the public key is useless in this regard.  So all communication is secured using the public key provided by the receiver.  Only the receiver knows the private key so only he can decrypt it.  It doesn't matter if others know the public key because all they can do is encrypt messages and send them to the owner of that key as no one else can decrypt the message.
     



  • @KattMan said:

    @joe.edwards@imaginuity.com said:

    I might be completely wrong about this, but as I understand it, HTTPS uses a public key to encrypt data on the way to the server, and a private key to sign data on the way back.  That is, only one direction is secured.  I've seen many sites that echo back the sensitive data you just sent encrypted, under the assumption that this will also be encrypted.

     Someone please tell me I've got this wrong.

    You don't understand public and private key encryption.

    Let's explain it a bit by using a conversation between you and me.

    Me: Generates a public/private key pair.

    You: Generates a public/private key pair.

    Us: trade our public keys, encrypt data to send using the others public key, decrypt received data using out private key.

    Basically what this does is anything you send to me you encrypt using my public key which I handed you.  The data is now secured and can only be read by someone that has the private key that is part of the pair.  No one else can decrypt this information, the public key is useless in this regard.  So all communication is secured using the public key provided by the receiver.  Only the receiver knows the private key so only he can decrypt it.  It doesn't matter if others know the public key because all they can do is encrypt messages and send them to the owner of that key as no one else can decrypt the message.


    Public-key encryption is so slow that nobody actually does this.  What actually happens is something like this:

    Me: Generate a symmetric-encryption key.  Use that to encrypt the message.  Encrypt the symmetric-encryption key using your public key.  Send both the encrypted key and the encrypted message to you.

    You: Decrypt the symmetric key using your private key.  Use the symmetric key to decrypt the message.

    If you've got a reply:

    You: Encrypt the reply using the symmetric key.  Send the encrypted reply to me.

    Me: Decrypt the reply with the symmetric key I already know.


  • @Carnildo said:

    Public-key encryption is so slow that nobody actually does this. What actually happens is something like this:

    Me: Generate a symmetric-encryption key. Use that to encrypt the message. Encrypt the symmetric-encryption key using your public key. Send both the encrypted key and the encrypted message to you.

    You: Decrypt the symmetric key using your private key. Use the symmetric key to decrypt the message.

    If you've got a reply:

    You: Encrypt the reply using the symmetric key. Send the encrypted reply to me.

    Me: Decrypt the reply with the symmetric key I already know.

    Even that is not what usually happens in SSL/TLS sessions. They begin with a Diffie-Helman handshake - this is a bizarre mathematical process by which two mathematicians (with no prior communication or secure channels) can each shout one large number across a crowded room, and after some computation they both know a shared secret that nobody else in the room can work out. That secret is used as a symmetric key, and then the certificates are used purely in signing mode to authenticate the hosts.

    This method is used because it makes the certificate authentication optional - you can use https with no certificates at all, and still be secure from eavesdropping (although not from man-in-the-middle attacks). It also has the advantage of providing "perfect forward secrecy": if the private key for the certificate is stolen, the attacker still cannot decrypt anything unless they perform a man-in-the-middle attack, so any sessions that happened before the certificate was stolen are still secure.

    The method you describe is commonly used for other purposes, such as pgp (and SSL/TLS do actually support it, primarily for compatibility), but it's not what usually happens for https.

    (The bit about using symmetric encryption for all the real data is still true though. Diffie-Helman is just a really perverse form of public-key encryption, so it's as slow as all the others) 


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.