|
-
May 29th, 2008, 07:57 PM
#15
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
Last edited by itPro; May 29th, 2008 at 08:15 PM.
Similar Threads
-
By DerekK in forum Network Security Discussions
Replies: 4
Last Post: September 10th, 2004, 10:35 PM
-
By Obliterate in forum Newbie Security Questions
Replies: 16
Last Post: August 26th, 2002, 10:44 AM
-
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
-
Forum Rules
|
|