RE: Authoring practices on mixed content and unsafe redirects.

2nd this.

 

Mixed mode sites may have been a reasonable design a few years ago, I
no longer feel that this is true. Attack vectors have changed with the
use of dynamic content and 3rd party providers. 

 

Feel that Johnathan makes a valid point and can't be better said

 

"Okay, you want to make those tradeoffs, go ahead, but don't call
yourself security-standards-compliant."

 

 

I deviate from Johnathan in that do not feel that TLS/SSL imposes a
significant penalty on the provider(s). It is the cost of doing
business.

 

Cheers

Bill D.

wdoyle@mitre.org

 

From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Johnathan
Nightingale
Sent: Friday, March 28, 2008 4:19 PM
To: Ian Fette
Cc: Mary Ellen Zurko; Thomas Roessler <tlr; public-wsc-wg@w3.org
Subject: Re: Authoring practices on mixed content and unsafe redirects.

 

On 28-Mar-08, at 2:02 PM, Ian Fette wrote:

Re: 8.3, I'm still not happy with this text. The reality is that a ton
of sites use TLS to protect the login, and then use a cookie over HTTP
afterwards. It's a calculated tradeoff based on the fact that SSL is
still significantly more expensive than unencrypted HTTP traffic. Take
for instance nwa.com - I log in via SSL, but then I get a cookie that
works over HTTP. When I go back I can see things like my mileage
balance, my recently posted activity, etc. I still have to give my pin
again if I want to change my pin, or if I want to make a booking using
a stored card etc, but for the most part I have the same access as I
did with the password. Many webmail applications are similar - full
access minus a few select things (changing password, for instance).

The consumer and provider of the service are much better equipped to
evaluate that tradeoff than we are. (Well, at the very least the
provider is well equipped to evaluate the tradeoff, and if the consumer
desires more security they have the option of not using that service,
or using a service that does offer SSL for everything, but that cost is
going to be borne by someone...)

 

I hear what you're saying here, Ian, but I think I disagree.  Sites
will, of course, do whatever they feel they need to do, and make
whatever tradeoffs they need to make along the way.  I don't think
that's a reason to weaken our guidance to site authors though.

 

A site which allows me to retrieve sensitive information, or transact
sensitive activities, and which does so without securing the channel,
is putting users at risk by the tradeoffs they've made, and I think
it's entirely appropriate for us to say "Okay, you want to make those
tradeoffs, go ahead, but don't call yourself
security-standards-compliant."

 

As we've discussed before, I'm not confident that any but the most
scrupulous of site developers are going to look at our guidance here in
the first place, but if they do, we ought to at least be unambiguous
about what the most secure approach is (to the extent we consider it
part of our charter) and let site authors choose to tradeoff compliance
against affordability (or any other business concern) as they see fit.

 

Cheers,

 

Johnathan

 

---

Johnathan Nightingale

Human Shield

johnath@mozilla.com