From poptalk at ukr.net  Sat Feb 14 16:01:11 2009
From: poptalk at ukr.net (poptalk)
Date: Sun, 15 Feb 2009 02:01:11 +0200
Subject: [Petname] checking SSL certificates
Message-ID: <49975B47.108@ukr.net>

Hi.
I've received messages that Petname does not check SSL certificates (see 
a recent review on https://addons.mozilla.org/uk/firefox/addon/957). 
While inspecting source code I found that a code which reads SSL 
certificates was removed since version 1.1. Comments would be appreciated.

From tyler.close at gmail.com  Sat Feb 14 16:30:47 2009
From: tyler.close at gmail.com (Tyler Close)
Date: Sat, 14 Feb 2009 16:30:47 -0800
Subject: [Petname] checking SSL certificates
In-Reply-To: <49975B47.108@ukr.net>
References: <49975B47.108@ukr.net>
Message-ID: <5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>

Hi poptalk,

When I updated the Petname Tool for Firefox 3, I changed the algorithm
for binding a petname to a site to take into account the research that
Collin Jackson published on finer-grained origins. See:

"Origin Granularity"
http://crypto.stanford.edu/websec/origins/

As Collin points out in his paper, the browser's Same Origin policy
allows all pages from the same origin (URL scheme, hostname, port
number) to freely read and write each other's pages within the
browser. Consequently, it is not possible to trust a page transmitted
using one certificate any more than a page transmitted using a
different certificate, if both of those pages are within the same
origin. Therefore, the Petname Tool now binds the user chosen petname
to an origin, rather than a certificate. Unfortunately, there is no
reliable security boundary within the browser that is based on
certificates. There is only the Origin security boundary.

If you want to ensure that you are communicating with a particular
certificate, you could remove all the CA certificates from your
browser and instead only use the certificate pinning UI provided by
Firefox 3. In this case, the browser would only let the pinned
certificate be used for the named origin. Since the Petname Tool binds
your petname to the origin, you would again have a hard link from a
petname to a particular certificate.

This seems to be the best I can do given the browser's current security model.

--Tyler

On Sat, Feb 14, 2009 at 4:01 PM, poptalk <poptalk at ukr.net> wrote:
> Hi.
> I've received messages that Petname does not check SSL certificates (see a
> recent review on https://addons.mozilla.org/uk/firefox/addon/957). While
> inspecting source code I found that a code which reads SSL certificates was
> removed since version 1.1. Comments would be appreciated.
> _______________________________________________
> Petname mailing list
> Petname at mozdev.org
> https://www.mozdev.org/mailman/listinfo/petname
>

From poptalk at ukr.net  Mon Feb 16 07:33:35 2009
From: poptalk at ukr.net (poptalk)
Date: Mon, 16 Feb 2009 17:33:35 +0200
Subject: [Petname] checking SSL certificates
In-Reply-To: <5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
References: <49975B47.108@ukr.net>
	<5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
Message-ID: <4999874F.4080608@ukr.net>

Thank you for the elaborated answer. I hope Firefox's developers will 
cope with this issue.

Tyler Close wrote:
> As Collin points out in his paper, the browser's Same Origin policy
> allows all pages from the same origin (URL scheme, hostname, port
> number) to freely read and write each other's pages within the
> browser.

From vwelch at uiuc.edu  Mon Feb 16 10:49:41 2009
From: vwelch at uiuc.edu (Von Welch)
Date: Mon, 16 Feb 2009 12:49:41 -0600
Subject: [Petname] checking SSL certificates
In-Reply-To: <5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
References: <49975B47.108@ukr.net>
	<5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
Message-ID: <4999B545.2040908@uiuc.edu>

Hi Tyler,

 What I take away from this is that since petname isn't binding to a
certificate, it is a valuable tool against the all-too-common email
phishing and domain name typo sort of attacks, but not a barrier to
a much more complicated, as far as I know theoretical, attack
involving DNS spoofing and an illicit certificate of some sort. This
isn't meant as a criticism, just making sure I understand things.

 Out of curiosity, given it bases the nickname on a origin rather
than a certificate, any reason it couldn't bind nicknames to
non-https (i.e. http) origins? (Granted, one could debate the
usefulness, but out of curiosity...)

Von

