PaulDotCom mailing list archives
SSL Encryption and HTML
From: raffi at flossyourmind.com (Raffi Jamgotchian)
Date: Wed, 29 Oct 2008 00:50:31 -0400
Or even within the community according to the reports ---- Raffi On Oct 28, 2008, at 11:49 PM, "James Costello" <genesiswave at gmail.com> wrote:
My bank uses SSL through out the session which I greatly appreciate and my credit union redirects from the main site to separate window to login to using SSL. I think a simpler hack/hijack is to put up a copycat site that a user is directed to via e-mail which has the same login handling as the main page of the banks website with a minor redirect through the bad guys server to capture the login information and then forward the client on to the legitimate bank site, user is never prompted for the certificate information because you can be legitimately redirected to https from http (as seen in the original example). One possible catch could be someone who has set their IE to notify them when they move to a trusted site from a non trusted site and has set his/her bank site up in the trusted zone instead of the default Internet zone. I agree with Paul's assessment about the extended validation cert, if I don't see it on my bank, I am not sure I would want to use the site without verifiying the certificate (but really how many people outside of the security community ever take the time to do that) James 2008/10/28 Paul Asadoorian <paul at pauldotcom.com> My thoughts on SSL: 1) Spoofing the Certificate - This is successful more often than not, and since SSL is based on trust, well bad things can happen. Remember the security conference where they spoofed bogus certs and most people, security people at that, accepted the invalid cert? This is a major weakness in the concept of SSL (not necessarily the encryption implementation, which is good, just don't get caught using weak ciphers). 2) Certificate Authorities - If you can own the cert authority, you could make a big profit :) Seriously, ever look at the CA's that are trusted in your browser? There are some shady places in there, and you don't necessarily just trust them, you trust however has possession of their keys... 3) Extended Verification Certs - Firefox just recently included this by default in version 3, and I think its a good thing, and adds a layer (albeit a small one) to the security of SSL. I like to see the green when I go to a web site (especially if its my bank ;) Cheers, Paul Cody Ray wrote:Do you guys agree with the below statement? Although the login does not occur on a secure HTML page, the loginis,in fact, secure. We have all been well trained on how to check for security. We all look down at our status bar at the bottom of the browser to make sure there is a little lock or key that assures usthateverything is secure before we send anything. Well now there's a new rule to learn: data can be sent securely even if you don't see these icons of security. When you fill out an information form, or application, or login, etc. you are filling out information on onepageand the information is being sent to a second page. We see thesecurityicons when the page that collects the information is secure. The information can be sent securely if the collection page is notsecure,but the page where the information is sent to is secure. This is the method we use on home page logins. If you want to assure yourselfthatthe information you are sending is secure and you don't see asecurityicon, you can view the HTML source code. This may be intimidatingforsome, but all you have to do is search to find the word "action=."Thiswill show you the location of the page that the information willbe sentto. If you see "action='_https://?',_" you know that it is being sentsecurely. If you see "action='_http://',_" you know it is notsecure.Information Encryption Your account information never travels the Internet withoutencryptionprotection. When you click on "login", we encrypt your OnlineBanking IDand password using Secure Sockets Layer (SSL) technology, thehighestlevel of Internet security available. A secure connection isestablishedbefore your ID and password are transmitted and maintained for the duration of your Online Banking session.--- ---------------------------------------------------------------------_______________________________________________ Pauldotcom mailing list Pauldotcom at mail.pauldotcom.com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com-- Paul Asadoorian PaulDotCom Enterprises Web: http://pauldotcom.com Phone: 401.829.9552 _______________________________________________ Pauldotcom mailing list Pauldotcom at mail.pauldotcom.com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list Pauldotcom at mail.pauldotcom.com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pauldotcom.com/pipermail/pauldotcom/attachments/20081029/65022c64/attachment.htm
Current thread:
- SSL Encryption and HTML Cody Ray (Oct 28)
- SSL Encryption and HTML Blake Hartstein (Oct 28)
- SSL Encryption and HTML matt donovan (Oct 28)
- SSL Encryption and HTML Nick Baronian (Oct 28)
- SSL Encryption and HTML matt donovan (Oct 28)
- SSL Encryption and HTML Paul Asadoorian (Oct 28)
- SSL Encryption and HTML James Costello (Oct 28)
- SSL Encryption and HTML Raffi Jamgotchian (Oct 28)
- SSL Encryption and HTML Oscar Koeroo (Oct 29)
- SSL Encryption and HTML Paul Asadoorian (Oct 29)
- SSL Encryption and HTML Jim Kelly (Oct 29)
- SSL Encryption and HTML James Costello (Oct 28)
- SSL Encryption and HTML Chris Frederick (Oct 29)
- <Possible follow-ups>
- SSL Encryption and HTML David A. Gershman (Oct 28)
- SSL Encryption and HTML Ken Asher (Oct 28)
- SSL Encryption and HTML Blake Hartstein (Oct 28)