Eddy Nigg wrote:
So IMO you get points for prompt disclosure and fixes, but in the end
you messed up just like Comodo and CertStar did.
Nonono :-)
I see the main differences as followed and I believe the main
differences are policy wise (and allow me to comment on this since you
made the
Eddy Nigg wrote:
On 01/03/2009 05:38 AM, Eddy Nigg:
Before anybody else does, I prefer from posting it myself :-)
http://blog.phishme.com/2009/01/nobody-is-perfect/
http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html
For the interested, StartCom is currently checking if I can release
On 01/05/2009 06:44 PM, Paul Hoffman:
At 6:08 PM +0200 1/5/09, Eddy Nigg wrote:
Therefor we can't lump just all failures together and as you correctly stated,
there is no clear line between one and the other. This is what I was saying.
What you said was As I see it, our case indeed was a
At 6:08 PM +0200 1/5/09, Eddy Nigg wrote:
Therefor we can't lump just all failures together and as you correctly stated,
there is no clear line between one and the other. This is what I was saying.
What you said was As I see it, our case indeed was a bug, the Comodo case was
negligence. That
On 01/05/2009 04:56 PM, Gervase Markham:
I am not saying the two incidents were the same - I think every incident
has to be assessed individually. I am just saying that you cannot make
such a division so quickly and easily.
Not quickly and easily - agree on that. And every incident needs to
Eddy Nigg wrote:
As I see it, our case indeed was a bug, the Comodo case was negligence.
There is no clear line between one and the other. You are saying the
Comodo case was negligence because the bug was so obvious that they
should have spotted it. But the obviousness of bugs is a gradated
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman phoff...@proper.com wrote:
I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The
topics for that list would include:
- All new trust anchors being added to the Mozilla trust anchor pile
- Proposals for changes to the
At 1:35 PM -0800 1/5/09, Wan-Teh Chang wrote:
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman phoff...@proper.com wrote:
I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The
topics for that list would include:
- All new trust anchors being added to the Mozilla trust
At 12:11 AM +0100 1/4/09, Jan Schejbal wrote:
Why is this relevant to this mailing list?
Because there was a security failure in one of the Firefox trusted CAs
allowing anyone to get fake certificates. This event and the reaction of the
CA are important to determine if the CA is (still)
On 3/1/09 04:38, Eddy Nigg wrote:
Before anybody else does, I prefer from posting it myself :-)
http://blog.phishme.com/2009/01/nobody-is-perfect/
http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html
For the interested, StartCom is currently checking if I can release our
internal
On 01/03/2009 04:43 PM, Ian G:
What incentive exists for a CA in disclosing an apparent weakness?
Quite frankly, none.
We've seen both sides over the last 2-3 weeks.
Not entirely correct...but...
So I guess there are two questions:
1. do we want to live in the world of open
On 1/3/2009 6:43 AM, Ian G wrote:
On 3/1/09 04:38, Eddy Nigg wrote:
Before anybody else does, I prefer from posting it myself :-)
http://blog.phishme.com/2009/01/nobody-is-perfect/
http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html
For the interested, StartCom is currently checking
Why is this relevant to this mailing list?
--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 03.01.2009 07:18, Eddy Nigg wrote:
The validations wizard allows for a selection of a few possible email
addresses considered for administrative purpose or as listed in the
whois records of the domain name. The flaw was, that insufficient
verification of the response at the server side was
On 03.01.2009 16:48, Eddy Nigg wrote:
...I wouldn't be willing to disclose each and every detail of code,
preventive measures, controls and procedures and possible events.
Well, I think this might be a good idea, though. I could even go so far
as to demand that all operations of the CA,
Paul Hoffman wrote:
Why is this relevant to this mailing list?
Doesn't it go along with the other are CA's trustworthy? threads?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy Nigg wrote, On 2009-01-02 22:18:
The attack was performed by using said tool above or by using a modified
version of the browser. By hooking this tool between the server and
browser, the tool allows to change the values coming to and from the
browser.
I hate to say it, but it's
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another way, but I'm glad to learn how.
So let me ask: Did Mike Zusman confirm that he
On 03.01.2009 20:01, Eddy Nigg wrote:
the other layers of defense
Please don't call the blacklist a real layer of defense. If he didn't
try to get a cert for paypal.com, it would have worked. All layers
failed. Please be honest enough to yourself to admit that, so that you
can try to find
On 03.01.2009 20:03, Eddy Nigg wrote:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another way, but I'm glad to learn how.
You can
On 01/03/2009 10:03 PM, Ben Bucksch:
On 03.01.2009 20:01, Eddy Nigg wrote:
the other layers of defense
Please don't call the blacklist a real layer of defense. If he didn't
try to get a cert for paypal.com, it would have worked. All layers
failed. Please be honest enough to yourself to admit
Eddy Nigg wrote, On 2009-01-02 22:18:
[...] The flaw was, that insufficient verification of the response at
the server side was performed, allowing him to validate the domain by
using a different email address than the validations wizard actually
provided. [...]
Additionally all steps of
On 01/03/2009 11:33 PM, Nelson B Bolyard:
Additionally all steps of the subscribers are always logged (yes, every
click of it) and we have records about every validation and about which
email address was used for it, failed attempts etc. With those records
could we re-validate all certificates
Eddy Nigg wrote, On 2009-01-03 11:03:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another way, but I'm glad to learn how.
It's
On 01/03/2009 11:54 PM, Nelson B Bolyard:
Eddy Nigg wrote, On 2009-01-03 11:03:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using some proxy
tool.
I don't know another
Eddy Nigg wrote, On 2009-01-03 13:38:
On 01/03/2009 11:33 PM, Nelson B Bolyard:
Additionally all steps of the subscribers are always logged (yes, every
click of it) and we have records about every validation and about which
email address was used for it, failed attempts etc. With those records
Eddy Nigg wrote, On 2009-01-03 14:25:
On 01/03/2009 11:54 PM, Nelson B Bolyard:
Eddy Nigg wrote, On 2009-01-03 11:03:
On 01/03/2009 09:03 PM, Nelson B Bolyard:
I hate to say it, but it's possible for the browser user to change those
values without either (a) modifying the browser or (b) using
On 01/03/2009 11:59 PM, Nelson B Bolyard:
As I understand it, Eddy, the situation with CertStar was a bug which
caused the code to simply fail to invoke the facilities that do the DV
validation (or verification, or whatever the right term is for that).
If that were correct, just a
Why is this relevant to this mailing list?
Because there was a security failure in one of the Firefox trusted CAs
allowing anyone to get fake certificates. This event and the reaction
of the CA are important to determine if the CA is (still) trustworthy.
It's the same as the Commodo thing.
On 01/03/2009 05:38 AM, Eddy Nigg:
Before anybody else does, I prefer from posting it myself :-)
http://blog.phishme.com/2009/01/nobody-is-perfect/
http://schmoil.blogspot.com/2009/01/nobody-is-perfect.html
For the interested, StartCom is currently checking if I can release our
internal
On 03.01.2009 04:59, Eddy Nigg wrote:
The report is available from here: https://blog.startcom.org/?p=161
That's surely interesting, but the report does not contain any details
of interest.
It only says
The attack ... involved proxying ,intercepting all communication from
and to the
On 01/03/2009 07:31 AM, Ben Bucksch:
On 03.01.2009 04:59, Eddy Nigg wrote:
The report is available from here: https://blog.startcom.org/?p=161
That's surely interesting, but the report does not contain any details
of interest.
It only says
The attack ... involved proxying ,intercepting all
... I realised that you can do something with Firefox 2.0.x that
you could not do with Firefox 1.5.x: track an unsuspecting user
using TLS client certificates.
this is not new. in a way it has been in the apache
documentation for years. it simple, and it's very bad:
a) firefox does not ask
33 matches
Mail list logo
