On 02/05/2009 08:36 PM, Gervase Markham:
Eddy: I don't think Frank is saying that you made the _same_ mistakes as
CertStar (out-sourcing validation etc. etc.), but that you made
_a_mistake_, just like they did. He then goes on to make the point that
making a mistake is not the end of the world.
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
>
On 02/04/2009 08:27 PM, Frank Hecker:
2. I understand that what happened in the case of StartCom was not
exactly the same as what happened in the case of Comodo/CertStar.
However it's part of web security basics to assume that whatever a
client sends to a server is untrusted and must be (re)verif
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 ou
At 1:35 PM -0800 1/5/09, Wan-Teh Chang wrote:
>On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman 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
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman 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 Mozilla trust ancho
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 bug
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
a
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 scal
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) tr
On 01/04/2009 12:46 AM, Nelson B Bolyard:
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 eit
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. Ju
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 walk-through
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
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 thos
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 11:01:
> On 01/03/2009 06:16 PM, Ben Bucksch:
>> Yes, that would have been incredibily stupid,
>> but given what we learned recently about some other CAs... This bug is
>> not too far from that, but at least not that obviously stupid, it can
>> really have been just
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.
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 ve
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 ste
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
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 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 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 01/03/2009 06:16 PM, Ben Bucksch:
Yes, that is (just?) a bug. It does mean that a developer didn't think
correctly - it's a general rule in security to validate all input,
distrust all other parties, and this was not done here.
Correct. Actually it was done, but something in the verificatio
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 p
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
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, includ
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 p
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 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 current
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 disclosure
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 "critica
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 c
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 browse
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 "critic
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 "critical event report" of this event to t
> ... 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
Brendan Dolan-Gavitt wrote:
> Can anyone see if this works through Privoxy and the other things in the
> standard Tor bundle?
It works with Tor with, and without Privoxy.
--
Hawaiian Astronomical Society: http://www.hawastsoc.org
HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky
__
Am Freitag, den 07.09.2007, 10:04 -0400 schrieb Arshad Noor:
> Alex,
>
> Do you presume that the websites in the domains that you intend
> to track users will install the self-signed CA certificate that
> issued the client-certificate to the unsuspecting user? If not,
> how will the browser know
it...
>
> --
> Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
> Jabber: [EMAIL PROTECTED] Blog: Join the
> Revolution!<http://blog.startcom.org>
> Phone: +1.213.341.0390
>
> __
42 matches
Mail list logo
