Jean-Marc Desperrier wrote:
> Gervase Markham wrote:
>> Jean-Marc Desperrier wrote:
>>> You don't care *who* the owner of the cert is. What you care about is
>>> if he intends to use his signing cert to distribute spyware
>>> extensions. And his identity tells you nothing about that.
>>
>> No, bu
Hi Jean Marc,
Jean-Marc Desperrier wrote:
>
> How effective has this approach been until now to block spam and spyware
> ?
E...how many times did you encounter and installed signed spyware
and adware on your computer? I guess close to zero!
Would all software one installs be singed by a ver
Gervase Markham wrote:
> Jean-Marc Desperrier wrote:
>> You don't care *who* the owner of the cert is. What you care about is
>> if he intends to use his signing cert to distribute spyware
>> extensions. And his identity tells you nothing about that.
>
> No, but it does tell you whose door the p
> OCSP provides almost instant information about the validity of a
> certificate...
This depends on the OCSP implementation; the use of OCSP does not
automatically equate to 'real-time' or (in some cases) even
'moderately-close-to-real-time' certificate status. If the responder
is referencing a CR
Gervase Markham wrote:
>
> No, but it does tell you whose door the police can go knocking on if he
> logs into your online banking and steals all your money.
>
> Identity is a reasonable proxy for intention, because criminals don't
> want to be caught.
> Except that you would need to review all t
Jean-Marc Desperrier wrote:
> You don't care *who* the owner of the cert is. What you care about is if
> he intends to use his signing cert to distribute spyware extensions. And
> his identity tells you nothing about that.
No, but it does tell you whose door the police can go knocking on if he
Gervase Markham wrote:
> My definition of a "sucky" code signing cert is one in which the
> information inside about the owner of the cert isn't accurate.
It's a bad definition of a "sucky" code signing certificate.
You don't care *who* the owner of the cert is. What you care about is if
he int
Arrakis wrote:
> Why not use digital certificates provided by CACert. They are free, and
> have high levels of assurity, as opposed to a CAs like Verisign that
> have little to no assurity, and charge a ransom.
Because CAcert have not applied for inclusion into (and therefore,
obviously, not been
Nils Maier wrote:
Eddy Nigg (StartCom Ltd.) schrieb:
Hypothetical question: If Mozilla or an independent organization could
provide this service for free and reduce the efforts required to a
minimum, would this solve the problem? Would the various applications,
add-ons etc be digitally signed fr
Arrakis wrote:
> Why not use digital certificates provided by CACert. They are free, and
> have high levels of assurity, as opposed to a CAs like Verisign that
> have little to no assurity, and charge a ransom.
>
>
>
Well
1) Not audited
2.) Not in Mozilla, or most other browsers because of #1
3
Eddy Nigg (StartCom Ltd.) schrieb:
> Nils Maier wrote:
>> The aversion to code signing lies more in the money, effort and required
>> knowledge associated with it.
> Hypothetical question: If Mozilla or an independent organization could
> provide this service for free and reduce the efforts require
Why not use digital certificates provided by CACert. They are free, and
have high levels of assurity, as opposed to a CAs like Verisign that
have little to no assurity, and charge a ransom.
Gervase Markham wrote:
> Jean-Marc Desperrier wrote:
>> I agree. *Therefore* Mozilla.org need to have it's
Nils Maier wrote:
The aversion to code signing lies more in the money, effort and required
knowledge associated with it.
Hypothetical question: If Mozilla or an independent organization could
provide this service for free and reduce the efforts required to a
minimum, would this solve the proble
Jean-Marc Desperrier wrote:
> I agree. *Therefore* Mozilla.org need to have it's own code signing
> authority, and only accept code signed by it. You have all the
> competence needed on this group to help you set it up.
Where in this group is there competence and experience in worldwide
identit
Gervase Markham wrote:
> Nelson B wrote:
>> This scheme is intended to make code signatures unnecessary. (Someone
>> at mozilla is allergic to code signing, evidently.) But at the cost that
>> mozilla must be given the new hashes for any new addons and any new
>> updates
>> to addons.
>
> Not a
Gervase Markham wrote:
Not allergic; we don't want to accept sucky code-signing certs, and we
don't want app authors to have to pay lot of money for non-sucky ones.
LOLcan you define sucky in relation to code-signing?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL
Nelson B wrote:
> This scheme is intended to make code signatures unnecessary. (Someone
> at mozilla is allergic to code signing, evidently.) But at the cost that
> mozilla must be given the new hashes for any new addons and any new updates
> to addons.
Not allergic; we don't want to accept suck
Dave Townsend wrote:
> It doesn't cover those that won't pay for the SSL and don't want to host
> on AMO. Yes there are people saying they are in that situation. Numbers
> are difficult to guess at though.
I'm sure there are people saying they are in that situation; there are
people who want so
Nelson B schrieb:
> As I understand it, presently the downloads of mozilla addons are
> validated not with code signatures but by the following method:
> A hash of the file is stored on an https server operated by mozilla,
> the actual file may be downloaded from anywhere, by any means including
>
Kai Engert wrote:
> Nelson B schrieb:
>> Dave Townsend wrote:
>>
>>> Nelson Bolyard wrote:
>>>
$18/year is too expensive, eh?
>>> Heh, this is true. My attempts to find cheap SSL certificates had only
>>> yielded $100/per year jobs. Given that they are not that expensive I
Dave Townsend schrieb:
> Nils Maier wrote:
>> Addressing Dave's demand for proposals:
>
> Sorry but I didn't actually demand proposals. I gave one and asked for
> opinions on it. I am of course open to other proposals and a few have
> been given.
>
>> If there is no workable solution then don't i
Nils Maier wrote:
> Addressing Dave's demand for proposals:
Sorry but I didn't actually demand proposals. I gave one and asked for
opinions on it. I am of course open to other proposals and a few have
been given.
> If there is no workable solution then don't implement one.
As far as I can tell
Dave Townsend schrieb:
> Gervase Markham wrote:
>> Dave Townsend wrote:
>>> Some examples that I have heard (or experienced myself):
>>>
>>> Long review times leading to slow updates for the users.
>>> Dissatisfaction with the new Sandbox.
>>> Poor download statistics.
>>> Restrictions on what kind
Gervase Markham wrote:
> Dave Townsend wrote:
>> Some examples that I have heard (or experienced myself):
>>
>> Long review times leading to slow updates for the users.
>> Dissatisfaction with the new Sandbox.
>> Poor download statistics.
>> Restrictions on what kind of add-ons they will host.
>> R
Gervase Markham wrote:
>
> The question is: how much harder is "harder"? Anyone can write an
> extension and make it available for free to the world today, paying not
> a penny. OK, so the service isn't instantaneous, and they don't get
> great stats. But it's free!
>
Gerv, I think stats is s
Gervase Markham wrote:
> OK. So instead of using our resource to fix these things, we are fixing
> the problem that they can't afford $40 for SSL hosting?
>
> a.m.o. isn't the best thing, but it's free. Hosting your own with SSL
> isn't free, but it gives you more flexibility. I really think the
Dave Townsend wrote:
> Yes that plan allows everyone to host, however we are forcing them down
> a path they previously didn't want, i.e. hosting on AMO, or paying for
> the privilege of writing extensions.
>
> Don't get me wrong, I would almost love it if this was the chosen route,
> it's a pi
Dave Townsend wrote:
> Some examples that I have heard (or experienced myself):
>
> Long review times leading to slow updates for the users.
> Dissatisfaction with the new Sandbox.
> Poor download statistics.
> Restrictions on what kind of add-ons they will host.
> Restrictions on the application
Kai Engert wrote:
> Wouldn't he require an object-signing aka code-signing cert?
Not as I understand it. We are talking about making sure that the
downloaded file is the correct file, not making sure that the code is
traceable back to a particular named individual. That's a separate issue.
Gerv
Hi Kai,
Kai Engert wrote:
Nelson B schrieb:
I have heard that SSL server certs are available for FREE from Startcom
(one of the CAs already known to mozilla products) at this web page:
http://cert.startcom.org/
Wouldn't he require an object-signing aka code-signing cert?
Are those ava
Nelson B schrieb:
> Dave Townsend wrote:
>
>> Nelson Bolyard wrote:
>>
>>> $18/year is too expensive, eh?
>>>
>> Heh, this is true. My attempts to find cheap SSL certificates had only
>> yielded $100/per year jobs. Given that they are not that expensive I
>> have started doing a st
Gervase Markham wrote:
> Dave Townsend wrote:
>> Indeed, the issue is with add-on authors who do not want to host on
>> AMO (for a variety of quite valid reasons).
>
> Could you expand on what those reasons are?
Some examples that I have heard (or experienced myself):
Long review times leading
Gervase Markham wrote:
> Benjamin Smedberg wrote:
>> We already support hashes specified by the upate.rdf for the XPI, and AMO
>> uses this to serve the XPIs over http. However, the issue at hand is when
>> the extension has nothing to do with AMO, and serves the update.rdf over
>> HTTP or the XPI
Dave Townsend wrote:
> Indeed, the issue is with add-on authors who do not want to host on AMO
> (for a variety of quite valid reasons).
Could you expand on what those reasons are?
> A compromise allowing authors to
> host their xpis on their own sites but the update.rdf on AMO or some
> othe
Benjamin Smedberg wrote:
> We already support hashes specified by the upate.rdf for the XPI, and AMO
> uses this to serve the XPIs over http. However, the issue at hand is when
> the extension has nothing to do with AMO, and serves the update.rdf over
> HTTP or the XPI over HTTP without specifying
Nils Maier wrote:
> But that was never my point anyway (I talked about collisions)... And
> does not make md5 less broken than I claimed and researchers found it was.
MD5 is not "broken" or "not broken" - it depends on your particular
application. In this case, the attacker would need to generate
Benjamin Smedberg wrote:
> Gervase Markham wrote:
>
>> This seems like the right solution to me. In fact, I had assumed it was
>> already the case, and that we were trying to solve the other half of the
>> problem.
>
> We already support hashes specified by the upate.rdf for the XPI, and AMO
> us
Gervase Markham schrieb:
> Nils Maier wrote:
> [...]
>> PS: the Link-Fingerprints "standard" says:
>>> Clients are encouraged not to implement any hash algorithms other
>>> than MD5 and SHA-256, until and unless SHA-256 is found to have flaws.
>> MD5 is broken, you can find collisions in just hours
Gervase Markham wrote:
> This seems like the right solution to me. In fact, I had assumed it was
> already the case, and that we were trying to solve the other half of the
> problem.
We already support hashes specified by the upate.rdf for the XPI, and AMO
uses this to serve the XPIs over http. H
Nils Maier wrote:
> Link-Fingerprints cannot solve the problem of update.rdf-over-HTTP as
> update.rdf is likely to update often and you cannot compute hash(es) for
> it in advance.
I didn't suggest that it could.
> If you're proposing that all extensions or at least their update.rdf
> must be se
Dave Townsend wrote:
> Gervase Markham wrote:
>> Dave Townsend wrote:
>>> What I want is to be able to be able to establish some trust that the
>>> update file retrieved is correct, and has not been tampered with,
>>> intercepted and is as it was originally written by the add-on author.
>>
>> Lin
Hi Nelson,
Nelson B wrote:
LOL...you mean todays hosting providers are providing support to 40% of
their clients already? ;-)
No, I mean that today, very few hosting providers provide any SSL server
support at all, or do so only at greatly increased cost related to assigning
a fixed IP ad
Eddy Nigg (StartCom Ltd.) wrote:
> Nelson B wrote:
>> Eddy Nigg (StartCom Ltd.) wrote:
>>> ...it will take some time until real hosting providers
>>> can rely on that and deploy without fear...just imagine supporting only
>>> 40% of all clients/browsers ;-)
>>>
>> That's 40% more than they sup
Gervase Markham wrote:
> Dave Townsend wrote:
>> What I want is to be able to be able to establish some trust that the
>> update file retrieved is correct, and has not been tampered with,
>> intercepted and is as it was originally written by the add-on author.
>
> Link Fingerprints was designed
Gervase Markham wrote:
> Dave Townsend wrote:
>> Out of interests besides Mozilla do other browsers support this, IE?
>> Safari? Opera?
>
> Why does that matter? It's Firefox that's going to be downloading the
> updates, isn't it?
Sorry it doesn't matter for the scope of this thread, I was more
Gervase Markham schrieb:
> Dave Townsend wrote:
>> What I want is to be able to be able to establish some trust that the
>> update file retrieved is correct, and has not been tampered with,
>> intercepted and is as it was originally written by the add-on author.
>
> Link Fingerprints was designed
Nelson B wrote:
Eddy Nigg (StartCom Ltd.) wrote:
...it will take some time until real hosting providers
can rely on that and deploy without fear...just imagine supporting only
40% of all clients/browsers ;-)
That's 40% more than they support today, evidently.
LOL...you mean todays hosting
Dave Townsend wrote:
> Out of interests besides Mozilla
> do other browsers support this, IE? Safari? Opera?
Why does that matter? It's Firefox that's going to be downloading the
updates, isn't it?
Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto
Dave Townsend wrote:
> What I want is to be able to be able to establish some trust that the
> update file retrieved is correct, and has not been tampered with,
> intercepted and is as it was originally written by the add-on author.
Link Fingerprints was designed for precisely this purpose, and
Eddy Nigg (StartCom Ltd.) wrote:
> Which means that at least 60 % of all clients don't support it yet. It's
> not there yet and it will take some time until real hosting providers
> can rely on that and deploy without fear...just imagine supporting only
> 40% of all clients/browsers ;-)
That's 40
Hi Nelson,
Nelson B wrote:
Well, then let me introduce you to "Server Name Indication" (SNI). It's
SSL on port 443 (could be any port, such as the port for IMAP-over-SSL, that
negotiates SSL before starting the application protocol [http, IMAP, etc.]).
Right, but on the server side it's not
I wrote:
>>> There is no unique IP address required any more. Modern TLS implementations
>>> like the one in Mozilla products, allow the client and server to negotiate
>>> the host name over the SSL connection, before the server presents its cert,
>>> So that the server can pick the right cert. I
Dave Townsend wrote:
Nelson B wrote:
There is no unique IP address required any more. Modern TLS implementations
like the one in Mozilla products, allow the client and server to negotiate
the host name over the SSL connection, before the server presents its cert,
So that the server can pick
Nelson B wrote:
> There is no unique IP address required any more. Modern TLS implementations
> like the one in Mozilla products, allow the client and server to negotiate
> the host name over the SSL connection, before the server presents its cert,
> So that the server can pick the right cert. It
Dave Townsend wrote:
> Nelson B wrote:
>> Dave Townsend wrote:
>>> Nelson Bolyard wrote:
$18/year is too expensive, eh?
>>> Heh, this is true. My attempts to find cheap SSL certificates had only
>>> yielded $100/per year jobs. Given that they are not that expensive I
>>> have started doing a s
Nelson B wrote:
> Dave Townsend wrote:
>> Nelson Bolyard wrote:
>>> $18/year is too expensive, eh?
>> Heh, this is true. My attempts to find cheap SSL certificates had only
>> yielded $100/per year jobs. Given that they are not that expensive I
>> have started doing a straw poll of authors to see
Dave Townsend wrote:
> Nelson Bolyard wrote:
>> $18/year is too expensive, eh?
>
> Heh, this is true. My attempts to find cheap SSL certificates had only
> yielded $100/per year jobs. Given that they are not that expensive I
> have started doing a straw poll of authors to see whether that would
Nelson Bolyard wrote:
>
> $18/year is too expensive, eh?
>
Heh, this is true. My attempts to find cheap SSL certificates had only
yielded $100/per year jobs. Given that they are not that expensive I
have started doing a straw poll of authors to see whether that would be
too much or not.
Dave
Dave Townsend wrote:
> Hi all, I am looking for some feedback on a proposal I'm working on to
> improve the security of add-on updates in Mozilla products. Let me give
> an overview of the problem I wish to solve and then what I have come up
> with so far as a potential solution.
>
> In the Mozill
so, essentially, you're trying to create a "key continuity" system
rather than a "trusted certification" system. As you point out, the
initial bootstrapping is outside the realm of what can be dealt with.
A public/private key pair could just as easily have a certificate
created for it (self-signe
Hi all, I am looking for some feedback on a proposal I'm working on to
improve the security of add-on updates in Mozilla products. Let me give
an overview of the problem I wish to solve and then what I have come up
with so far as a potential solution.
In the Mozilla applications we have an add-
61 matches
Mail list logo
