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?

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')">

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.

Quote:

---

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

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.

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

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

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.

If it makes you feel any better: I had no clue about the things in the "Interesting Part" part of the article :D (I just noticed, btw, that the article specifically mentions Chase).

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

Good question... the article doesn't cover exactly how it takes place. The key point is that it is irrelevant whether or not the page where you fill out your username and password is secure (https) or not (http). What is important is that the "action" value of the form initiates an https connection - how exactly the exchange takes place, it doesn't mention. I'm assuming it's along the lines of what you suggest.

My gf uses chase.com it does use https after you log in of course. That client is full of poo.

Computernerd22 : the question isn't whether or not it uses it, but at what point it kicks in (before or after credentials are submitted)

Would someone more knowledgable on the subject than Neg or I care to chime in on the exact process? I'm curious now....

After configuring a server a couple of times, it makes me just shake my head at Chase. Even if they are using proper security, their method is very unprofessional. You can set up your IIS server to allow connections that aren't encrypted. This means that the machine will reply to unencrypted connections as well as encrypted connections, and the content the machine sends back may or may not be encrypted, even with an https URL.

I'll still say that anyone that trust a website's security that doesn't have browser confirmation that an SSL certificate is being used is naive. Even with all of the knowledge I possess about web sites and the way they work, this still makes me uneasy. There is at least a confirmation article stating that it really is secure at Chase, but I would love to see a diagram or other example of what steps are taking place in order during this transaction.

The only thing that gives me hope that this is secure is the fact that the IIS server is probably configured so that all port 443 traffic is encrypted before data is being sent between the machines.

Think about it this way. You can ping a machine without sending encrypted data. The machine's choice to respond and its method of responding has nothing to do with the data that you sent it, other than the permissions that are set for the origination of the request, and that decision is still made after the data is received by the server. There really is no difference when sending a username and password. You could send your username and password to the machine in clear text. Even if the data is ignored, it still traveled to the server over the Internet in clear text before it was dropped. The real question is whether or not that transaction is happening before the messages start being encrypted. When you see a lock on your browser, you know that everything is encrypted. Until you see that lock, I wouldn't be so sure. Thinking back to that article, I wonder if that guy has anymore of an idea than we do.

One of two things could be happening.
1.
The browser uses the action part of the url and checks for the IP of the https url.
The browser sends a request for communication to that IP.
The server sends a response along with the public key.
The browser then uses the public key to encrypt the information and to then send the username and password.

or

2.
The browser uses the action part of the url and checks for the IP of the https url.
The browser then sends the username and password along with the request for an encrypted web page. (This is very similar to adding parameters to a method.)
The server then sends the browser a public key so that data can be sent to the server that's encrypted.
I would guess that the browser then sends the server a created public key that is encrypted so that the server can use that key in order to encrypt data that only the browser could decrypt (with its created private key).
Once both machines are ready to send encrypted content that only the other machine can decrypt, the encrypted session starts and either an encrypted login page is sent to the browser (upon failed verification) or an encrypted account page is sent to the browser (upon successful verification).


That still leaves one to wonder when exactly the encryption starts. It would be awesome to have some literature on it from Mozilla or Microsoft. lol

Quote:

---

Originally Posted by Computernerd22

My gf uses chase.com it does use https after you log in of course. That client is full of poo.

---

lol I guess it never crossed your mind that your login credentials might be sent in clear text and any encryption process after that would be irrelevant, if someone knew your user-name and password.

Here's a packet capture of what happens when you go to http://www.chase.com (not https!):

Code:

---

192.168.1.104        159.53.64.173        TCP        17093 > https [ACK] Seq=1 Ack=1 Win=17520 Len=0
192.168.1.104        159.53.64.173        SSL        Client Hello
159.53.64.173        192.168.1.104        TCP        [TCP segment of a reassembled PDU]
159.53.64.173        192.168.1.104        TLSv1        Server Hello, Certificate, Server Hello Done
192.168.1.104        159.53.64.173        TCP        17093 > https [ACK] Seq=153 Ack=2093 Win=17520 Len=0
192.168.1.104        159.53.64.173        TLSv1        Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
159.53.64.173        192.168.1.104        TLSv1        Change Cipher Spec, Encrypted Handshake Message
192.168.1.104        159.53.64.173        TLSv1        Application Data
159.53.64.173        192.168.1.104        TLSv1        Application Data
159.53.64.173        192.168.1.104        TCP        https > 17093 [FIN, ACK] Seq=2765 Ack=1644 Win=65535 Len=0
192.168.1.104        159.53.64.173        TCP        17093 > https [ACK] Seq=1644 Ack=2766 Win=16848 Len=0
192.168.1.104        159.53.64.173        TLSv1        Encrypted Alert

