Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Quick HTTPS question

  1. #1
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424

    Quick HTTPS question

    Quick question: I have this guy claiming that Chase's online banking is insecure, because it's an http page and not an https page (http://www.chase.com), and that "you can login on an unsecure page" (sic).

    I could be totally wrong here, but that's not an issue, is it? I would think that as soon as you hit the Log On button, an SSL or TLS session is set up, and that session is used to send the username and password. The fact that the session is only set up when you hit Log On (and not before you even start filling out your username and password) is insignificant, no? In both cases, the username and password are sent over a (secure) SSL connection, so what's the problem?

  2. #2
    Senior Member
    Join Date
    Dec 2001
    Posts
    319
    Check the source. There's a section in there named 'start login_module_shared'. Glancing through it, you can see that it's passing the login info to a https address.

    <form style="display: inline; margin: 0; padding: 0;" name="logonform" id="logonform" align="center" autocomplete="off" action="https://chaseonline.chase.com/siteminderagent/forms/formpost.fcc" method="POST" onSubmit="return validateandsetcookie(document.logonform.usr_name, document.logonform.usr_password.value, document.logonform.remember.checked, '.chase.com','RBGLogon')">

  3. #3
    Member
    Join Date
    May 2008
    Posts
    34
    It's sending the information there...

    That is true. Is it being encrypted before it's sent there? Doesn't the browser have to send the username and password to the server before any encryption is taking place, if it's being sent over port 80? The only way that the login information is being secured before it leaves the browser is if the encryption is taking place client-side. Are you suggesting this is happening? If not, the login information is traveling over port 80...

    I wonder what a packet sniffer would find if it intercepted the web traffic going to the https url. Communication has to be initiated before any handshaking takes place, and the username and password are being sent, when you click the submit button, before an encrypted session is started, is it not? You are not actually in an encrypted session until you see the locks in the browser stating the certificate that is being used and there is https in the URL.

    Unless I am mistaken, you are initiating the communication with the server over port 80 http. The communication request is for a new port 443 connection and the server responds by sending an https URL over port 443. Until the machines are both communicating over https on port 443, it is not encrypted traffic. That means the username and password is not encrypted during the first trip to the server. If anyone has some facts or links explaining how this is secure, I would love to see them.
    Last edited by itPro; May 22nd, 2008 at 08:07 PM.

  4. #4
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    the username and password are being sent, when you click the submit button, before an encrypted session is started, is it not?
    No.
    You seem to suggest that the customer's username and password are being used to initiate the SSL connection (in the handshake), which is not the case. The encrypted session is set up first, then the customer username and password are sent (over the encrypted session).

  5. #5
    Member
    Join Date
    May 2008
    Posts
    34
    When you click the submit button, it is posting the page and its entire contents to the server. The URL that it wants to retrieve is https://blahblah, but the data is traveling over the established port 80. The server responds by establishing the link via port 443, but this is done after the post has already occurred, not before. Are you saying that every time a post is made on an http page that it does not send any information to the server until after it receives a response? Look at the javascript. Even if that was the case, you can clearly see that, OnSubmit(), the parameters are being passed to the server. This is happening before the server switches over to https.

  6. #6
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    As far as I know, as soon as you click the Log On button, an SSL session (with the https page) is initiated (through the "action" of the form). It can't send the information via port 80 to the https page (and it doesn't), because the https page only accepts SSL connections. Almost all online payment services (including PayPal) use that method (post to https), so from that fact alone, I'm going to conclude that it's got to be pretty secure (and, thus, that there's no sensitive data being sent over an insecure connection).

  7. #7
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    I believe this page spells it out completely: http://www.michaelhorowitz.com/securesubmit.html

    Check the "Bad News" section (the rest is pretty interesting, too, but that section clearly explains why the post https method is secure).

  8. #8
    Member
    Join Date
    May 2008
    Posts
    34
    Thank you. I was still uncertain about whether or not the information was being encrypted, but I read the article that you linked to. That was very informative. I feel a bit better about using Chase now. What finally satisfied my doubt was the fact that I set FireFox to alert me whenever I was sending unencrypted data. When logging in, I didn't get the warning.

    It also clicked when you said that the browser doesn't attempt to connect over port 80. I'm still curious as to how exactly the procedure takes place. I'm going to assume (yet again) that the browser finds the server, asks the server what port and protocol to use, and then begins the process of starting the data transfer. The login is being sent, but it is being encrypted first.

    Nevertheless, I will still not just assume that a webpage is offering an encrypted login just because there is a .gif or a .jpeg of a lock on the page. That is a practice that should still be avoided, and it would be wise not to just assume that things are safe. While I was wrong about the login information being sent in clear text, I was right to be wary. (I'm so glad that someone with some expertise finally cleared up my worries on this one...)

    Anyway, thanks again.

  9. #9
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    If it makes you feel any better: I had no clue about the things in the "Interesting Part" part of the article (I just noticed, btw, that the article specifically mentions Chase).

  10. #10
    Senior Member
    Join Date
    Dec 2001
    Posts
    319
    Without having read the article, would I be correct in guessing that the method used is :
    1) When user hits submit, send a 'blank' request for the https page
    2) Fill in the blanks on the https page on client-side
    3) Submit the https page with the login details back through the secure port

Similar Threads

  1. Quick question...
    By DerekK in forum Network Security Discussions
    Replies: 4
    Last Post: September 10th, 2004, 10:35 PM
  2. Quick Apache Question...
    By NetSec in forum *nix Security Discussions
    Replies: 2
    Last Post: September 25th, 2002, 01:02 AM
  3. Quick question: Can a group be added to a group?
    By roswell1329 in forum *nix Security Discussions
    Replies: 2
    Last Post: September 13th, 2002, 10:18 PM
  4. quick question
    By Obliterate in forum Newbie Security Questions
    Replies: 16
    Last Post: August 26th, 2002, 10:44 AM
  5. quick linux question
    By lewzer in forum Newbie Security Questions
    Replies: 3
    Last Post: August 7th, 2002, 03:07 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •