Re: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 15:24, Todd Johnson wrote:
> Did *anyone* capture this information in a way that can be proven?  
> 
> While I personally would not trust any content from either hostname, the
> Twitter post referenced earlier is not sufficient proof of key compromise.

Unfortunately, the server quickly went down after the vulnerability was
publicly posted (as you might expect when throwing a root shell to
Twitter), and now that it is back up the vulnerable endpoints return
404. I'm not sure if anyone managed to capture further proof of the
extent of the breach. That Twitter thread is pretty damning, though,
even if it may not qualify as proof of key compromise.

I think the more interesting question here will be Trustico's response,
if any. Will they report the potential key compromise to Comodo and
request a revocation and reissuance? Or will they just pretend the
Twitterverse didn't have root on the server almost certainly holding
their private key for a while? Will they be transparent about their
storage of customer private keys, and exactly how it was implemented and
whether this compromise could've further compromised those keys?

And what does Comodo think of all of this?

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 13:32, grandamp--- via dev-security-policy wrote:
> The web site is back up, with the same certificate being used.  That said, it 
> *is* possible that the certificate was managed by their load balancing 
> solution, and the private key for (trustico.com) was not exposed.
> 
> trustico.co.uk appears to be the same web site, yet it has a *different* 
> certificate.

The code injection occurred on an interface they had to check the
certificate of an arbitrary server. When 127.0.0.1 was used, the
trustico.com certificate was returned. That means the local web server
was handling TLS, not a remote load balancer solution (unless somehow
127.0.0.1 was forwarding to a remote host, which doesn't really make any
sense).

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[grandamp--- via dev-security-policy]

The web site is back up, with the same certificate being used.  That said, it 
*is* possible that the certificate was managed by their load balancing 
solution, and the private key for (trustico.com) was not exposed.

trustico.co.uk appears to be the same web site, yet it has a *different* 
certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Ryan Hurst via dev-security-policy]

> >
> > Google requests that certain subCA SPKIs are whitelisted, to ensure
> > continued trust of Symantec-issued certificates that are used by
> > infrastructure that is operated by Google.
> >
> > Is whitelisting the SPKI found in the Google subCA sufficient to achieve
> > the need of trusting Google's server infrastructure?

Kai,

I will do my best to answer this question.

Alphabet has a policy that all of its companies should be getting certificates 
from the Google PKI infrastructure. Right now in the context of certificate 
chains you see that manifested as certificates issued under GIAG2 and GIAG3.

We are actively migrating from GIAG2 (issued under a Symantec owned Root) to 
GIAG3 (issued under a root we own and operate). This transition will be 
complete in August 2018.

Given the size and nature of the Google organization sometimes other CAs are 
used either on accident because the team did not know any better, because the 
organization is part of an acquisition that is not yet integrated or there may 
be some sort of exceptional requirement/situation that necessitates it.

For this, and other reasons, we tell partners that we reserve the right to use 
other roots should the need arise and we publish a list of root certificates we 
may use (https://pki.goog/faq.html see what roots to trust).

As for the use of the With that background nearly all certificates for Alphabet 
(and Google) properties will be issued by a Google operated CA.

In the context of the whitelist, we believe the SPKI approach should be 
sufficient for those applications who also need to whitelist associated CA(s). 

I am also not aware of any Alphabet properties utilizing the DigiCert's Managed 
Partner Infrastructure (beyond one subca they operate that is not in use).

In summary while a SPKI whitelist should work for the current situation 
applications communicating with Alphabet properties should still trust (and 
periodically update to) the more complete list of roots listed in the FAQ.

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

Re: Mozilla’s Plan for Symantec Roots

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 1, 2018 at 4:45 PM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 01.03.2018 18:45, Ryan Sleevi via dev-security-policy wrote:
> >>
> >> The point of my question is to clarify, if the DigiCert transition Roots
> >> are completely separate from the Apple/Google subCA whitelisting
> >> requirements.
> >>
> >
> > I'm not sure how to interpret the Apple/Google question, but yes, they
> are
> > treated as completely separate.
>
> I'm trying to have a clearer understanding about "who needs what".
>
> Let me reword it.
>
> Google requests that certain subCA SPKIs are whitelisted, to ensure
> continued trust of Symantec-issued certificates that are used by
> infrastructure that is operated by Google.
>
> Is whitelisting the SPKI found in the Google subCA sufficient to achieve
> the need of trusting Google's server infrastructure?
>
> I assume the answer is yes. If I'm right, and the answer is "yes", then
> it means that whitelisting the SPKIs from the DigiCert transition Roots
> isn't required for Google's servers. It's required for continued trust
> of other, non-Google server systems.
>
> Or rephrasing again: There are no Google servers that use certificates
> from DigiCert's Managed Partner Infrastructure.
>
> I further assume that it's possible to replace the word Google with the
> word Apple in all previous paragraphs, and the statements are still
> correct.


Gotcha.

I can't personally speak to that, then - that's up to Apple and Google's
PKI teams - but:
1) I'm not aware of it
2) But it's also not prohibited. The solution was designed to accommodate
that case if they should need.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

On 01.03.2018 18:45, Ryan Sleevi via dev-security-policy wrote:
>>
>> The point of my question is to clarify, if the DigiCert transition Roots
>> are completely separate from the Apple/Google subCA whitelisting
>> requirements.
>>
> 
> I'm not sure how to interpret the Apple/Google question, but yes, they are
> treated as completely separate.