Tyler Close wrote:
> Hi poptalk,
> 
> When I updated the Petname Tool for Firefox 3, I changed the algorithm
> for binding a petname to a site to take into account the research that
> Collin Jackson published on finer-grained origins. See:
> 
> "Origin Granularity"
> http://crypto.stanford.edu/websec/origins/
> 
> As Collin points out in his paper, the browser's Same Origin policy
> allows all pages from the same origin (URL scheme, hostname, port
> number) to freely read and write each other's pages within the
> browser. Consequently, it is not possible to trust a page transmitted
> using one certificate any more than a page transmitted using a
> different certificate, if both of those pages are within the same
> origin. Therefore, the Petname Tool now binds the user chosen petname
> to an origin, rather than a certificate. Unfortunately, there is no
> reliable security boundary within the browser that is based on
> certificates. There is only the Origin security boundary.
> 
> If you want to ensure that you are communicating with a particular
> certificate, you could remove all the CA certificates from your
> browser and instead only use the certificate pinning UI provided by
> Firefox 3. In this case, the browser would only let the pinned
> certificate be used for the named origin. Since the Petname Tool binds
> your petname to the origin, you would again have a hard link from a
> petname to a particular certificate.
> 
> This seems to be the best I can do given the browser's current security model.
> 
> --Tyler
> 
> On Sat, Feb 14, 2009 at 4:01 PM, poptalk <poptalk at ukr.net> wrote:
>> Hi.
>> I've received messages that Petname does not check SSL certificates (see a
>> recent review on https://addons.mozilla.org/uk/firefox/addon/957). While
>> inspecting source code I found that a code which reads SSL certificates was
>> removed since version 1.1. Comments would be appreciated.
>> _______________________________________________
>> Petname mailing list
>> Petname at mozdev.org
>> https://www.mozdev.org/mailman/listinfo/petname
>>
> _______________________________________________
> Petname mailing list
> Petname at mozdev.org
> https://www.mozdev.org/mailman/listinfo/petname

From tyler.close at gmail.com  Mon Feb 16 16:55:10 2009
From: tyler.close at gmail.com (Tyler Close)
Date: Mon, 16 Feb 2009 16:55:10 -0800
Subject: [Petname] checking SSL certificates
In-Reply-To: <4999B545.2040908@uiuc.edu>
References: <49975B47.108@ukr.net>
	<5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
	<4999B545.2040908@uiuc.edu>
Message-ID: <5691356f0902161655kf4b7934s5bc723a2013ed7dc@mail.gmail.com>

Hi Von,

On Mon, Feb 16, 2009 at 10:49 AM, Von Welch <vwelch at uiuc.edu> wrote:
> Hi Tyler,
>
>  What I take away from this is that since petname isn't binding to a
> certificate, it is a valuable tool against the all-too-common email
> phishing and domain name typo sort of attacks, but not a barrier to
> a much more complicated, as far as I know theoretical, attack
> involving DNS spoofing and an illicit certificate of some sort. This
> isn't meant as a criticism, just making sure I understand things.

If the illicit certificate is trusted by your browser (because it was
issued by a trusted CA, or you clicked through the error dialogs), the
loaded page can read/write any of the pages in that Origin. The
Petname Tool doesn't provide you with any protection in this case.

>  Out of curiosity, given it bases the nickname on a origin rather
> than a certificate, any reason it couldn't bind nicknames to
> non-https (i.e. http) origins? (Granted, one could debate the
> usefulness, but out of curiosity...)

It is certainly possible to assign petnames to http origins, but I
suspect that would be misleading. When you give information to an http
page, it is just like shouting it out for all to hear and probably
also modify. The user shouldn't have any expectation of private
communication over plain http.

--Tyler

From jamesd at echeque.com  Tue Feb 17 12:32:03 2009
From: jamesd at echeque.com (James A. Donald)
Date: Wed, 18 Feb 2009 06:32:03 +1000
Subject: [Petname] checking SSL certificates
In-Reply-To: <5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
References: <49975B47.108@ukr.net>
	<5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
Message-ID: <499B1EC3.8030503@echeque.com>

Tyler Close wrote:
> Hi poptalk,
> 
> When I updated the Petname Tool for Firefox 3, I changed the algorithm
> for binding a petname to a site to take into account the research that
> Collin Jackson published on finer-grained origins. See:
> 
> "Origin Granularity"
> http://crypto.stanford.edu/websec/origins/

I do not see the issue here.

Petname can, and should, caution the user if the containing page has an 
anomalous certificate.



From tyler.close at gmail.com  Tue Feb 17 13:00:01 2009
From: tyler.close at gmail.com (Tyler Close)
Date: Tue, 17 Feb 2009 13:00:01 -0800
Subject: [Petname] checking SSL certificates
In-Reply-To: <499B1EC3.8030503@echeque.com>
References: <49975B47.108@ukr.net>
	<5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
	<499B1EC3.8030503@echeque.com>
Message-ID: <5691356f0902171300u1eb472d8x22c5d260e46580b7@mail.gmail.com>

Hi James,

