Re: Trustico code injection

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

Re: Trustico code injection

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. > >

Re: Trustico code injection

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*

Re: Mozilla’s Plan for Symantec Roots

> > > > 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

Re: Mozilla’s Plan for Symantec Roots

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

Re: Mozilla’s Plan for Symantec Roots

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

Re: Trustico code injection

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

Re: Trustico code injection

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

Re: Trustico code injection

> 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

Re: Trustico code injection

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

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

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

Re: Trustico code injection

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: >>

Re: Trustico code injection

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

Re: Trustico code injection

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: >

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

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

Re: How do you handle mass revocation requests?

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

Re: How do you handle mass revocation requests?

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

Re: Mozilla’s Plan for Symantec Roots

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

Re: How do you handle mass revocation requests?

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

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

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

Re: Trustico code injection

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 <

Re: How do you handle mass revocation requests?

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

Trustico code injection

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

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

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 <

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

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

Re: How do you handle mass revocation requests?

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

RE: How do you handle mass revocation requests?

> 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

Re: How do you handle mass revocation requests?

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:

Re: How do you handle mass revocation requests?

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

Re: How do you handle mass revocation requests?

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

Re: WebExtensions Overriding TLS Certificate Validation

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