---

I'm not sure why nothing is indicating that this is a secure (HTTPS) site, but I think that that traffic speaks for itself...

I wish you had port numbers and a bit more detail as to what is going on. I'm guessing that is just a portion of the transaction. I can see https in the log, but you say that you get that when going to an http site. I don't get that. My guess is that a portion of the page is being rendered through https. With that said, however, why isn't there a lock on the page? Usually, whenever a page has secure and non-secure items, there is a lock shown that is crossed out, which alerts you that some of the content has been encrypted. Forgive my curiosity, but I really want to know the hows and whys of this.

Edited:

I looked through a logfile I created with Wireshark. It appears as though the page has content coming from two different servers. It also appears as though an entirely different page is being loaded within this page. Check your log for 159.53.83.23 and you should see an entry for HTTP GET /auth/login.html HTTP /1.1. Later in the log, you will see an https entry generated for that same IP. That is why there is no lock showing on the http page. It isn't secure. The page that is secure is completely different, and, since it is not contained within its own browser window, there is no way of showing a lock.

Btw guys, if this is the case, then the action of the login button is not what is actually encrypting the credentials before it leaves. The encryption is taking place as the page loads. The empty input boxes are traveling in encrypted format when the page opens, or at least the packet-sniffer seems to suggest that. At the very least, the handshaking process has at least taken place before the form submits and all data leaving the page will be encrypted, even if those input boxes were not when the page loaded. The https link in the action does let us know that it is going to a server that will be secure, but I'm pretty sure that the content is encrypted before that connection is made. Nevertheless, I'm still excited about finding out more on this. I'm obviously not sure if I'm 100% accurate on my theory, but it fits together logically. Of course, there are other possibilities.

At least I finally figured it out. :)

With that said, I will still say that you should not trust any web page that doesn't show you a lock. With the same idea in mind as what I've discovered, it could just as easily be the reverse that's true. If a variable is passed in clear text to an http web page within a https web page, whatever is sent over the http page will not be encrypted. With that being said, however, it would be incredibly ignorant to go to the trouble of encrypting the page, only to turn around and send important data over an insecure page as well.

I figured out what is exactly going on. As I theorized with the information gathered from the log file, there is indeed another page being loaded within the page. It's not easily noticed on the page by right-clicking in order to look for an iframe, either, which is also the reason why I did not think that there was an iframe and why I did not think the process was secure to begin with.

Here is the code: "<iframe id="loginframe" name="loginframe" src="http://mfasa.chase.com/auth/login.html" width="0" height="0" frameborder="0" scrolling="no" marginheight="0" marginwidth="0"></iframe>
<!-- end login_module_shared -->"

(Notice that the size of the iframe is 0 pixels by 0 pixels. You won't find that iframe by right-clicking anywhere on the page that you can see.)

For the record, that doctor in the other article that suggested that the action part of the submit button ensured encryption prior to the data being sent was indeed WRONG. When you submit a form and the action part attempts to go to https://chaseonline.chase.com/sitemi...s/formpost.fcc , you are really asking the domain name server what IP you're going to connect to. That's it. The form data is then sent to the server at that IP and the server decides what to do with it. What is really going on here is that the http://mfasa.chase.com/auth/login.html (not secure) is being opened, then auto-submitted and replaced with an https page (secure). That public key transaction is what encrypts the contents of your username and password before it is sent out. The action part of the URL only lets you know that it is going to a secure server and that the reply you get back will also be encrypted.

I love it when I prove that I am smart. :D This also is another prime example of why you don't take someone else's word for it, and never assume that someone else is smarter than you, regardless of their education or job title.

Computernerd22, I really hope you paid attention.

If that iframe wasn't there, that 'client' would have been correct. The fact that it is there gives a reasonable indication that I was correct in saying that no encryption takes place until after a response comes back from an https request and that data submitted via the form with this request is also not encrypted during submission. Why else would they need to establish the handshaking process first via the iframe?

Negative, that quote does not contain an error, so your use of "(sic)" is no longer appropriate. lol You are indeed logging in on an unsecure page. It is, after all, http and we all know that http is not secure. The method of transportation is over https, but that doesn't make the quote inaccurate. ;)