RE: ISSUE-108: Should Safe Browsing mode restrict users to a specific set of sites? [Techniques]

I agree that:

1. Their SSL handshake determined that a site was allowed for SBM. The
validating of the site should take place first

2. Their needs to be a globally accepted approach; e.g. US banks could be
validated by a single US authority, but there would have to be an equivalent
authority for each country; or alternatively we would need some recognized
international association, such as SWIFT.

 

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Ian Fette
Sent: Thursday, September 20, 2007 8:47 PM
To: michael.mccormick@wellsfargo.com
Cc: johnath@mozilla.com; dan.schutzer@fstc.org; public-wsc-wg@w3.org
Subject: Re: ISSUE-108: Should Safe Browsing mode restrict users to a
specific set of sites? [Techniques]

 

I don't think there was argument that SBM should be SSL only (and I would
not carve out any exceptions for images - they too can be an attack vector.
Mixed content should not be allowed in a "safe" mode - it should be SSL and
everything should validate and there should be no problems with anything.
Period.) 

I think the question is whether the SSL handshake took place *before*
validating that a site was allowed for SBM, or whether the SSL handshake
*determined* that a site was allowed for SBM.

The distinction is this: 

There is a (small, but nonzero) surface of attack exposed when you connect
to some random site. It could try to exploit a buffer overflow in a SSL
handshake, or some other weird attack. If you use the SSL handshake as the
first step in SBM, then you are opening yourself up in a mode that is
supposed to be "safe". It's not huge, but it's there. The alternative is to
do some validation before connecting. That is, something along the lines of
"The user wants to connect to https://www.wellsfargo.com. Wellsfargo is an
"approved" site, so assuming the certificate checks out then everything is
fine. Now the user wants to connect to https://www.IStealYourMoney.com.
IStealYourMoney.com is not an "approved" site, so I am not even going to
connect to IStealYourMoney.com and ask for a certificate, because it's not
an approved site anyways." 

I hope that clarifies the distinction that was being raised earlier that
Johnathan was raising about having a list + EV, in that it allowed you an
initial sanity check before connecting to some random host.

The other point was that, even within CAB, Logotype extensions aren't
standardized / finalized (PHB please correct me if I'm wrong). 

Also, I'm a bit concerned about the example of using the ABA - Unless I'm
mistaken, ABA stands for the "American Bankers Association", and it's not
clear to me that the ABA should be validating DeutscheBank or HSBC, for
instance. I think we want to give a lot of thought to who or what is the
root authority/authorities. I think a national organization might be a hard
sell (even something like FSTC would be a hard sell in my mind, because I
could easily see a UK customer asking why they're trusting FSTC instead of
APACS). On the other hand, I don't want to end up creating a mess like SSL
is where most browsers have tons of root CAs that I really have no idea
whether I should trust them or not. 

For instance, right now, my browser "trusts" a certificate from Staat der
Nederlanden - why should my browser trust the Dutch government? Who is
Swisscom? Who is Starfield? (Didn't it get bought by GoDaddy or something?)
And Unizeto Sp. z o.o.? Heck, even scarier, my browser has a "Wells Fargo
Root Certificate Authority"... no offense, but I don't trust Wells Fargo to
be a root of trust after it leaked private data back in 2006 (and stolen
laptops, etc.) 

Anyhow, I'm not trying to go CA bashing, or bank bashing, or consortium
bashing, or anything like that. I love banks, my family works for banks, I
think they're great and all that - I'm just saying that we need to be very
careful in creating a root of trust for SBM, because this is a very
international issue, and it should be very clear to the user why a certain
site is trusted - and I don't really think that, for the average person on
the streets of New York, that the answer "Because Unizeto Sp. z o.o." is
good enough (and frankly, on the streets of Berlin, I don't think the ABA is
a good enough answer.)

It's a hard problem, I'm not saying I have the answer, I'm merely trying to
raise a caution flag. 

-Ian

On 9/20/07, michael.mccormick@wellsfargo.com <
<mailto:michael.mccormick@wellsfargo.com>  michael.mccormick@wellsfargo.com>
wrote:


First of all, I feel SBM should be SSL-only (only https allowed, 
possible exception for certain MIMEs like GIF) so to me always requiring
a TLS handshake isn't a problem.

I agree a EV cert by itself provides little or no assurance of
trustworthiness or safety, but I didn't think SBM was proposing to use 
vanilla EV.  My understanding was that EV communities would be formed
and managed by a central authority that imposes additional controls on
issuing CAs.

For example, a banking community could be managed by an association such 
as the ABA, and ABA would require all participating issuers to meet (and
impose) certain criteria that go above & beyond what CAB Forum mandates.
In that scenario, possession of a EV SSL cert with the ABA community 
logo seems to me equivalent in every meaningful way to having one's URL
on a ABA managed white list... without all the well-known inherent
disadvantages of white listing (not scalable, not real-time, not secure, 
etc.)

Mike

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org ]
On Behalf Of Johnathan Nightingale
Sent: Wednesday, September 19, 2007 4:54 PM
To: Web Security Context Working Group WG
Subject: Re: ISSUE-108: Should Safe Browsing mode restrict users to a
specific set of sites? [Techniques] 


Using EV certs as the stand-in for a whitelist seems wrong, to me.
EV certs make strong identity claims, but not trustworthiness or safety
claims, which I think SBM envisions.  EV certs in combination with a 
whitelist seem like a more natural fit, if we're going to recommend this
at all.

I think the argument has been advanced that we could use the community
logotype field of an EV cert as a proxy for the whitelist, basically 
that having (say) the FSTC logo in there acts as de facto whitelist
membership.  One downside I see there is that it still requires the SSL
handshake to take place (in order to acquire the certificate for
inspection) which exposes some, albeit limited, attack surface.  In an 
EV+Whitelist world, that initial connection wouldn't occur because the
"Your accounts are being closed" email link would presumably point to
some non-whitelisted domain, and the connection would not be built in 
the first place.

I've said in the past that I don't think the maintenance and generation
of these lists can be accurately foreseen, and hence that I don't think
it's really the right kind of thing for our group to mandate, since that 
compels us to declare "non-conforming" any
browser that doesn't think the lists are mature enough.
Nevertheless, if we *are* to make such a recommendation, it feels like
EVs shouldn't be used as a surrogate for "trustworthiness" 
determinations.

Cheers,

Johnathan

On 18-Sep-07, at 8:59 AM, Web Security Context Working Group Issue
Tracker wrote:

>
> ISSUE-108: Should Safe Browsing mode restrict users to a specific 
> set of sites? [Techniques]
>
> http://www.w3.org/2006/WSC/track/issues/
>
> Raised by: Thomas Roessler
> On product: Techniques 
>
> In the current draft:
>
>   Editor's Draft $Date: 2007/09/18 12:50:20 $
>
> safe browsing mode includes a requirement that Web user agents only
> be able to access EV (or EV-like) sites when in Safe Browsing 
> Mode.  From discussions, this is one possible approach; the aim
> seems to be to have some whitelist of truted sites that can be
> accessed in this mode.
>
> Questions:
>
> - Should such a whitelist exist at all? 
> - If it exists, are EV certificates the right criterion?
>
>
>
>
>
>

---
Johnathan Nightingale
Human Shield
johnath@mozilla.com  <mailto:johnath@mozilla.com>