Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Peter Gutmann via dev-security-policy]

Nick Lamb via dev-security-policy  
writes:

>In order for Symantec to reveal anybody's private keys they'd first need to
>have those keys

That's standard practice for many CAs, they generate the key and certificate
for you and email it to you as a PKCS #12.  It seems to be more common among
lesser-known CAs though, particularly ones with government-mandated monopolies
for some reason, so I'm not sure if Symantec does it.

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[ian--- via dev-security-policy]

On Tuesday, March 28, 2017 at 3:46:05 PM UTC-4, Nick Lamb wrote:
> In order for Symantec to reveal anybody's private keys they'd first need to 
> have those keys, which is already, IIRC forbidden in the BRs. So even proof 
> that Symantec routinely had these keys is a big deal.

>From what I can tell, this may be correct in the context of retainment. Many 
>CAs have provisions to generate the key on the behalf of the subscriber, 
>though. The wording of the section you're probably thinking of (6.1.2) is 
>tricky:

> Parties   other than the Subscriber SHALL NOT archive the Subscriber 
> Private Key without authorization by the Subscriber.

So I guess you would need to see if the subscribers here authorized it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Vincent Lynch via dev-security-policy]

On Tuesday, March 28, 2017 at 11:08:08 PM UTC-4, uri...@gmail.com wrote:
> For what it's worth, this is the latest post on facebook from the researcher.
> https://www.facebook.com/cbyrneiv/posts/10155129935452436
> 
> The private key storage issue sounds like a reseller tool, like
> https://www.thesslstore.com/ssltools/csr-generator.php
> and he found the private key was stored with the reseller,  when he accessed 
> the account.
> 

I work for The SSL Store and just wanted to quickly clarify that Urijah is 
using our site as an example of the *type* of tool that the private key issue 
was related to.

But our specific tool does not store the user's private key in any way. Nor is 
there any scenario in which we store the user's private key or make it 
accessible to them through their account.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[urijah--- via dev-security-policy]

For what it's worth, this is the latest post on facebook from the researcher.
https://www.facebook.com/cbyrneiv/posts/10155129935452436

The private key storage issue sounds like a reseller tool, like
https://www.thesslstore.com/ssltools/csr-generator.php
and he found the private key was stored with the reseller,  when he accessed 
the account.

Chris Byrne
March 24 at 8:02pm · 

UPDATED Tuesday March 28th, to clarify some language, and provide additional 
detail...
..
Looks like I don't have to stay quiet about this one anymore... 
I found out about this problem... and others related to it... back in early 
2015. I warned Symantec about it, and worked through some of the issues with 
them. 
At the end of it, they asked for a chance to verify how extensive the issue 
was, and to fix it. We both agreed it would take up to two years to fix, 
without creating more chaos and causing more damage... and I said yes.
I agreed to limited non-disclosure of the issue, unless I felt it was 
critically necessary, or it would be unethical or irresponsible for me not to 
disclose (for example, if there were a threat to national security, or I 
discovered a compromise of a client, or any actual criminal compromise arising 
from it, etc... etc...). 
That said, I informed Krebs and a few others about what I had found... and also 
that I agreed to let them fix it, because it would be less damaging to the 
world, than exposure would be. 
It was one of those issues where there's no GOOD choice... but I looked at the 
damage immediate exposure would cause, vs. a slowly rolling fix over two 
years... 
I talked to some of my friends on the grey and black sides of things, and did 
my own checking, to see if there was any chatter about this anywhere, and I 
couldn't find any... and I concluded that more harm would be done if I 
disclosed.
Fellow security professional Bobby Kuzma helped me investigate and validate 
these issues, and he can verify what I state here. 
I checked a few months later, and they HAD fixed several of the core 
problems... though not all of them... So I waited, and so did those who I had 
informed about the problem, and had verified it for themselves... 
Unfortunately, late in 2015, my cancer recurred, and spread to my lymph 
nodes... and I've been fighting it ever since, so I haven't kept up with the 
issue. 

So... Here's what the post doesn't mention...
If you purchased a Symantec certificate (or a cert from any of their associated 
subsidiaries and partners) through a third party, from at least as far back as 
early 2013 until recently; their third party certificate generation, 
management, and retrieval API allowed those certificates... including in some 
cases private keys generated by third parties... to be retrieved without proper 
authentication, or in some cases any authentication at all.
Unless the third party added proper security around it, all you had to do was 
click a link sent in email, and you could retrieve a cert, revoke a cert, and 
re-issue a cert... and for some third party vendors, depending on the type of 
certificate, and how the certificate was issued, you could also retrieve 
private keys.
Note, this was not just for server certificates for SSL, it also included other 
certificates, such as personal certificates used for email and other personal 
encryption. These certs could be requested entirely through the web interface 
without a separate server issued certificate request, generating both private 
and public keys, which would then only be protected by a passphrase. 

