Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 21:04, Ryan Sleevi wrote:

On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


That's my point.  The current situation is distinct from weak keys, and
we shouldn't sacrifice the weak keys BR to make room for a compromised
keys BR.



But a weak key is always suspected of having suffered a Key Compromise - is
it not?




That is, changing to from "weak keys" to "suspected or known to have
suffered Key Compromise" in 6.1.1.3 would fully include weak keys (which
are already in scope) as well as include those excluded (compromised,
strong). This applies in addition to the requirements already present in
6.1.5/6.1.6 regarding key sizes and strengths (which already counter your
hypothetical), and 4.9.1.1/4.9.1.2 address the situation if a strong key,
post issuance, becomes either weak or compromised.



I would say a key whose strength against attack is significantly below
that of normally accepted keys (say 256 times less work factor with the
best known attack) would be a weak key, even though that might still
require a year or more on the best known hardware at fort Meade.

A suspected key compromise is a higher degree of badness (say > 0.01%
chance that attackers will have the key now or in the next 72 hours).

Heartbleed, Debian weak keys or leaving the private key in a public
place would be suspected or actual key compromise, because attackers may
have already gotten the private key using a known attack and almost
trivial effort, and there is no way to tell.

A 2048 bit RSA key which somehow has only the cryptographic strength
normally associated with a 1536 bit RSA key would be a weak key, but
still unlikely to be cracked within a few weeks of revealing the public
key.  And since an actual 1536 bit RSA key would be too weak to allow
issuance under BR 6.1.5, issuing a new certificate issued to such a
"special form" 2048 bit RSA key would be reasonably considered against
6.1.1.3 .

Now we obviously don't know the nature of yet-to-be-published 
cryptanalytical attacks, but if a new attack applies to only some keys, 
and those keys can be identified from the public keys, similar to how 
there is currently a formula for detecting "weak SHA-1" hashes, then CAs 
should apply that formula in a pre-issuance test under 6.1.1.3, but 
would not require instant revocation of all such keys under 4.9.1.2 #3, 
though CA subscribers would be encouraged to voluntarily reissue and 
revoke such keys as they are spotted by e.g. Qualsys SSL checks or 
database scans by the CA.


P.S.

The classical example of "weak keys" is of cause the special forms of
DES symmetric keys that were known 30 years ago, at a time when cracking
regular full DES keys was still beyond most attackers.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> That's my point.  The current situation is distinct from weak keys, and
> we shouldn't sacrifice the weak keys BR to make room for a compromised
> keys BR.


But a weak key is always suspected of having suffered a Key Compromise - is
it not?

That is, changing to from "weak keys" to "suspected or known to have
suffered Key Compromise" in 6.1.1.3 would fully include weak keys (which
are already in scope) as well as include those excluded (compromised,
strong). This applies in addition to the requirements already present in
6.1.5/6.1.6 regarding key sizes and strengths (which already counter your
hypothetical), and 4.9.1.1/4.9.1.2 address the situation if a strong key,
post issuance, becomes either weak or compromised.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 18:19, Ryan Sleevi wrote:

On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 14/07/2017 15:53, Ryan Sleevi wrote:


On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:



But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme example).



Yes. Because that's clearly not necessary - because it's already covered
by
4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
criticism to the proposed update.



That's why I called it an "extreme example".  Point was that the current
wording requires CAs to reject public keys that fail any reasonable test
for weakness not just the explicit cases listed in the BRs (such as too
short RSA keys or small composite public exponents).

For example if it is published that the RSA requirements in 6.1.6 are
insufficient (for example that moduli with more than 80% 1-bits are
weak), then the current wording of 6.1.1.3 would require CAs to
instigate such a test without waiting for a BR update.



Sure, but that's unrelated to the discussion at hand, at least from what
you've described. However, if I've misunderstood you, it might help if you
rephrase the argument from what was originally being discussed - which is
CAs issuing certificates for compromised keys - which are arguably distinct
from weak keys (which was the point I was making).