On Tue, Feb 17, 2009 at 12:32 PM, James A. Donald <jamesd at echeque.com> wrote:
> Tyler Close wrote:
>>
>> Hi poptalk,
>>
>> When I updated the Petname Tool for Firefox 3, I changed the algorithm
>> for binding a petname to a site to take into account the research that
>> Collin Jackson published on finer-grained origins. See:
>>
>> "Origin Granularity"
>> http://crypto.stanford.edu/websec/origins/
>
> I do not see the issue here.
>
> Petname can, and should, caution the user if the containing page has an
> anomalous certificate.

Firefox does caution the user if an untrusted certificate is
encountered. The problem is with a certificate that is illegitimate,
but issued by a CA trusted by Firefox, or if the user clicks through
the warning about an untrusted certificate. If either of these events
occur, the page from the illegitimate site can immediately read/write
any of the pages, or cookies, belonging to the legitimate site.

--Tyler

From jamesd at echeque.com  Tue Feb 17 13:11:25 2009
From: jamesd at echeque.com (James A. Donald)
Date: Wed, 18 Feb 2009 07:11:25 +1000
Subject: [Petname] checking SSL certificates
In-Reply-To: <499B1EC3.8030503@echeque.com>
References: <49975B47.108@ukr.net>
	<5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>
	<499B1EC3.8030503@echeque.com>
Message-ID: <499B27FD.6010601@echeque.com>

 > "Origin Granularity"
 > http://crypto.stanford.edu/websec/origins/

Suppose that petname makes sure that the origin of the
main containing page has the correct key.

If the main containing page contains pages capable of
executing scripts from the same origin, but not
necessarily the same key, then checking the key of the
containing document is useless.

If, however, all the stuff on the page capable of
containing scripts from this origin is a single document
from a single source, which is also pretty common, then
it seems to me that the only way we can be hosed is if
we at some point open a main containing page that
petname shows has an unexpected key, which page can then
modify other pages that petname continues to show have
the correct key.

Including multiple https documents within a single
document greatly increases the number of round trips.
Informal surveys suggest that each additional round trip
significantly reduces the number of customers using your
page.  It is a big killer on web comics.

The security flaw to which you refer is only serious if
someone includes multiple same origin documents in a
single document - which no one should ever do, even
though lots of people do it.

The inclusion of scripts from a multitude of sources
introduces a multitude of obscure and complex security
issues, for which caja is the solution - caja ensures
that foreign scripts included by the main containing
page can only do those things that the main containing
page gives them to do.  Petname cannot, and should not,
worry about the kind of problems introduced by the
inclusion of diverse scripts.  That is a Caja issue.
Assume it is taken care of, or assume the main
containing page is so simple that script related
problems cannot arise.

You cannot say "scripts break all security solutions,
therefore we give up".

You can say "scripts create a big gap in the security
perimeter we erect.  But that is someone else's problem.
Use caja to contain them, or refrain from including
them."

From jamesd at echeque.com  Tue Feb 17 14:25:40 2009
From: jamesd at echeque.com (James A. Donald)
Date: Wed, 18 Feb 2009 08:25:40 +1000
Subject: [Petname] checking SSL certificates
In-Reply-To: <5691356f0902171300u1eb472d8x22c5d260e46580b7@mail.gmail.com>
References: <49975B47.108@ukr.net>	
	<5691356f0902141630l2aa2217cgf10044296cfba034@mail.gmail.com>	
	<499B1EC3.8030503@echeque.com>
	<5691356f0902171300u1eb472d8x22c5d260e46580b7@mail.gmail.com>
Message-ID: <499B3964.4040201@echeque.com>

Tyler Close wrote:
 > Firefox does caution the user if an untrusted
 > certificate is encountered. The problem is with a
 > certificate that is illegitimate, but issued by a CA
 > trusted by Firefox, or if the user clicks through the
 > warning about an untrusted certificate. If either of
 > these events occur, the page from the illegitimate
 > site can immediately read/write any of the pages, or
 > cookies, belonging to the legitimate site.

Since the worst of umpteen CAs trusted by Firefox will
always be a very incompetent or dishonest CA, I would
like to be able to see if a web page has a certificate
issued by an unexpected CA, for even if this fails to
seal all security holes, it still seals one security
hole.

Any security system that relies on some trusted group
will either trust too few, or too many.  If too few,
will not be used, therefore will always trust too many.
If attackers can choose which of that many, we are
hosed.  If attackers cannot choose,  we are still OK
because the vetting will ensure that most of that many
are OK, even though it is unlikely to ensure that all of
that many are OK.

The scenario, as I understand it, is that you are logged
in and browsing a secured web site.  At some point the
attacker intercepts a fresh https request, and provides
his fraudulent certificate for the same origin site. His
page can then do anything, giving him complete access
and control over all your pages downloaded from the same
origin with the correct key. But one then has an anomalous
situation - two certificates for one origin.  I would like
to see such an anomaly flagged.