Further, even with first party purchase, for some time in some web interfaces, 
it was possible for properly authenticated users to edit a URL, and at least 
retrieve information about first party certificates and their owners, and 
possibly the certs of others. 
This is because third party data retrieval was not limited to certificates 
issued by that third party. It was available to anyone by entering the UID of 
any other user. 
To clarify... at no time were we able to retrieve private keys directly from 
Symantec, only from third parties that issued certificates from a web interface 
without requiring a server generated certificate request.
We were able to confirm that these third party weaknesses extended to 
retreiving, revoking, and reissuing certificates, in some cases without 
notification to the legitimate certificate holder.
In one case, we were also able to reissue a certificate without first 
explicitly revoking it, and the original certificate continued working for at 
least 48 hours... We did not test further to see how long it would take for the 
certificate revocation list to propagate, and we're not pale to prove one way 
or the other if the organ certificate was revoked or not. 

It is possible that the certificate was never revoked at all, and another 
certificate was simply issued, leaving two valid certificates one controlled by 
the original requestor, and one controlled by the 

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Nick Lamb via dev-security-policy]

In order for Symantec to reveal anybody's private keys they'd first need to 
have those keys, which is already, IIRC forbidden in the BRs. So even proof 
that Symantec routinely had these keys is a big deal. The whole reason things 
like CSR signing exist is that public CAs have no reason to know anybody's 
private key, the clue is in the name.

Beyond that I'll note that anybody reading Raymond Chen for a few weeks will 
learn that not every researcher who thinks they just found a smoking gun turns 
out to know what a gun actually is, nor sometimes what constitutes smoke. So, 
evidence is what we need. Neither holes in Symantec security nor overclaims 
from a person who misunderstood what they were seeing are unlikely.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[urijah--- via dev-security-policy]

https://www.bleepingcomputer.com/news/security/researcher-says-api-flaw-exposed-symantec-certificates-including-private-keys/

Does anyone have further information about this?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Jakob Bohm via dev-security-policy]

On 28/03/2017 16:13, Ryan Sleevi wrote:

On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


In principle any source of information could change just one minute
later.  A domain could be sold, a company could declare bankruptcy, a
personal domain owner could die.



Yup. And we balance the usability tradeoff.



For smaller organizations (i.e. not Google), requesting and deploying
new certificates every few years is a real hassle,



And that's a bug and needs to change. Plain and simple, that doesn't work
for security. But perhaps we're getting further off-topic, other than I
think the crux of your objection is that "Replacing certificates is hard",
when the reality is we should be striving to replace certificate every 90
days or less, and work to address the systemic and organizational issues
that prevent this.



and often a
non-trivial expense.  Forcing the paid, carefully validated
certificates to be repurchased and reinstalled a lot more often imposes
a real burden on real websites and real e-mail accounts.

The previous CAB/F rule of 3 years max seemed to be a useful
compromise, only slightly more difficult than the old 5 year offering
from some CAs, and well within reason as to handling the frequency of
ordinary changes in domain and company ownership/status that occur in
the real world.



Unfortunately, that's long been held as undesirably long by browser
members, based on the surveys for several years. Unfortunately, CAs have
not been terribly interested in aligning this.



The somewhat sudden (to outsiders) tendency to force frequent
certificate replacements for those not using "Let's encrypt" seems
arbitrary, harmful and mostly pointless.



Right, I think this philosophical difference - one in which I very much
think is actively harmful to security, even though I think it's a totally
understandable and reasonable position for you to hold - is perhaps the
crux of the objection on validating information. And that's useful to
acknowledge up front, and since we've arguably beat this horse to death,
acknowledge that it's merely a position statement being provided, and the
philosophical differences mean it's unlikely for everyone to be happy.



Just because you happen to disagree doesn't make it an invalid point to
make when someone explicitly asks if it would be a good idea to lower
the max to 1 year *before* the "bug" of certificate deployment being
hard has been fixed.

While some parts of the "bug" are about tools and instructions (I have
posted some suggestions to help in that area), there are fundamental
intractable parts:

1. Strong validation *by necessity* must involve interacting with high
  ranking humans in ways that are sufficiently non-trivial to avoid
  being faked by phishing attacks.

2. Securely generating and deploying private keys for new certificates,
  and securely ensuring the right private key is used in a non-ACME
  certificate request (of any form), *necessarily* involves non-trivial
  security procedures on the part of the certificate holder.


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: Next CA Communication