That's my point.  The current situation is distinct from weak keys, and
we shouldn't sacrifice the weak keys BR to make room for a compromised
keys BR.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 14/07/2017 15:53, Ryan Sleevi wrote:
>
>> On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> But that doesn't clearly include keys that are weak for other reasons,
>>> such as a 512 bit RSA key with an exponent of 4 (as an extreme example).
>>>
>>>
>> Yes. Because that's clearly not necessary - because it's already covered
>> by
>> 4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
>> criticism to the proposed update.
>>
>>
> That's why I called it an "extreme example".  Point was that the current
> wording requires CAs to reject public keys that fail any reasonable test
> for weakness not just the explicit cases listed in the BRs (such as too
> short RSA keys or small composite public exponents).
>
> For example if it is published that the RSA requirements in 6.1.6 are
> insufficient (for example that moduli with more than 80% 1-bits are
> weak), then the current wording of 6.1.1.3 would require CAs to
> instigate such a test without waiting for a BR update.
>

Sure, but that's unrelated to the discussion at hand, at least from what
you've described. However, if I've misunderstood you, it might help if you
rephrase the argument from what was originally being discussed - which is
CAs issuing certificates for compromised keys - which are arguably distinct
from weak keys (which was the point I was making).

It sounds like you're saying "No, they're weak" - but I both acknowledged
and refuted that interpretation in my message, so perhaps I simply do not
understand the relation of what you're discussing above to the general
issue Hanno raised.


> Maybe it would be better stylistically to add this to one of the other
>>> BR clauses.
>>>
>>>
>> Considering that the goal is to make it clearer, I'm not sure this
>> suggestion furthers that goal.
>>
>>
> It could be in a new clause 6.1.1.3.1 (not applicable to SubCAs) or a
> new clause 6.1.1.4 (applicable to all public keys, not just subscribers)
> or a new clause 6.1.6.1 (ditto), or it could be added as an additional
> textual paragraph in 6.1.1.3 or 6.1.6 .
>

I'm afraid at this point, I'm completely lost as to the point you're trying
to make.

But at least 4.9.1.1 #3 requires them to revoke without waiting for a
> new report.


No, "it depends". And that was the point I was trying to make.


> And it would be obviously and patently bad faith to revoke
> the same key every 24 hours and claim all is well (once or twice may be
> an understandable oversight, since this is not such a common scenario,
> but after that they should start automating the rejection/revocation).


I don't think you can or should ascribe bad faith here; my entire point was
to highlight the possible interpretation issues - but to further highlight
why the thing you call "patently bad faith" is itself fraught with peril,
and thus it's reasonable to argue that it's not bad faith.

If this is not desirable, we should strive to make it clearer - but that
means acknowledging the edge cases, determining what is appropriate, and
providing sufficient guidance so that, in the future, it might be more
successfully argued as bad faith.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 16:07, Alex Gaynor wrote:

On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

...

>> ...

Ultimately I'm inclined to say that there really shouldn't be any good
reason at all to ever reuse a key. (Except... HPKP)



I see. I think I'd strongly disagree with that assertion. There are lots of
good reasons to reuse keys. The most obvious example being for
shorter-lived certificates (e.g. 90 days), which allow you to rotate the
key in case of compromise, but otherwise don't require you to do so.
Considering revocation information is no longer required to be provided
once a certificate expires, it _also_ means that in the CA Foo case, with
Key X compromised, the subscriber could get another cert for it once the
original cert has expired (and thus revocation information no longer able
to be provided)



What you described is a case where it's not harmful to reuse a key, not a
case in which it's a good reason to. Indeed defaulting to rotating your key
on every new certificate is probably the safest choice, as it ensures that
"key compromise" is no different from any other rotation, and keeps that
hinge well oiled.



His scenario did include "Key X compromised" .


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 15:53, Ryan Sleevi wrote:

On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme example).



Yes. Because that's clearly not necessary - because it's already covered by
4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
criticism to the proposed update.



That's why I called it an "extreme example".  Point was that the current
wording requires CAs to reject public keys that fail any reasonable test
for weakness not just the explicit cases listed in the BRs (such as too
short RSA keys or small composite public exponents).