I'm trying to have a clearer understanding about "who needs what".

Let me reword it.

Google requests that certain subCA SPKIs are whitelisted, to ensure
continued trust of Symantec-issued certificates that are used by
infrastructure that is operated by Google.

Is whitelisting the SPKI found in the Google subCA sufficient to achieve
the need of trusting Google's server infrastructure?

I assume the answer is yes. If I'm right, and the answer is "yes", then
it means that whitelisting the SPKIs from the DigiCert transition Roots
isn't required for Google's servers. It's required for continued trust
of other, non-Google server systems.

Or rephrasing again: There are no Google servers that use certificates
from DigiCert's Managed Partner Infrastructure.

I further assume that it's possible to replace the word Google with the
word Apple in all previous paragraphs, and the statements are still correct.

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

Re: Trustico code injection

[Tim Shirley via dev-security-policy]

That's jumping the gun a bit.  First of all they'd have to be made aware of the 
suspected compromise before the 24 hour clock would start.  And then they'd 
need to be convinced that it actually was compromised.  Since the server has 
apparently been taken down, they wouldn't be able to verify these claims 
themselves and I would certainly hope a CA wouldn't take such an action based 
only on unverified claims on Twitter.

On 3/1/18, 1:13 PM, "dev-security-policy on behalf of Hector Martin 'marcan' 
via dev-security-policy" 
 wrote:

At this point I would expect Comodo should revoke this certificate due
to key compromise within the next 24 hours.


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

Re: Trustico code injection

[RS Tyler Schroder via dev-security-policy]

On Thursday, March 1, 2018 at 2:43:05 PM UTC-5, Tom wrote:
> > Therefore, it is not unreasonable to assume that this key has been
>  > compromised.
> 
> 
> So it means that any private keys generated on that website could be 
> compromised:
> - If any third-party JS were compromised (and we know how insecure 
> js-based ads are - last time it was a crypto miner on youtube)
> - If they were stored on the compromised server
> - If a trojan were installed on the compromised server
> - If somebody MitM the server
> 
> Or am I missing something ?

That seems rather comprehensive. Any number of vectors could have caused a key 
leak.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Tom via dev-security-policy]

> Therefore, it is not unreasonable to assume that this key has been
> compromised.


So it means that any private keys generated on that website could be 
compromised:
- If any third-party JS were compromised (and we know how insecure 
js-based ads are - last time it was a crypto miner on youtube)

- If they were stored on the compromised server
- If a trojan were installed on the compromised server
- If somebody MitM the server

Or am I missing something ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[RS Tyler Schroder via dev-security-policy]

On Thursday, March 1, 2018 at 12:59:17 PM UTC-5, Matthew Hardeman wrote:
> By this point, one would imagine that reputational risks would prevent any
> CA from working with Trustico.
> 
> On Thu, Mar 1, 2018 at 11:56 AM, Hector Martin 'marcan' via
> dev-security-policy  wrote:
> 
> > On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> > > Hi,
> > >
> > > On twitter there are currently some people poking Trustico's web
> > > interface and found trivial script injections:
> > > https://twitter.com/svblxyz/status/969220402768736258
> > >
> > > Which seem to run as root:
> > > https://twitter.com/cujanovic/status/969229397508153350
> > >
> > > I haven't tried to reproduce it, but it sounds legit.
> >
> > Unsurprisingly, the entire server is now down. If Trustico are lucky,
> > someone just `rm -rf /`ed the whole thing. If they aren't, they now have
> > a bunch of persistent backdoors in their network.
> >
> > Now the interesting question is whether this vector could've been used
> > to recover any/all archived private keys.
> >
> > As I understand it, Trustico is in the process of terminating their
> > relationship with Digicert and switching to Comodo for issuance. I have
> > a question for Digicert, Comodo, and other CAs: do you do any vetting of
> > resellers for best practices? While clearly most of the security burden
> > rests with the CA, this example shows that resellers with poor security
> > practices (archiving subscriber public keys, e-mailing them to trigger
> > revocation, trivial command injection vulnerabilities, running a PHP
> > frontend directly as root) can have a significant impact on the security
> > of the WebPKI for a large number of certificate holders. Are there any
> > concerns that the reputability of a CA might be impacted if they
> > willingly choose to partner with resellers which have demonstrated such
> > problems?
> >
> > --
> > Hector Martin "marcan" (x...@x.st)
> > Public Key: https://mrcn.st/pub
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

I posted about this issue in the other thread on Trustico's debacle after 
seeing the twitter explosion over here: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/wxX4Yv0E3Mk/q6P8oE3pAQAJ

Agreeing with Hector, I think that would be reasonable grounds to assume 
compromise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

[Ryan Hurst via dev-security-policy]

On Thursday, March 1, 2018 at 7:15:52 AM UTC-8, Kai Engert wrote:

> Are the owners of the Apple and Google subCAs able to announce a date,
> after which they will no longer require their Symantec-issued subCAs to
> be whitelisted?

Kai,

We are actively migrating to the Google Trust Services operated root 
certificates and while we would love to provide a concrete date the nature of 
these sorts of deployments makes that hard to provide.

What I can say is that our plan is to be migrated off by the time the Equifax 
root expires August 22nd 2018.

Ryan Hurst
Google

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