[Ryan Sleevi via dev-security-policy]

On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In principle any source of information could change just one minute
> later.  A domain could be sold, a company could declare bankruptcy, a
> personal domain owner could die.
>

Yup. And we balance the usability tradeoff.


> For smaller organizations (i.e. not Google), requesting and deploying
> new certificates every few years is a real hassle,


And that's a bug and needs to change. Plain and simple, that doesn't work
for security. But perhaps we're getting further off-topic, other than I
think the crux of your objection is that "Replacing certificates is hard",
when the reality is we should be striving to replace certificate every 90
days or less, and work to address the systemic and organizational issues
that prevent this.


> and often a
> non-trivial expense.  Forcing the paid, carefully validated
> certificates to be repurchased and reinstalled a lot more often imposes
> a real burden on real websites and real e-mail accounts.
>
> The previous CAB/F rule of 3 years max seemed to be a useful
> compromise, only slightly more difficult than the old 5 year offering
> from some CAs, and well within reason as to handling the frequency of
> ordinary changes in domain and company ownership/status that occur in
> the real world.
>

Unfortunately, that's long been held as undesirably long by browser
members, based on the surveys for several years. Unfortunately, CAs have
not been terribly interested in aligning this.


> The somewhat sudden (to outsiders) tendency to force frequent
> certificate replacements for those not using "Let's encrypt" seems
> arbitrary, harmful and mostly pointless.


Right, I think this philosophical difference - one in which I very much
think is actively harmful to security, even though I think it's a totally
understandable and reasonable position for you to hold - is perhaps the
crux of the objection on validating information. And that's useful to
acknowledge up front, and since we've arguably beat this horse to death,
acknowledge that it's merely a position statement being provided, and the
philosophical differences mean it's unlikely for everyone to be happy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

[Jakob Bohm via dev-security-policy]

On 27/03/2017 11:10, Gervase Markham wrote:

On 17/03/17 15:30, Gervase Markham wrote:

The URL for the draft of the next CA Communication is here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2

Note that this is a _draft_ - the form parts will not work, and no CA
should attempt to use this URL or the form to send in any responses.


Here is another proposed question:

Certificate Validity Periods

Your attention is drawn to CAB Forum ballot 193, which recently passed.
This reduces the maximum permissible lifetime of certificates from 39 to
27 months, as of 1st March 2018. In addition, it reduces the amount of
time validation information can be reused, from 39 to 27 months, as of
31st March 2017. Please be aware of these deadlines so you can adjust
your practices accordingly.



While this has apparently already passed, the earlier date for
requiring revalidation is going to be a problem for any CA that has
already sold a large number (thousands, millions) of prepaid 3 year
contracts based on the assumption that validation costs would be
incurred by the CA only once during the contract period.

As I have noted elsewhere, at least one major CA (GlobalSign) has a
contract structure and issuance practice which assumes that the
validity of validation information is at least as long as the
certificate validity period.  Thus for any 3-year GlobalSign
certificate issued in the past 2 years, GlobalSign would have already
promised the cert holders that the work and costs of doing certificate
validation had been fully completed at the time when payment was
collected.

This is all because the allowed validity of validation information is 
being retroactively shortened within that validity period.  It would

not have occurred if the shorter validity period of validity
information only applied to validity information gathered after a
deadline that isn't in the extremely near future (If someone orders an
OV cert *today* and pays *todays* price, the validation might not
complete until next week).

At least this needs to be considered when doing the next reduction (if any).



Mozilla is interested in, and the CAB Forum continues to discuss, the
possibility of further reductions in certificate lifetime. We see a
benefit here in reducing the overall turnover time it takes for an
improvement in practices or algorithms to make its way through the
entire WebPKI. Shorter times, carefully managed, also encourage the
ecosystem towards automation, which is beneficial when quick changes
need to be made in response to security incidents. Specifically, Mozilla
is currently considering a reduction to 13 months, effective as of 1st
March 2019 (2 years from now). Alternatively, several CAs have said that
the need for contract renegotiation is a significant issue when reducing
lifetimes, so in order that CAs will only have to do this once rather
than twice, another option would be to require the reduction from 1st
March 2018 (1 year from now), the current reduction date.

Please explain whether you would support such a further reduction dated
to one or both of those dates and, if not, what specifically prevents
you from lending your support to such a move. You may wish to reference
the discussion on the CAB Forum public mailing list to familiarise
yourself with the detailed arguments in favour of certificate lifetime
reduction.



