- From: Yngve Nysaeter Pettersen <yngve@opera.com>
- Date: Thu, 25 Jan 2007 18:56:52 +0100
- To: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>
- Cc: "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
Sorry about the delay. On Mon, 08 Jan 2007 16:17:11 +0100, Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com> wrote: > Yngve indicates the former caused severe enough usability problems > that IE7 backed out of it. Yngve, were those serious enough that that > approach should not be considered in this context? Microsoft indicates in their IE-blog posting <URL: http://blogs.msdn.com/ie/archive/2006/10/18/ssl-tls-amp-a-little-activex-how-ie7-strikes-a-balance-between-security-and-compatibility.aspx > that they observed mixed security (images and Javascript) on secure blog compose pages. I recently saw (as a result of a question in our forums) a major European travel site use unsecure external CSS in many of their pages, such as the login and order pages, as well as their *security* policy page. <URL: https://www.opodo.co.uk/opodo/StrutsServlet/DisplaySiteInfoPage?pageName=security > They also used an unsecure external Javascript in their secure "Contact us" page. <URL: https://opodouk.custhelp.com/cgi-bin/opodouk.cfg/php/enduser/ask.php > (this form actually requires you to register and login before you can send the comment/question, and the registration page reference the same Javascript file) I sent an email to them almost two weeks ago, but have not yet received any response. In my opinion the better approach is to block unsecure elements in secure pages, but that may require a coordinated break by the browsers. (I am also skeptical to sites with secure elements in an unsecure page, such as a frame with a "secure" login form) > Yngve, I don't find the issues around redirect to be obvious to me at > all. > Do you have a longer discussion around the security context information > issues there? Or does someone else understand them in full? I'm guessing > it's something about a site other than the one originally pointed to > pushing the redirect on the browser (before the first site could > respond?). The two primary categories are 1) unsecure->secure redirects for the main document and 2) redirects involving inline resources, My primary concern here is point 1 as point 2 will be handled as part of the general padlock logic. It is very "popular" to have a link on an unsecure front page saying "go to online banking", which just sends a request to the same unsecure server and which is the redirected to the secure server. Just take a look at Bank of America's "Sign In"-link <URL: http://www.bankofamerica.com/hub/index.cfm?template=view_acct >. That link is doing multiple unsecure HTTP 302 redirects before ending up on the secure server (and they are apparently doing an automatic reload to get past the padlock indicating unsecure). The alternatives to the HTTP redirect are HTML Meta refresh and Javascript location redirects, both of which have varying effects on Opera's padlock depending on when they are triggered. The problem with these is that they are more difficult to detect as part of loading a page, or as part of a automatic action that was not part of the page load, but a new page load, whereas HTTP redirects are much easier to handle. I've not written any articles specifically about this topic (at least so far) but what I have on the area of secure vs. unsecure can be found at <URL: http://my.opera.com/yngve/blog/index.dml/tag/weak%20encryption > Another example of things I have seen in this area was the Las Vegas hotel (mentioned in my articles) that had a Flash based booking system (developed/hosted by a thirdparty) that downloaded information from the unsecure version of the booking system. That's irritating enough, but what they did next was among the worst offenses I've seen in this area: Their SSL hosted Flash booking applet sent the booking information, including credit card details, in _plain_ text! No SSL connection. They used 5-6 weeks to fix that problem after I told them about it. Cases like these are part of the reason why I am starting to favor a less forgiving handling of webpages containing mixed secure and unsecure content. But such a change would require coordination between the browser vendors. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ********************************************************************
Received on Thursday, 25 January 2007 18:00:04 UTC