Re: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 02:56, Hector Martin 'marcan' via dev-security-policy wrote:
> On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
>> Hi,
>>
>> On twitter there are currently some people poking Trustico's web
>> interface and found trivial script injections:
>> https://twitter.com/svblxyz/status/969220402768736258
>>
>> Which seem to run as root:
>> https://twitter.com/cujanovic/status/969229397508153350
>>
>> I haven't tried to reproduce it, but it sounds legit.
> 
> Unsurprisingly, the entire server is now down. If Trustico are lucky,
> someone just `rm -rf /`ed the whole thing. If they aren't, they now have
> a bunch of persistent backdoors in their network.
> 
> Now the interesting question is whether this vector could've been used
> to recover any/all archived private keys.
> 
> As I understand it, Trustico is in the process of terminating their
> relationship with Digicert and switching to Comodo for issuance. I have
> a question for Digicert, Comodo, and other CAs: do you do any vetting of
> resellers for best practices? While clearly most of the security burden
> rests with the CA, this example shows that resellers with poor security
> practices (archiving subscriber public keys, e-mailing them to trigger
> revocation, trivial command injection vulnerabilities, running a PHP
> frontend directly as root) can have a significant impact on the security
> of the WebPKI for a large number of certificate holders. Are there any
> concerns that the reputability of a CA might be impacted if they
> willingly choose to partner with resellers which have demonstrated such
> problems?

According to this report, 127.0.0.1 returned the SSL certificate of the
Trustico server itself. This is evidence that no reverse proxy was in
use, and thus, the private key of trustico.com was directly exposed to
the code execution vector and could've been trivially exfiltrated:
https://twitter.com/ebuildy/status/969230182295982080

Therefore, it is not unreasonable to assume that this key has been
compromised.

The certificate in use is this one:
https://crt.sh/?id=206535041

At this point I would expect Comodo should revoke this certificate due
to key compromise within the next 24 hours.

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Matthew Hardeman via dev-security-policy]

By this point, one would imagine that reputational risks would prevent any
CA from working with Trustico.

On Thu, Mar 1, 2018 at 11:56 AM, Hector Martin 'marcan' via
dev-security-policy  wrote:

> On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On twitter there are currently some people poking Trustico's web
> > interface and found trivial script injections:
> > https://twitter.com/svblxyz/status/969220402768736258
> >
> > Which seem to run as root:
> > https://twitter.com/cujanovic/status/969229397508153350
> >
> > I haven't tried to reproduce it, but it sounds legit.
>
> Unsurprisingly, the entire server is now down. If Trustico are lucky,
> someone just `rm -rf /`ed the whole thing. If they aren't, they now have
> a bunch of persistent backdoors in their network.
>
> Now the interesting question is whether this vector could've been used
> to recover any/all archived private keys.
>
> As I understand it, Trustico is in the process of terminating their
> relationship with Digicert and switching to Comodo for issuance. I have
> a question for Digicert, Comodo, and other CAs: do you do any vetting of
> resellers for best practices? While clearly most of the security burden
> rests with the CA, this example shows that resellers with poor security
> practices (archiving subscriber public keys, e-mailing them to trigger
> revocation, trivial command injection vulnerabilities, running a PHP
> frontend directly as root) can have a significant impact on the security
> of the WebPKI for a large number of certificate holders. Are there any
> concerns that the reputability of a CA might be impacted if they
> willingly choose to partner with resellers which have demonstrated such
> problems?
>
> --
> Hector Martin "marcan" (mar...@marcan.st)
> Public Key: https://mrcn.st/pub
> ___
> 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: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> Hi,
> 
> On twitter there are currently some people poking Trustico's web
> interface and found trivial script injections:
> https://twitter.com/svblxyz/status/969220402768736258
> 
> Which seem to run as root:
> https://twitter.com/cujanovic/status/969229397508153350
> 
> I haven't tried to reproduce it, but it sounds legit.

Unsurprisingly, the entire server is now down. If Trustico are lucky,
someone just `rm -rf /`ed the whole thing. If they aren't, they now have
a bunch of persistent backdoors in their network.

Now the interesting question is whether this vector could've been used
to recover any/all archived private keys.

As I understand it, Trustico is in the process of terminating their
relationship with Digicert and switching to Comodo for issuance. I have
a question for Digicert, Comodo, and other CAs: do you do any vetting of
resellers for best practices? While clearly most of the security burden
rests with the CA, this example shows that resellers with poor security
practices (archiving subscriber public keys, e-mailing them to trigger
revocation, trivial command injection vulnerabilities, running a PHP
frontend directly as root) can have a significant impact on the security
of the WebPKI for a large number of certificate holders. Are there any
concerns that the reputability of a CA might be impacted if they
willingly choose to partner with resellers which have demonstrated such
problems?

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

[Ryan Sleevi via dev-security-policy]

This is precisely what was discussed as part of the Managed Partner
Infrastructure transition, which was anticipated to potentially take
several years due to a wide variety of complexities.

This model was designed to allow for the replacement of the existing
Symantec Roots with the Transition Certificates (which would have
stabilized then, but not necessarily right now, as folks only now begin to
transition), and a separable discussion regarding whether or not the
Apple/Google intermediates will have fully expired (as is possible) or
whether they would need to be 'administratively managed' - effectively,
treated as roots (in which Mozilla or other root programs oversaw the audit
reports), rather than delegating the audit report oversight to Symantec.

