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.

May 29th, 2008, 05:21 AM

Computernerd22

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

May 29th, 2008, 03:03 PM

delstar

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

May 29th, 2008, 08:57 PM

itPro

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

May 30th, 2008, 02:37 PM

itPro

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.

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

May 30th, 2008, 08:52 PM

itPro

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.

June 3rd, 2008, 05:38 PM

itPro

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.

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