Note that it is very common for all the underlying validity information
to be fixed for 2 or more years (for example domain registrations,
company registrations etc.), providing little reason to impose the
inconvenience and cost of short certificate lifespans onto every
ongoing business and every personal website on the planet.


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: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 28/03/17 13:32, Jakob Bohm via dev-security-policy wrote:


On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:



Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?



Actually, I think it is about ensuring that there are no non-compliant
issuers of Mozilla-trusted certificates, that might be issuing
improperly validated certificates.


We're talking about the policy's requirement for disclosing "dormant" 
sub-CAs, not sub-CAs "that might be issuing".


By the time a sub-CA issues its first cert, that sub-CA MUST have 
already been disclosed.  The policy is already clear on this point.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Grace Period for Sub-CA Disclosure

[Jakob Bohm via dev-security-policy]

On 28/03/2017 12:21, Rob Stradling wrote:

On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:

On 27/03/17 23:12, Andrew Ayer wrote:

My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.  If the sub-CA is created as a backup that is never used, the
disclosure would never need to happen.

I think this is bad.


Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?


Increased attack surface.  An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being compromised by an attacker, or to
being accidentally used to misissue a cert) than an offline root key.

IINM, the purpose (so far) of Mozilla's intermediate cert disclosure
policy is to map the attack surface.  Right?



Actually, I think it is about ensuring that there are no non-compliant
issuers of Mozilla-trusted certificates, that might be issuing
improperly validated certificates.

Any unknown SubCA would be trusted by recursion, but would not have
given Mozilla sufficient assurance it is using this ability in a policy
compliant manner.


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: Grace Period for Sub-CA Disclosure

[Rob Stradling via dev-security-policy]

On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:

On 27/03/17 23:12, Andrew Ayer wrote:

My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.  If the sub-CA is created as a backup that is never used, the
disclosure would never need to happen.

I think this is bad.


Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?


Increased attack surface.  An undisclosed dormant sub-CA most likely has 
its private key in an online HSM, and so I think it's prudent to assume 
that it's more vulnerable (to being compromised by an attacker, or to 
being accidentally used to misissue a cert) than an offline root key.


IINM, the purpose (so far) of Mozilla's intermediate cert disclosure 
policy is to map the attack surface.  Right?


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

[Gervase Markham via dev-security-policy]

On 27/03/17 23:15, mono.r...@gmail.com wrote:
> Are there general proposals yet on how to distinguish phishing vs
> legitimate when it comes to domains? (like apple.com vs app1e.com vs
> mom'n'pop farmer's myapple.com)

Not for those sorts of differences. There are in an IDN context:
http://unicode.org/reports/tr39/

Gerv

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

Re: Grace Period for Sub-CA Disclosure

[Gervase Markham via dev-security-policy]

On 27/03/17 23:12, Andrew Ayer wrote:
> My interpretation of the policy is that a CA could delay disclosure for
> quite some time if the sub-CA is not used to issue certificates right
> away.  If the sub-CA is created as a backup that is never used, the
> disclosure would never need to happen.
> 
> I think this is bad.

Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

On 27/03/17 23:18, okaphone.elektron...@gmail.com wrote:
> Will that remain the responsibility of GlobalSign for any existing
> certificates that have been signed with these roots? (Those would be
> intermediate certificates, if I understand correctly.) Or does
> revocation also require signing, and does it therefore become the
> responsibility of the new owner of the roots?

The latter - Mozilla would hold Google ultimately responsible for any
revocation-related requirements in these hierarchies. (They may, of
course, contract GlobalSign to manage some subset of it, but that's not
our business).

Gerv

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

Re: Next CA Communication

[Gervase Markham via dev-security-policy]

On 27/03/17 16:22, Ryan Sleevi wrote:
> Would it be useful to thus also query whether there would be impact in
> Mozilla applications failing to trust such certificates, but otherwise to
> continue permitting their issuance. 

That is a good idea. How about:


If you are unable to support a comprehensive reduction in issuance
lifetime, please explain the impact you see of Mozilla (and potentially
other browsers) removing trust from certificates of lifetime > 13 months
in the same sort of timeframe. This would mean browser-facing
certificates would need to have shorter lifetimes, but those
certificates not issued for trust by browsers could have longer lifetimes.



> That is a separate, but related, question, but useful to consider if you
> will be asking all CAs, some of whom may have reasons due to other PKIs
> that would make them concerned about potential impact. However, if
> Mozilla's goals and desires would include seeing those PKIs are operated
> independently of the Web PKI, then forbidding issuance would be appropriate.

Presumably you mean independently apart from the fact that they happen
to share roots?

Gerv

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