I can't speak for Google or Apple's transition plans, but the design of the
plan, as discussed on the list, was precisely to allow for a minimally
disruptive transition, in a solution that would technically work with a
wide variety of root programs, including all browsers root programs'
technical constraints. This wasn't accidental, it was intentional.

On Thu, Mar 1, 2018 at 10:17 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is it practical to remove the Symantec root certificates and (temporarily)
> add the Google and Apple intermediates to the trust store? This should
> facilitate removing trust in Symantec without disruption.
>
> Alex
>
> On Thu, Mar 1, 2018 at 10:15 AM, Kai Engert via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > In my opinion, Mozilla's and Google's plans to distrust the Thawte,
> > RapidSSL, GeoTrust, Verisign, and Symantec branded CAs in the browser,
> > should be interpreted as a recommendation to eventually distrust them
> > for all server authentication uses.
> >
> > If a CA gets distrusted for https, then I think it's fair to equally
> > consider it as no longer acceptable for other services like IMAPS or
> LDAPS.
> >
> > As Ryan said in another thread, migration of non-https services might
> > take a longer time to migrate. However, based on Jeremy's statement in
> >   https://bugzilla.mozilla.org/show_bug.cgi?id=1437826#c3
> > I'd assume that the customer certificate migration efforts driven by
> > DigiCert should also cover migration of non-https services within a
> > reasonable amount of time, where general purpose client software is used
> > to connect to non-https services.
> >
> > (I'm excluding special purpose hardware with embedded restrictions, and
> > also excluding manually configured server to server configurations.)
> >
> > I conclude that for general purpose client software, that doesn't
> > implement key pinning and doesn't have restrictions on chain length, but
> > which wants to retain the ability to connect to services offered by
> > Apple or Google, the whitelisting for Apple/Google subCAs is the only
> > hindrance for eventual full distrust of the Symantec Root CAs.
> >
> > Are the owners of the Apple and Google subCAs able to announce a date,
> > after which they will no longer require their Symantec-issued subCAs to
> > be whitelisted?
> >
> > Thanks
> > Kai
> > ___
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 1, 2018 at 10:31 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 1 Mar 2018 10:51:04 +
> Ben Laurie via dev-security-policy
>  wrote:
>
> > Seems to me that signing something that has nothing to do with certs
> > is a safer option - e.g. sign random string+Subject DN.
>
> That does sounds sane, I confess I have not spent much time playing with
> easily available tools to check what is or is not easily possible on
> each platform in terms of producing and checking such proofs. I knew
> that you can make a CSR on popular platforms, and I knew how to check a
> CSR is valid and a bogus CSR seemed obviously harmless to me.
>
> I feel sure I saw someone's carefully thought through procedure for
> proving control over a private key written up properly for close to
> this sort of situation but I have tried and failed to find it again
> since the incident was first reported, and apparently Jeremy didn't
> know it either.


Perhaps you were thinking about the ROBOT attack, which covered
https://robotattack.org/

You can produce such messages, if you have the key, through something like
(note: haven't tested, but you get the idea)

associated_spki_hash=`openssl pkey -inform PEM -in foo.key -pubout |
openssl dgst -sha256 -binary | openssl enc -base64`
associated_crt_sh_url="http://crt.sh/?spkisha256=${associated_spki_hash};
echo "${associated_crt_sh_url} is compromised - 2018-03-01" > message.txt
openssl dgst -sha256 -sign foo.key -out foo.key -out
${associated_spki_hash}.signature message.txt

to verify
openssl dgst -sha256 -verify <(openssl x509 -in "cert file goes here"
-pubkey -noout) -signature ${associated_spki_hash}.signature message.txt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

[Ryan Duff via dev-security-policy]

On Thursday, March 1, 2018 at 11:08:58 AM UTC-5, RSTS wrote:
> On Thursday, March 1, 2018 at 1:51:16 PM UTC, Michel Gre wrote:
> > > I'd postulate there's
> > > nothing wrong with Trustico holding the private keys if they were hosting
> > > the site or providing CDN services for all of these sites. 
> > 
> > I manage one of the affected domains. I can tell that in no way does 
> > Trustico hosts the site, nor provide us any CDN service.
> > 
> > We just purchased them a certificate 4 years ago and renewed it for 3 years 
> > in april 2015. Since we are usually quite busy we simply used their form to 
> > generate the key, the CSR, and get the certificate... So, Trustico should 
> > be actually Dontrustico. The worst is that the CEO himself publicly said 
> > (here!) that they HELD OUR PRIVATE KEYS!!! Come on. M. Zane Lucas, your 
> > staff sent me (after I asked them from an explanation regarding the 
> > Digicert's first email) a coupon for a "Trustico(r) Single Site" 
> > certificate, would you expect me to trust it after what YOU disclosed here? 
> > Looks like you just cut the branch your company was sitting on.
> 
> In relevant news, Trustico's site is down due to an apparent flaw, apparently 
> allowing users to run commands as root on their production webserver. 
> 
> My question is, assuming this was discovered previously by an attacker, is 
> there possibility of exploiting that to fetch these cold-storage keys?
> 
> https://twitter.com/Manawyrm/status/969230542578348033 in reply to 
> https://twitter.com/svblxyz/status/969220402768736258

Given that they were able to readily produce all of these keys, I would suspect 
they were never really in cold storage. At least not exclusively.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Kai Engert via dev-security-policy]

Hello Ryan,

thanks again for this response. The situation appears very complex. I
might follow up with a couple of clarification questions, that are
hopefully simple to answer. Let me start with this one:

Chromium will whitelist the SPKIs of a "CN=DigiCert Transition ECC Root"
and a "CN=DigiCert Transition RSA Root" certificate, as found in this
directory:
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/managed

Are there any Apple systems, servers, infrastructure, devices, that rely
on any of these DigiCert transition Root CAs?

Are there any Google systems, servers, infrastructure, devices, that
rely on any of these DigiCert transition Root CAs?

The point of my question is to clarify, if the DigiCert transition Roots
are completely separate from the Apple/Google subCA whitelisting
requirements.

Thanks
Kai

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

Re: How do you handle mass revocation requests?

[RSTS via dev-security-policy]

On Thursday, March 1, 2018 at 1:51:16 PM UTC, Michel Gre wrote:
> > I'd postulate there's
> > nothing wrong with Trustico holding the private keys if they were hosting
> > the site or providing CDN services for all of these sites. 
> 
> I manage one of the affected domains. I can tell that in no way does Trustico 
> hosts the site, nor provide us any CDN service.
> 
> We just purchased them a certificate 4 years ago and renewed it for 3 years 
> in april 2015. Since we are usually quite busy we simply used their form to 
> generate the key, the CSR, and get the certificate... So, Trustico should be 
> actually Dontrustico. The worst is that the CEO himself publicly said (here!) 
> that they HELD OUR PRIVATE KEYS!!! Come on. M. Zane Lucas, your staff sent me 
> (after I asked them from an explanation regarding the Digicert's first email) 
> a coupon for a "Trustico(r) Single Site" certificate, would you expect me to 
> trust it after what YOU disclosed here? Looks like you just cut the branch 
> your company was sitting on.

In relevant news, Trustico's site is down due to an apparent flaw, apparently 
allowing users to run commands as root on their production webserver. 

My question is, assuming this was discovered previously by an attacker, is 
there possibility of exploiting that to fetch these cold-storage keys?

https://twitter.com/Manawyrm/status/969230542578348033 in reply to 
https://twitter.com/svblxyz/status/969220402768736258
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

[Wayne Thayer via dev-security-policy]

On Thu, Mar 1, 2018 at 8:17 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is it practical to remove the Symantec root certificates and (temporarily)
> add the Google and Apple intermediates to the trust store? This should
> facilitate removing trust in Symantec without disruption.
>
> Before we can completely remove the Symantec roots, we need to address
email protection (S/MIME) certs. An interim step would be to turn off the
websites trust bit.

The decision to whitelist specific keys rather than add the intermediates
to the trust store was intentional - it allows DigiCert to sign additional
whitelisted intermediates during the transition period.


> Alex
>
> On Thu, Mar 1, 2018 at 10:15 AM, Kai Engert via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>
> > Are the owners of the Apple and Google subCAs able to announce a date,
> > after which they will no longer require their Symantec-issued subCAs to
> > be whitelisted?
> >
>
I would also like an answer to this question. Since DigiCert also holds
whitelisted keys, I think we need to hear from them as well.

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

Re: Trustico code injection

[Alex Gaynor via dev-security-policy]

For the Trustico folks:

While I imagine you're quite busy remediating this serious issue: Can you
state whether it would be possible to access any of the private keys you
store using this root shell?

Alex


On Thu, Mar 1, 2018 at 10:28 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> On twitter there are currently some people poking Trustico's web
> interface and found trivial script injections:
> https://twitter.com/svblxyz/status/969220402768736258
>
> Which seem to run as root:
> https://twitter.com/cujanovic/status/969229397508153350
>
> I haven't tried to reproduce it, but it sounds legit.
>
> --
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

[Nick Lamb via dev-security-policy]

On Thu, 1 Mar 2018 10:51:04 +
Ben Laurie via dev-security-policy
 wrote:

> Seems to me that signing something that has nothing to do with certs
> is a safer option - e.g. sign random string+Subject DN.

That does sounds sane, I confess I have not spent much time playing with
easily available tools to check what is or is not easily possible on
each platform in terms of producing and checking such proofs. I knew
that you can make a CSR on popular platforms, and I knew how to check a
CSR is valid and a bogus CSR seemed obviously harmless to me.

I feel sure I saw someone's carefully thought through procedure for
proving control over a private key written up properly for close to
this sort of situation but I have tried and failed to find it again
since the incident was first reported, and apparently Jeremy didn't
know it either.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Trustico code injection

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

Hi,

On twitter there are currently some people poking Trustico's web
interface and found trivial script injections:
https://twitter.com/svblxyz/status/969220402768736258

Which seem to run as root:
https://twitter.com/cujanovic/status/969229397508153350

I haven't tried to reproduce it, but it sounds legit.

-- 
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: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

[Alex Gaynor via dev-security-policy]

Is it practical to remove the Symantec root certificates and (temporarily)
add the Google and Apple intermediates to the trust store? This should
facilitate removing trust in Symantec without disruption.

Alex

On Thu, Mar 1, 2018 at 10:15 AM, Kai Engert via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In my opinion, Mozilla's and Google's plans to distrust the Thawte,
> RapidSSL, GeoTrust, Verisign, and Symantec branded CAs in the browser,
> should be interpreted as a recommendation to eventually distrust them
> for all server authentication uses.
>
> If a CA gets distrusted for https, then I think it's fair to equally
> consider it as no longer acceptable for other services like IMAPS or LDAPS.
>
> As Ryan said in another thread, migration of non-https services might
> take a longer time to migrate. However, based on Jeremy's statement in
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1437826#c3
> I'd assume that the customer certificate migration efforts driven by
> DigiCert should also cover migration of non-https services within a
> reasonable amount of time, where general purpose client software is used
> to connect to non-https services.
>
> (I'm excluding special purpose hardware with embedded restrictions, and
> also excluding manually configured server to server configurations.)
>
> I conclude that for general purpose client software, that doesn't
> implement key pinning and doesn't have restrictions on chain length, but
> which wants to retain the ability to connect to services offered by
> Apple or Google, the whitelisting for Apple/Google subCAs is the only
> hindrance for eventual full distrust of the Symantec Root CAs.
>
> Are the owners of the Apple and Google subCAs able to announce a date,
> after which they will no longer require their Symantec-issued subCAs to
> be whitelisted?
>
> Thanks
> Kai
> ___
> 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

Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

[Kai Engert via dev-security-policy]

In my opinion, Mozilla's and Google's plans to distrust the Thawte,
RapidSSL, GeoTrust, Verisign, and Symantec branded CAs in the browser,
should be interpreted as a recommendation to eventually distrust them
for all server authentication uses.

If a CA gets distrusted for https, then I think it's fair to equally
consider it as no longer acceptable for other services like IMAPS or LDAPS.

As Ryan said in another thread, migration of non-https services might
take a longer time to migrate. However, based on Jeremy's statement in
  https://bugzilla.mozilla.org/show_bug.cgi?id=1437826#c3
I'd assume that the customer certificate migration efforts driven by
DigiCert should also cover migration of non-https services within a
reasonable amount of time, where general purpose client software is used
to connect to non-https services.

(I'm excluding special purpose hardware with embedded restrictions, and
also excluding manually configured server to server configurations.)

I conclude that for general purpose client software, that doesn't
implement key pinning and doesn't have restrictions on chain length, but
which wants to retain the ability to connect to services offered by
Apple or Google, the whitelisting for Apple/Google subCAs is the only
hindrance for eventual full distrust of the Symantec Root CAs.

Are the owners of the Apple and Google subCAs able to announce a date,
after which they will no longer require their Symantec-issued subCAs to
be whitelisted?

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

Re: How do you handle mass revocation requests?

[nic.swart--- via dev-security-policy]

I agree with Eric, I would call storing the customers private keys (without 
their knowledge!!) as an immediate compromise and a clear breach of trust.

On Thursday, March 1, 2018 at 1:04:54 AM UTC+1, Eric Mill wrote:
> Trustico doesn't seem to provide any hosting or CDN services that would
> make use of the private key, nor do they appear to explicitly inform users
> about the storage of this private key.
> 
> In their statement, they say they keep the private keys explicitly to
> perform revocation as necessary:
> https://www.trustico.com/news/2018/symantec-revocation/certificate-replacement.php
> (archived: https://archive.is/0AnyR )
> 
> > These Private Keys are stored in cold storage, for the purpose of
> revocation.
> 
> Their CSR/key generation form is here:
> https://www.trustico.com/ssltools/create/csr-pem/create-a-new-csr-instantly.php
> (archived: https://archive.is/hJV42 )
> 
> The storage of private keys appears to be done without the user's knowledge
> or consent. And of course, only the keys they create through their form are
> stored, so it is clearly not a necessary business function for most of
> their certificate business.
> 
> Finally -- the CSR/key generation form page incorporates JavaScript from at
> least 5 or 6 different companies (including ad servers), which would allow
> any of those third parties (intentionally or through compromise of their
> own) to capture generated keys. This is a reckless amount of exposure, to
> the point that even if the keys were generated completely inside the
> browser and never exposed to the server (which does not appear to be the
> case), I would consider them compromised at the time of generation.
> 
> Given everything that's known, then regardless of who emailed whose
> customers when and why, I think it's clear that Trustico compromised those
> keys at _least_ at the time they were stored, if not at the time of
> generation, and has been routinely compromising customer keys for years.
> Emailing them to DigiCert only widened their exposure to more unauthorized
> parties.
> 
> And given that there's no evidence that Trustico has acknowledged this
> fact, or indicated any intent to change their business practices, then I
> believe it's appropriate for all CAs to immediately suspend or terminate
> their relationship with Trustico -- as any CA who continued doing business
> with Trustico would now be knowingly allowing Trustico to compromise the
> keys of the certificates issued under their hierarchy.
> 
> -- Eric
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: How do you handle mass revocation requests?

[Michel Gre via dev-security-policy]

> I'd postulate there's
> nothing wrong with Trustico holding the private keys if they were hosting
> the site or providing CDN services for all of these sites. 

I manage one of the affected domains. I can tell that in no way does Trustico 
hosts the site, nor provide us any CDN service.

We just purchased them a certificate 4 years ago and renewed it for 3 years in 
april 2015. Since we are usually quite busy we simply used their form to 
generate the key, the CSR, and get the certificate... So, Trustico should be 
actually Dontrustico. The worst is that the CEO himself publicly said (here!) 
that they HELD OUR PRIVATE KEYS!!! Come on. M. Zane Lucas, your staff sent me 
(after I asked them from an explanation regarding the Digicert's first email) a 
coupon for a "Trustico(r) Single Site" certificate, would you expect me to 
trust it after what YOU disclosed here? Looks like you just cut the branch your 
company was sitting on.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

[Rob Stradling via dev-security-policy]

On 01/03/18 10:51, Ben Laurie via dev-security-policy wrote:

On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Wed, 28 Feb 2018 20:03:51 +
Jeremy Rowley via dev-security-policy
 wrote:


The keys were emailed to me. I'm trying to get a project together
where we self-sign a cert with each of the keys and publish them.
That way there's evidence to the community of the compromise without
simply listing 23k private keys. Someone on Reddit suggested that,
which I really appreciated.


That's probably me (tialaramex).

Anyway, if it is me you're referring to, I suggested using the private
keys to issue a bogus CSR. CSRs are signed, proving that whoever made
them had the corresponding private key but they avoid the confusion
that comes from DigiCert (or its employees) issuing bogus certs.
Everybody reading m.d.s.policy can still see that a self-signed cert is
harmless and not an attack, but it may be harder to explain in a
soundbite. Maybe more technically able contributors disagree ?



Seems to me that signing something that has nothing to do with certs is a
safer option - e.g. sign random string+Subject DN.


And also throw in some transparency...

https://mailarchive.ietf.org/arch/msg/trans/WLFmIyaH4BJo77ZJDinKJcylOcg

--
Rob Stradling
Senior Research & Development Scientist
Email: rob.stradl...@comodoca.com
Bradford, UK
Office: +441274730505
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

[Ben Laurie via dev-security-policy]

On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, 28 Feb 2018 20:03:51 +
> Jeremy Rowley via dev-security-policy
>  wrote:
>
> > The keys were emailed to me. I'm trying to get a project together
> > where we self-sign a cert with each of the keys and publish them.
> > That way there's evidence to the community of the compromise without
> > simply listing 23k private keys. Someone on Reddit suggested that,
> > which I really appreciated.
>
> That's probably me (tialaramex).
>
> Anyway, if it is me you're referring to, I suggested using the private
> keys to issue a bogus CSR. CSRs are signed, proving that whoever made
> them had the corresponding private key but they avoid the confusion
> that comes from DigiCert (or its employees) issuing bogus certs.
> Everybody reading m.d.s.policy can still see that a self-signed cert is
> harmless and not an attack, but it may be harder to explain in a
> soundbite. Maybe more technically able contributors disagree ?
>

Seems to me that signing something that has nothing to do with certs is a
safer option - e.g. sign random string+Subject DN.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How do you handle mass revocation requests?

[Ben Laurie via dev-security-policy]

On 28 February 2018 at 19:40, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The end user agreed to the subscriber agreement, not Trustico. Our
> analysis follows what Peter B. posted – the subscriber is the “natural
> person or Legal Entity to whom a Certificate is issued and who is legally
> bound by a Subscriber Agreement or Terms of Use"—which in this case was
> Trustico’s customers.  In addition, we felt that given (1) the number of
> certificates Trustico was asking us to mass-revoke and (2) the lack of any
> substantiation of why Trustico thought the certs were “compromised,” we
> needed more information before revoking. At the minimum, it warranted
> alerting the contact for each certificate that revocation was imminent.
>
>
>
> I also agree that there’s no problem with the way or that the keys were
> provided to DigiCert for cert revocation.


Agree with who? Both asking for the keys and providing them seems weird to
me.

The more secure thing to do would be to ask for proof of possession of the
keys, e.g. by signing a random string with them...


> I certainly don’t want to discourage revocation of compromised certs!  My
> main question is how do you handle these things? The process at scale
> should not be different if a reseller requests revocation compared to any
> other security researcher. The question is how you handle the this volume
> of revocations when its happen? I’ve never received a revocation request of
> this magnitude before so I’m seeking the wisdom of the community in what we
> do.
>
>
>
> I’m happy to share any of the details I can.
>
>
>
> Jeremy
>
>
>
>
>
> From: Ryan Sleevi 
> Sent: Wednesday, February 28, 2018 11:58 AM
> To: Jeremy Rowley 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: How do you handle mass revocation requests?
>
>
>
>
>
>
>
> On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org  lists.mozilla.org> > wrote:
>
> On February 2nd, 2018, we received a request from Trustico to mass revoke
> all certificates that had been ordered by end users through Trustico.
> Unfortunately, the email was not sent to the appropriate certificate
> problem
> reporting channels and did not surface immediately so we're delayed in
> sharing the concerns and information. Once we were alerted, the team kicked
> off a debate that I wanted to bring to the CAB Forum. Basically, our
> position is that resellers do not constitute subscribers under the Baseline
> Requirement's definitions (Section 1.6.1). As such, we needed to confirm
> that either the key was compromised or that they revocation was authorized
> by the domain holder (the subscriber) prior to revoking the certificate.
> The
> certificates were not alleged as compromised at that time.
>
>
>
> I think there's a little nuance to this in the general case (e.g. consider
> "Resllers" who are also the hosting provider, and thus constitute the
> Applicant/Subscriber even when they're not the domain holder, but
> authorized by them), but based on this specific case, I think this sounds
> like a correct determination.
>
>
>
> I think the biggest question is who agreed to the terms - Trustico or the
> end-user - and that mostly impacts the rest of the decision here. Further,
> did Trustico warrant on behalf of the user that the user agreed to the
> terms (in which case, I would think it's a bit of a copout, and it's really
> Trustico agreeing, thus the Subscriber), or did DigiCert have direct
> communication with the user on the basis of Trustico's introduction (in
> which case, yeah, the Subscriber is the user)
>
>
>
> Anyway, just highlighting it here as perhaps not a uniform consensus, but
> perhaps not as material as what follows.
>
>
>
> On 2/27/2018, at my request for proof of compromise, we received a file
> with
> 23k private keys matched to specific Trustico customers. This definitely
> triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
> Once we received the keys, we confirmed that these were indeed the matching
> private keys for the reported certificates. We will be revoking these
> certificates today (February 28th, 2018).
>
>
>
> I think all of this sounds reasonable, no different than a security
> researcher (or random member of the public) who were to claim compromise
> with no evidence of that.
>
>
>
> Currently, we are only revoking the certificates if we received the private
> keys. There are additional certificates the reseller requested to have
> revoked, but DigiCert has decided to disregard that request until we
> receive
> proof of compromise or more information about the cause of this incident.
>
>
>
> For the same reason that "Jane Random User" should not be able to cause
> revocation merely by assertion, I think that sounds reasonable.
>
>
>
> This raises a question about the MDSP policy and 

Re: WebExtensions Overriding TLS Certificate Validation

[Franziskus Kiefer via dev-security-policy]

Sorry for the delay, I wasn't subscribed to the mailing list and didn't get
your reply.

Another discussion started on the security-policy mailing list [1] (thanks
Wayne for starting that). Please check that one out as well.
I cross-post this reply to the security-policy mailing list as I think this
conversion should involve both.

Franziskus Kiefer:
> > I agree with Tom that an API for WebExtensions that allows to make
> > connection trust decisions would be great (allowing all those
> experiments).
> > But I think we shouldn't allow the API to override Firefox's trust
> > decision, i.e. the green/whatevercolored lock.
>
> Please forgive my general lack of familiarity with the terminology here,
> but if I understand the above correctly, "connection trust decisions" ==
> influencing (in either direction) whether the TLS handshake succeeds
> without erroring out, and "Firefox's trust decision" == influencing the
> iconography displayed when the page loads?
>

Yeah, I think there are two levels here.
i) Does Firefox establish a connection at all and display the page content
ii) What "security level"/"trustworthiness" does Firefox give the page.

The question here is whether WebExtensions should be allowed to alter any
of them and in particular how that decision is communicated to the user.
Should a trust-decision made by an extension be communicated the same way
the decision from Firefox is communicated (with the green lock icon)? I
think it shouldn't.

To clarify my position: I think WebExtensions should be allowed to get most
information of the TLS connection to implement its own trust decision
algorithms. (I say most as I obviously wouldn't expose any secrets.) This
wouldn't allow the extension to make a connection with a self-signed
certificate valid. But it could for example add an icon next to the Firefox
lock icon adding additional information to the "security level" of the
connection such as web of trust information etc.

Cheers,
Franziskus

[1] https://groups.google.com/forum/#!topic/mozilla.dev.security
.policy/yyzRatMijpE


On Wed, Feb 7, 2018 at 11:45 AM, Franziskus Kiefer 
wrote:

> I agree with Tom that an API for WebExtensions that allows to make
> connection trust decisions would be great (allowing all those experiments).
> But I think we shouldn't allow the API to override Firefox's trust
> decision, i.e. the green/whatevercolored lock.
>
> The lock icon is the only way we communicate security of a page to users.
> Giving this away to any extension is too dangerous imho. And, as Andrew
> said, giving extensions that use potentially dangerous APIs like this extra
> review doesn't scale well.
>
> Adding this API would also force us to keep the lock there (or break
> extensions), which is something that we probably don't want. HTTPS is
> supposed to become the default and the lock will probably go away
> long-term. This could potentially leave us in a position similar to the one
> we had with legacy extensions where we had to keep code around and couldn't
> move forward just to avoid breaking extensions.
>
> Adding additional UI could be a solution. Instead of allowing to change
> the lock icon we could allow adding an icon. Extensions could then enhance
> the trust decision Firefox took but not override it.
>
> Cheers,
> Franziskus
>
> On Wed, Feb 7, 2018 at 12:19 AM, Andrew Swan  wrote:
>
>>
>> On Tue, Feb 6, 2018 at 7:34 AM, Tom Ritter  wrote:
>>
>>> So I'm curious what the Web Extension experts think of this, and what
>>> the best way to gate and mitigate harm from this would be. I'm not
>>> sure what the status quo is with Web Extension permissions and manual
>>> review, and what options we have there.
>>>
>>
>> I don't have a strong opinion about this particular API (there are strong
>> arguments both for and against, which is the most difficult possible
>> scenario :/)
>>
>> However, I can say that we've deliberately moved away from using "we'll
>> just give extensions that use this API extra close scrutiny during
>> review".  Somebody like Andreas or Jorge can probably explain the reasoning
>> for that better than I can but I think that essentially it doesn't work at
>> scale, plus it isn't clear how unlisted extensions should be handled.
>>
>> Its not a direct replacement, but when creating new APIs we have tried
>> hard to design them in a way that it is clear to users when an extension
>> has (or might have) affected something and the user can be given an
>> opportunity to easily disable the extension if that isn't something they
>> desire.  (examples of this are the doorhangers for an extension-provided
>> newtab page or the proposed UI handling for tabs hidden by extensions).
>> For TLS certificate validation, I think we would have lots of options.  Off
>> the top of my head, simple options would be changing the appearance of the
>> lock icon in the location bar or displaying a notification the first time a
>> page is