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 thi
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 Certi
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 ce
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
> 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
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
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
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-polic
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 sou
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 t
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@
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 S
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 wa
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
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.
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
On Thu, Mar 1, 2018 at 11:14 AM, Kai Engert wrote:
> 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
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
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 Cert
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
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 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/
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 opera
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
> 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 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
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 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 ye
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
> >
> > 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 G
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
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
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
33 matches
Mail list logo