Re: Comodo password exposed in GitHub allowed access to internal Comodo files

2019-07-27 Thread Nick Lamb via dev-security-policy
On Sun, 28 Jul 2019 00:06:38 +0200
Ángel via dev-security-policy 
wrote:

> A set of credentials mistakenly exposed in a public GitHub repository
> owned by a Comodo software developer allowed access to internal Comodo
> documents stored in OneDrive and SharePoint:
> 
> https://techcrunch.com/2019/07/27/comodo-password-access-data/
> 
> 
> It doesn't seem that it affected the certificate issuance system, but
> it's an ugly security incident nevertheless.

What was once the Comodo CA is named Sectigo these days, so conveniently
for us this makes it possible to simply ask whether the incident
affected Sectigo at all:

- Does Sectigo in practice share systems with Comodo such that this
  account would have access to Sectigo internal materials ?

In passing it's probably a good time to remind all programme
participants that Multi-factor Authentication as well as being
mandatory for some elements of the CA function itself (BR 6.5.1), is a
best practice for any security sensitive business like yours to be using
across ordinary business functions in 2019. Don't let embarrassing
incidents like this happen to you.

Nick.



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


Re: Comodo password exposed in GitHub allowed access to internal Comodo files

2019-07-27 Thread Ronald Crane via dev-security-policy

Thank you for posting that notice.

It's not clear whether the leak impacted issuance. From the link you cited:


*** Other documents appeared to be Comodo vulnerability reports. *** 
Ursem’s cursory review of the data did not turn up any customer 
certificates private keys, however.



(emphasis added). If "Comodo vulnerability reports" means unfixed 
security bugs reported to or known by Comodo, there could be continuing 
exposure to hacking, possibly affecting issuance.


-R

On 7/27/2019 3:06 PM, Ángel via dev-security-policy wrote:

A set of credentials mistakenly exposed in a public GitHub repository
owned by a Comodo software developer allowed access to internal Comodo
documents stored in OneDrive and SharePoint:

https://techcrunch.com/2019/07/27/comodo-password-access-data/


It doesn't seem that it affected the certificate issuance system, but
it's an ugly security incident nevertheless.

___
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


Comodo password exposed in GitHub allowed access to internal Comodo files

2019-07-27 Thread Ángel via dev-security-policy
A set of credentials mistakenly exposed in a public GitHub repository
owned by a Comodo software developer allowed access to internal Comodo
documents stored in OneDrive and SharePoint:

https://techcrunch.com/2019/07/27/comodo-password-access-data/


It doesn't seem that it affected the certificate issuance system, but
it's an ugly security incident nevertheless.

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


Re: Nation State MITM CA's ?

2019-07-27 Thread vtolkm--- via dev-security-policy
* whatever the legislation of a sovereign state it can hardly be a browser's 
remit to govern the state's citizen by hard coding a block, preventing those 
not participating in this panel discussion to install the certificate(s) if 
they would desire to do so (for whatever reason that may be and that may seem 
inexplicable/controversial to anyone petitioning for a hard coded block)
* whether the relatively few opinions, compared to the electorate of a state, 
in this panel discussion are (a) representative (majority) of said electorate 
is debatable
* if this becomes a test case for defying the legislation of a sovereign state 
and a hard coded block is elected then it will have to be replicated so without 
bias for any other state that aspires a similar measure, regardless of such 
state's state of domestic affairs. Else it would taint the renown instilled in 
the trust lender (certificate store)
* are there any such petitions made to other vendors, or panel discussions held 
with such vendors, that provide certificate stores, such as Google, Apple, 
Microsoft? 
* what would be the measurable impact in terms of users if only Mozilla 
implements a hard coded block?
* and if this discussion is meant to put a spotlight on MitM (at least the the 
topic's subject would imply as such and if not then please pardon/ignore the 
digression) as well then perhaps consider that the majority of users is 
blisfully unaware when their TLS connections are being termniated (decrypted) 
midair whilst reaching a host that is being served through reverse proxy 
providers (cue SNI). Here the remote host allows the reverse proxy to decrypt 
the traffic at its edge server and thus all the traffic is accessible in the 
clear to the reverse proxy provider (MitM). Whether the intentions of a reverse 
proxy provider are more sublime than a state probably lies in the eye of the 
beholder and likely vary as much.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy