Re: Trustico code injection

> Trustico have assured us that the private key > could not have been compromised. Did they elaborate on how they came to that "could not have been" conclusion? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Trustico code injection

That's not what Trustico are saying in their fulfilment emails (received during the purchase of a Trustico® certificate through Comodo CA this morning): 'If you chose to have us generate your CSR during the ordering process, you will need to contact us for a copy of your corresponding Private

Re: Trustico code injection

(re-sending to list) > We also asked Trustico to cease offering any tools to generate and/or retain customer private keys. Does Comodo intend to standardize a policy against this? GoGetSSL has a tool like this in their customer panel and I’m sure there are more. On Fri, Mar 2, 2018 at 12:29 PM

RE: Trustico code injection

https://crt.sh/?id=206535041 is now revoked. Regards, Rich Smith smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

We also asked Trustico to cease offering any tools to generate and/or retain customer private keys. They have complied with this request and have confirmed that they do not intend to offer any such tools again in the future. Trustico have also confirmed to us that they were not, and are not,

RE: Trustico code injection

Comodo CA has investigated the reports posted to this list relating to the suspected compromise of the private key corresponding to https://crt.sh/?id=206535041. Trustico have assured us that the private key could not have been compromised. However, since it will be hard to convince everyone

Re: Trustico code injection

> 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

Re: Trustico code injection

Not in my opinion. If my house is burning, I expect someone to call the fire department even if I am not aware/convinced that the house is burning. The fact that they disabled their website is evidence that the Twitter posts were no fake. Am Donnerstag, 1. März 2018 20:53:16 UTC+1 schrieb Tim

Comodo and Trustico (was Re: Trustico code injection)

On Fri, 2 Mar 2018 16:10:52 +0900 Hector Martin 'marcan' via dev-security-policy wrote: > And what does Comodo think of all of this? I'd like to second this. When I wrote the original mail in this thread I considered adding questions to Comodo, but I

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