Re: What is a secure page?

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