> 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
https://lists.mo
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 Ke
(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 R
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
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,
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 that
> 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 for
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 Sh
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 thought it's so obvious and Comodo people
wi
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 quick
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.
>
> trustic
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*
certifi
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 the
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 ho
> 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 youtub
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
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/
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 c
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/c
On Thursday, 1 March 2018 15:32:56 UTC, Alex Gaynor wrote:
> 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, Ma
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@
21 matches
Mail list logo