For example if it is published that the RSA requirements in 6.1.6 are
insufficient (for example that moduli with more than 80% 1-bits are
weak), then the current wording of 6.1.1.3 would require CAs to
instigate such a test without waiting for a BR update.




Maybe it would be better stylistically to add this to one of the other
BR clauses.



Considering that the goal is to make it clearer, I'm not sure this
suggestion furthers that goal.



It could be in a new clause 6.1.1.3.1 (not applicable to SubCAs) or a
new clause 6.1.1.4 (applicable to all public keys, not just subscribers)
or a new clause 6.1.6.1 (ditto), or it could be added as an additional
textual paragraph in 6.1.1.3 or 6.1.6 .




Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not
be obvious to the CA that they should have set up checks for this, since
most key compromise reports come from the subscriber, who would be a lot
less likely to make this mistake after revoking the key themselves,
except when the revocation was mistaken (this happens, and in that case,
reusing the key is not a big problem).



I'm afraid you may have misunderstood the point. Certainly, 4.9.1.1 #3
covers revocation. However, my suggestion was about preventing issuance,
which is why I was talking about 6.1.1.3. That is, unquestionably, if a CA
revokes a certificate for key compromise, then issues a new one for that
same key, they're obligated under 4.9.1.1 #3 to revoke within 24 hours. My
point was responding to Hanno's suggestion of preventing them from issuing
the second certificate at all.



But at least 4.9.1.1 #3 requires them to revoke without waiting for a
new report.  And it would be obviously and patently bad faith to revoke
the same key every 24 hours and claim all is well (once or twice may be
an understandable oversight, since this is not such a common scenario,
but after that they should start automating the rejection/revocation).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Alex Gaynor via dev-security-policy]

On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > So there are several questions and possible situations here.
> >
> > I think it's relatively clear that a CA could prevent reissuance of
> > certs if they know about a key compromise.
> >
>
> I actually don't think it's clear, that's why I was trying to highlight the
> challenges.
>
> That is, I think we can all agree that for situations where you reported
> directly to the CA, it was clear that the CA had knowledge that the
> associated private key was compromised. Presumably, a requirement to
> prevent issuance would mean that the CA maintains a blacklist of
> 'compromised keys' and refuses to issue certificates for them.
>
> However, if we say that the CA shall not prevent for situations of
> compromise, the following interpretations exist, and we should try to
> figure out first what we want (from an ecosystem) and then how to specify
> that.
> - Are we expecting the CA to maintain a database of compromised private
> keys (I believe the implied answer is 'yes' - but today, they only need
> maintain the database of revoked certificates, which is different)
> - Is the CA obligated to check other sources of compromise information
> prior to issuing the certificate.
>   - Example: Should they check other CAs' CRLs? The CRLs themselves don't
> provide information about the key, so one would presumably _also_ need to
> check sources like Certificate Transparency.
>   - Tortured example: What happens if a (different CA's) cert is not logged
> in CT, revoked in the CRL (for keyCompromise), and then subsequently
> disclosed to first CA. Are they obligated to revoke (under 4.9.1.1 #3)? Are
> they obligated to not issue (under the proposed change)?
>
> The reason I highlight this is that preventing CA "Foo" from issuing a
> second cert for (compromised) key X doesn't prevent CA "Bar" from doing the
> same. Because of this, it's a reasonable question about what security value
> we're obtaining, if the party with Key X can simply go to another CA to get
> the cert.
>
> From a CA perspective, requiring that Foo reject a request that Bar can
> accept would be unappealing to Foo - it's effectively giving business to
> Bar (whether or not this is actually the case, and however illogical it is,
> there are plenty of CAs who think this way)
>
> From a security perspective, requiring that Foo not issue for key X doesn't
> ensure that a cert for key X will not be introduced, not unless we make the
> requirement of all CAs.
>
> So that's why I'm not sure how much value we'd get from such a requirement
> - and wanted to highlight the challenges in finding a way to establish it
> for all CAs, and why it's important (for CAs and relying parties) for a
> consistent requirement.
>
>
> > Ultimately I'm inclined to say that there really shouldn't be any good
> > reason at all to ever reuse a key. (Except... HPKP)
>
>
> I see. I think I'd strongly disagree with that assertion. There are lots of
> good reasons to reuse keys. The most obvious example being for
> shorter-lived certificates (e.g. 90 days), which allow you to rotate the
> key in case of compromise, but otherwise don't require you to do so.
> Considering revocation information is no longer required to be provided
> once a certificate expires, it _also_ means that in the CA Foo case, with
> Key X compromised, the subscriber could get another cert for it once the
> original cert has expired (and thus revocation information no longer able
> to be provided)
>

What you described is a case where it's not harmful to reuse a key, not a
case in which it's a good reason to. Indeed defaulting to rotating your key
on every new certificate is probably the safest choice, as it ensures that
"key compromise" is no different from any other rotation, and keeps that
hinge well oiled.

Alex


> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> So there are several questions and possible situations here.
>
> I think it's relatively clear that a CA could prevent reissuance of
> certs if they know about a key compromise.
>

I actually don't think it's clear, that's why I was trying to highlight the
challenges.

That is, I think we can all agree that for situations where you reported
directly to the CA, it was clear that the CA had knowledge that the
associated private key was compromised. Presumably, a requirement to
prevent issuance would mean that the CA maintains a blacklist of
'compromised keys' and refuses to issue certificates for them.

However, if we say that the CA shall not prevent for situations of
compromise, the following interpretations exist, and we should try to
figure out first what we want (from an ecosystem) and then how to specify
that.
- Are we expecting the CA to maintain a database of compromised private
keys (I believe the implied answer is 'yes' - but today, they only need
maintain the database of revoked certificates, which is different)
- Is the CA obligated to check other sources of compromise information
prior to issuing the certificate.
  - Example: Should they check other CAs' CRLs? The CRLs themselves don't
provide information about the key, so one would presumably _also_ need to
check sources like Certificate Transparency.
  - Tortured example: What happens if a (different CA's) cert is not logged
in CT, revoked in the CRL (for keyCompromise), and then subsequently
disclosed to first CA. Are they obligated to revoke (under 4.9.1.1 #3)? Are
they obligated to not issue (under the proposed change)?

The reason I highlight this is that preventing CA "Foo" from issuing a
second cert for (compromised) key X doesn't prevent CA "Bar" from doing the
same. Because of this, it's a reasonable question about what security value
we're obtaining, if the party with Key X can simply go to another CA to get
the cert.

From a CA perspective, requiring that Foo reject a request that Bar can
accept would be unappealing to Foo - it's effectively giving business to
Bar (whether or not this is actually the case, and however illogical it is,
there are plenty of CAs who think this way)

From a security perspective, requiring that Foo not issue for key X doesn't
ensure that a cert for key X will not be introduced, not unless we make the
requirement of all CAs.

So that's why I'm not sure how much value we'd get from such a requirement
- and wanted to highlight the challenges in finding a way to establish it
for all CAs, and why it's important (for CAs and relying parties) for a
consistent requirement.


> Ultimately I'm inclined to say that there really shouldn't be any good
> reason at all to ever reuse a key. (Except... HPKP)


I see. I think I'd strongly disagree with that assertion. There are lots of
good reasons to reuse keys. The most obvious example being for
shorter-lived certificates (e.g. 90 days), which allow you to rotate the
key in case of compromise, but otherwise don't require you to do so.
Considering revocation information is no longer required to be provided
once a certificate expires, it _also_ means that in the CA Foo case, with
Key X compromised, the subscriber could get another cert for it once the
original cert has expired (and thus revocation information no longer able
to be provided)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> But that doesn't clearly include keys that are weak for other reasons,
> such as a 512 bit RSA key with an exponent of 4 (as an extreme example).
>

Yes. Because that's clearly not necessary - because it's already covered by
4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
criticism to the proposed update.


> Maybe it would be better stylistically to add this to one of the other
> BR clauses.
>

Considering that the goal is to make it clearer, I'm not sure this
suggestion furthers that goal.


> Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not
> be obvious to the CA that they should have set up checks for this, since
> most key compromise reports come from the subscriber, who would be a lot
> less likely to make this mistake after revoking the key themselves,
> except when the revocation was mistaken (this happens, and in that case,
> reusing the key is not a big problem).
>

I'm afraid you may have misunderstood the point. Certainly, 4.9.1.1 #3
covers revocation. However, my suggestion was about preventing issuance,
which is why I was talking about 6.1.1.3. That is, unquestionably, if a CA
revokes a certificate for key compromise, then issues a new one for that
same key, they're obligated under 4.9.1.1 #3 to revoke within 24 hours. My
point was responding to Hanno's suggestion of preventing them from issuing
the second certificate at all.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Hanno Böck via dev-security-policy]

On Wed, 12 Jul 2017 10:47:51 -0400
Ryan Sleevi  wrote:

> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued
> another certificate with that key, arguably that's something Comodo
> should have caught. However, if you reported the compromise to, say,
> ACME CA, and then Comodo issued an equivalent cert, that's
> questionable. I'm loathe to make CAs rely on eachothers'
> keyCompromise revocation reasons, simply because we have no normative
> guidance in the BRs (yet) that require CAs be honest or competent
> with their revocation reasons (... yet). Further, we explicitly don't
> want to have a registry (of compromised keys, untrustworthy orgs,
> etc), for various non-technical reasons.
> 
> I'm curious if you have thoughts there - particularly, how you
> reported the private key was compromised (did you provide evidence -
> for example, a signed message, or simply a link to "Here's the URL,
> go see for yourself"?)
> - and how you see it working cross-CA boundaries.

To answer this question: As the private keys were available on webpages
I simply reported the URLs and corresponding certs to the CAs.
(This was also with the intention that in case the CA has a contact to
their customer they could inform them about the key on their server,
though I'm not sure if any CA informed them.)

So there are several questions and possible situations here.

I think it's relatively clear that a CA could prevent reissuance of
certs if they know about a key compromise.

Another question is if there has been a revocation that wasn't clearly
tied to a key compromise. On the other hand I hardly see any reason why
anyone would revoke a cert if there isn't any indication of a
compromise.

The next question would be if there should be a cross-CA blacklisting
of compromised keys. I think that would be valuable, but of course it
raises a lot of questions on how this information should be shared
(share the private keys? public keys? spki hashes? share it in public
or only between CAs?).

Ultimately I'm inclined to say that there really shouldn't be any good
reason at all to ever reuse a key. (Except... HPKP)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign new system passed Cure 53 system security audit

[okaphone.elektronika--- via dev-security-policy]

On Friday, 14 July 2017 04:44:39 UTC+2, Richard Wang  wrote:
> Hi Peter,
> 
> Thanks for your guesses.
> Buy no those issues in our system.
> 
> 
> Best Regards,
> 
> Richard

That's what you say. But you've lied before. :-( So sorry, but that won't go 
anywhere near regaining trust. You'll have to be quite a bit more transparant 
before anything you say will be believed.

I really don't see why you post this summary at a time when you have not yet 
told us anything about the items that went before it. Or should have gone 
before?

The summary itself doesn't say much. But some things can be read between the 
lines.

There was a penetration test and they found problems which you then fixed 
quickly. Sounds like you did not do anything about the reason why those 
problems were in your code. So there will probably be more. That in itself is 
not surprising, but a team that quickly fixes those problem is. They should 
instead have done an an analyses why those problems were there in the first 
place and fixed there software development practices/process, then let that 
take care of fixing the problems.

There was a code review. But we don't hear anything about what the outcome was. 
There may have been findings but more import is what the overall quality of the 
code is. And still more important is what the quality of your development 
process is.

Are there unit tests, integration tests, what is the coverage, how complete is 
the documentation, specs, structure of the code, how good the layering, how 
complex is it, how maintainable, how correct, are you using version control, 
release management, code quality scanners?

All that is not covered by a penetration test and only some of it by a code 
review. So item five is really not all that important. It is just an extra 
insurance that all is well after all the other work has been done.

I still think that it would make most sense to start by showing us this item 
one. That would be a real step towards regaining trust.

CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy