Re: WoSign: updated report and discussion

2016-10-12 Thread Percy
(Hmm, my previous comment about two faced WoSign disappeared from Google group 
probably due to anti-spam. Gerv, can you recover it for me?)

I also want to point out that WoSign is currently asking customers to go to 
StartCom to get DV certs. If we continue to trust StartCom, then WoSign 
basically suffered no consequences for gross negligence. 

"
Sorry, due to some security consideration, 
WoSign decide to close the free SSL certificate application temporarily. Sept. 
29th 2016.
You can visit https://www.startssl.com to get a Free SSL Certificate.
"
https://buy.wosign.com/free/#ssl
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: StartCom & Qihoo Incidents

2016-10-12 Thread 谭晓生
Yuwei, 
I don’t know who you are, but I can tell you and the community, Qihoo 360 never 
been involved in * Fire Wall project, if you did some investigation to the 
message that accused Qihoo 360 joined the project “Search Engine Content 
Security Management System”, you should know the project had been done on Feb 
2005, before Qihoo 360 was founded on Aug 2005, and the project is neither part 
of the * fire wall project nor a project done by Qihoo 360, actually it is 
part of the efforts to help Yahoo’s search engine could work in China, I was 
the tech head of Yahoo!China ‘s tech team, director of engineering and soon the 
CTO of Yahoo!China, I know what happened at that time.
 
Thanks,
Xiaosheng Tan



在 2016/10/13 上午5:22,“dev-security-policy 代表 Han 
Yuwei” 写入:

在 2016年10月13日星期四 UTC+8上午3:12:08,Ryan Sleevi写道:
> As Gerv suggested this was the official call for incidents with respect 
to StartCom, it seems appropriate to start a new thread.
> 
> It would seem that, in evaluating the relationship with WoSign and Qihoo, 
we naturally reach three possible conclusions:
> 1) StartCom is treated as an independent entity
> 2) StartCom is treated as a subsidiary of Qihoo
> 3) StartCom is treated as a subsidiary of WoSign
> 
> We know there are serious incidents with WoSign that, collectively, 
encourage the community to distrust future certificates. However, there hasn't 
been a similar investigation into the trustworthiness of StartCom as an 
independent entity or as an entity operated by Qihoo. It would seem that 
germane to the discussion is how trustworthy the claims are - from either 
StartCom or Qihoo - and how that affects trust.
> 
> Incidents with StartCom:
> A) Duplicate Serials. https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> We know that StartCom had issues issuing duplicate serials, in violation 
of RFC 5280. We know that they did not prioritize resolution, and when 
attempting resolution, did so incompletely, as the issue still resurfaced.
> 
> C) Improper OCSP responder. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> We know that StartCom continues to have issue with their OCSP responder 
after they issue certificates. Presumably, this is a CDN distribution delay, 
but we can't be sure, especially considering Incident A was with the underlying 
systems. As a consequence of this, users with StartCom certificates are 
disproportionately disadvantaged from enabling OCSP stapling, which many 
browser programs support (and is perhaps the only viable path towards a 
complete revocation solution).
> 
> E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> We know StartCom had a notoriously poor response to HeartBleed. Eddy 
first dismissed the significance, and then when proven wrong, still continued 
to charge $25 USD for revocation. Ostensibly, this is a violation of the 
Baseline Requirements, in that CAs are required to revoke certificates 
suspected of Key Compromise. However, despite the BRs effective date of 2012, 
Mozilla was not aggressively imposing compliance then (... or now, to be fair).
> 
> G) StartCom BR violations - IV 
https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> StartCom was materially violating its CP/CPS and the Baseline 
Requirements with respect to certain types of validation. No explanation for 
the root cause provided.
> 
> I) StartCom BR violations (2) - Key Sizes 
https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> StartCom was issuing certificates less than 2048 bits.
> 
> K) StartCom impersonating mozilla.com. 
https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
www.mozilla.com and placed it on an Internet-facing server.
> 
> M) StartCom BR violations (3) - Key exponents 
https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> StartCom was not enforcing the BRs with respect to RSA public exponents.
> 
> O) StartCom BR violations (4) - Curve violations 
https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> StartCom was not enforcing the BRs with respect to EC curve algorithms.
> 
> 
> 
> In addition to discussion of StartCom issues, it seems relevant to future 
trust to evaluate issues with Qihoo. Many in the Mozilla community may not have 
direct interactions with Qihoo, but they have obtained some notoriety in 
security circles.
> 
> Q.A) Qihoo masking their browser as a critical Windows security update to 
IE users.
> http://wmos.info/archives/7717 / 
http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows 

Re: WoSign: updated report and discussion

2016-10-12 Thread 谭晓生
The HSM is stored offline, in the Vault of Qihoo 360’s head quarter, a little 
bit surprised by this question, I don’t know if there other CAs put their Root 
Certificates online?
If anybody have evident to say “Wosign have the private key of StartCom”, 
please show us here.

Thanks,
Xiaosheng Tan


在 2016/10/13 上午6:49,“dev-security-policy 代表 
Percy” 写入:

On Monday, October 10, 2016 at 2:16:53 PM UTC-7, Matt Palmer wrote:
> On Mon, Oct 10, 2016 at 10:33:15AM -0700, Nick Lamb wrote:
> > Would anybody here _seriously_ be shocked to read next month that a 
black
> > hat group is auctioning some StartCom private keys ?  On the evidence
> > available we have to assume that the keys underpinning both WoSign and
> > StartCom may turn out to be compromised,
> 
> Say what-now?  I don't recall anything that suggested private key
> *compromise*.  The need to roll the keys, from what I can see, is because
> the existing chains have done "things" that are shady, and we can never be
> sure there isn't more shady things lurking in the shadows.  Hence, we
> distrust the keys entirely to prevent any of the old shady from leaping 
out
> in a year's time and laying waste to the landscape once again.
> 
> - Matt

" PKI – signing service 
>Code: Same code with WoSign’s one. 
>Server: Shared Server. 
>Location: The primary one is hosted in Qihoo 360 head quarter’s data 
center in Beijing since Dec 2015, there is a backup server in Wosign’s office 
in Shenzhen. 
>Business Process: Same 
"
As Jakob said, WoSign might have StartCom's private key. Xiaosheng Tan, 
perhaps you can clarify what the backup server process and whether HSM is 
"backed up" as well. 



___
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


RE: StartCom & Qihoo Incidents

2016-10-12 Thread Stefan Paletta
> Similarly, if we were to accept trust in Qihoo, then we would be ignoring the 
> precedent Qihoo has set of choosing insecure and anti-user behaviours masked 
> as "security".

I dare say your cert store will end up as a pretty lonely place if you start 
investigating CAs –outside the realm of CA per se– and their parent companies 
for questionable security and shady business.

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


Re: WoSign: updated report and discussion

2016-10-12 Thread Percy
On Monday, October 10, 2016 at 2:16:53 PM UTC-7, Matt Palmer wrote:
> On Mon, Oct 10, 2016 at 10:33:15AM -0700, Nick Lamb wrote:
> > Would anybody here _seriously_ be shocked to read next month that a black
> > hat group is auctioning some StartCom private keys ?  On the evidence
> > available we have to assume that the keys underpinning both WoSign and
> > StartCom may turn out to be compromised,
> 
> Say what-now?  I don't recall anything that suggested private key
> *compromise*.  The need to roll the keys, from what I can see, is because
> the existing chains have done "things" that are shady, and we can never be
> sure there isn't more shady things lurking in the shadows.  Hence, we
> distrust the keys entirely to prevent any of the old shady from leaping out
> in a year's time and laying waste to the landscape once again.
> 
> - Matt

" PKI – signing service 
>Code: Same code with WoSign’s one. 
>Server: Shared Server. 
>Location: The primary one is hosted in Qihoo 360 head quarter’s data 
> center in Beijing since Dec 2015, there is a backup server in Wosign’s office 
> in Shenzhen. 
>Business Process: Same 
"
As Jakob said, WoSign might have StartCom's private key. Xiaosheng Tan, perhaps 
you can clarify what the backup server process and whether HSM is "backed up" 
as well. 



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


Re: StartCom & Qihoo Incidents

2016-10-12 Thread Percy
The Chinese wikipedia has well documented controversies surrounding Qihoo 360. 
Unfortunately, it's not translated into the English Wikipedia. So please go to 
https://zh.wikipedia.org/wiki/%E5%A5%87%E8%99%8E360#.E5.95.86.E4.B8.9A.E7.9F.9B.E7.9B.BE.E4.B8.8E.E4.BA.89.E8.AE.AE.E4.BA.8B.E4.BB.B6
 and use Google Translate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: StartCom & Qihoo Incidents

2016-10-12 Thread Han Yuwei
在 2016年10月13日星期四 UTC+8上午3:12:08,Ryan Sleevi写道:
> As Gerv suggested this was the official call for incidents with respect to 
> StartCom, it seems appropriate to start a new thread.
> 
> It would seem that, in evaluating the relationship with WoSign and Qihoo, we 
> naturally reach three possible conclusions:
> 1) StartCom is treated as an independent entity
> 2) StartCom is treated as a subsidiary of Qihoo
> 3) StartCom is treated as a subsidiary of WoSign
> 
> We know there are serious incidents with WoSign that, collectively, encourage 
> the community to distrust future certificates. However, there hasn't been a 
> similar investigation into the trustworthiness of StartCom as an independent 
> entity or as an entity operated by Qihoo. It would seem that germane to the 
> discussion is how trustworthy the claims are - from either StartCom or Qihoo 
> - and how that affects trust.
> 
> Incidents with StartCom:
> A) Duplicate Serials. https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> We know that StartCom had issues issuing duplicate serials, in violation of 
> RFC 5280. We know that they did not prioritize resolution, and when 
> attempting resolution, did so incompletely, as the issue still resurfaced.
> 
> C) Improper OCSP responder. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> We know that StartCom continues to have issue with their OCSP responder after 
> they issue certificates. Presumably, this is a CDN distribution delay, but we 
> can't be sure, especially considering Incident A was with the underlying 
> systems. As a consequence of this, users with StartCom certificates are 
> disproportionately disadvantaged from enabling OCSP stapling, which many 
> browser programs support (and is perhaps the only viable path towards a 
> complete revocation solution).
> 
> E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> We know StartCom had a notoriously poor response to HeartBleed. Eddy first 
> dismissed the significance, and then when proven wrong, still continued to 
> charge $25 USD for revocation. Ostensibly, this is a violation of the 
> Baseline Requirements, in that CAs are required to revoke certificates 
> suspected of Key Compromise. However, despite the BRs effective date of 2012, 
> Mozilla was not aggressively imposing compliance then (... or now, to be 
> fair).
> 
> G) StartCom BR violations - IV 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> StartCom was materially violating its CP/CPS and the Baseline Requirements 
> with respect to certain types of validation. No explanation for the root 
> cause provided.
> 
> I) StartCom BR violations (2) - Key Sizes 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> StartCom was issuing certificates less than 2048 bits.
> 
> K) StartCom impersonating mozilla.com. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> www.mozilla.com and placed it on an Internet-facing server.
> 
> M) StartCom BR violations (3) - Key exponents 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> StartCom was not enforcing the BRs with respect to RSA public exponents.
> 
> O) StartCom BR violations (4) - Curve violations 
> https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> StartCom was not enforcing the BRs with respect to EC curve algorithms.
> 
> 
> 
> In addition to discussion of StartCom issues, it seems relevant to future 
> trust to evaluate issues with Qihoo. Many in the Mozilla community may not 
> have direct interactions with Qihoo, but they have obtained some notoriety in 
> security circles.
> 
> Q.A) Qihoo masking their browser as a critical Windows security update to IE 
> users.
> http://wmos.info/archives/7717 / 
> http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows users that instead 
> installed their browser.
> 
> Q.C) Qihoo browser actively enables insecure cryptography.
> https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit
> Qihoo's browser is notably insecure with respect to SSL/TLS, with some of the 
> insecure changes requiring active modification to the low-level source 
> libraries that Chromium (of which they're based on) uses.
> 
> Q.E) Qihoo apps removed from app stores due to malware
> https://www.techinasia.com/qihoo-committing-fraud-google-making-huge-mistake 
> / https://www.techinasia.com/qihoo-apps-banned-apple-app-store
> Qihoo Apps have repeatedly been banned from Apple's App Store due to issues
> 
> Q.G) Qihoo "security" apps repeatedly found as unfair competition
> https://www.techinasia.com/qihoo-360-loses-chinas-courts-ordered-pay-sogou-82-million-unfair-competition
> 
> 
> 
> I hope the above show that the odds are if the original StartCom systems are 
> 

Re: StartCom & Qihoo Incidents

2016-10-12 Thread Percy
I'd also like to point out the Qihoo 360 cheated in all anti-virus tests 
http://www.computerworld.com/article/2917384/malware-vulnerabilities/antivirus-test-labs-call-out-chinese-security-company-as-cheat.html
 When Qihoo was caught out, Qihoo turned it into a market campaign, calling 
AV-C outdated and saying Qihoo's cloud engine is much more advanced and 
announced it quit 
(http://tech.sina.com.cn/i/2015-05-02/doc-icczmvup0903459.shtml article in 
Chinese )
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


StartCom & Qihoo Incidents

2016-10-12 Thread Ryan Sleevi
As Gerv suggested this was the official call for incidents with respect to 
StartCom, it seems appropriate to start a new thread.

It would seem that, in evaluating the relationship with WoSign and Qihoo, we 
naturally reach three possible conclusions:
1) StartCom is treated as an independent entity
2) StartCom is treated as a subsidiary of Qihoo
3) StartCom is treated as a subsidiary of WoSign

We know there are serious incidents with WoSign that, collectively, encourage 
the community to distrust future certificates. However, there hasn't been a 
similar investigation into the trustworthiness of StartCom as an independent 
entity or as an entity operated by Qihoo. It would seem that germane to the 
discussion is how trustworthy the claims are - from either StartCom or Qihoo - 
and how that affects trust.

Incidents with StartCom:
A) Duplicate Serials. https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
We know that StartCom had issues issuing duplicate serials, in violation of RFC 
5280. We know that they did not prioritize resolution, and when attempting 
resolution, did so incompletely, as the issue still resurfaced.

C) Improper OCSP responder. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
We know that StartCom continues to have issue with their OCSP responder after 
they issue certificates. Presumably, this is a CDN distribution delay, but we 
can't be sure, especially considering Incident A was with the underlying 
systems. As a consequence of this, users with StartCom certificates are 
disproportionately disadvantaged from enabling OCSP stapling, which many 
browser programs support (and is perhaps the only viable path towards a 
complete revocation solution).

E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=994478
We know StartCom had a notoriously poor response to HeartBleed. Eddy first 
dismissed the significance, and then when proven wrong, still continued to 
charge $25 USD for revocation. Ostensibly, this is a violation of the Baseline 
Requirements, in that CAs are required to revoke certificates suspected of Key 
Compromise. However, despite the BRs effective date of 2012, Mozilla was not 
aggressively imposing compliance then (... or now, to be fair).

G) StartCom BR violations - IV 
https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
StartCom was materially violating its CP/CPS and the Baseline Requirements with 
respect to certain types of validation. No explanation for the root cause 
provided.

I) StartCom BR violations (2) - Key Sizes 
https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
StartCom was issuing certificates less than 2048 bits.

K) StartCom impersonating mozilla.com. 
https://bugzilla.mozilla.org/show_bug.cgi?id=471702
StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
www.mozilla.com and placed it on an Internet-facing server.

M) StartCom BR violations (3) - Key exponents 
https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
StartCom was not enforcing the BRs with respect to RSA public exponents.

O) StartCom BR violations (4) - Curve violations 
https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
StartCom was not enforcing the BRs with respect to EC curve algorithms.



In addition to discussion of StartCom issues, it seems relevant to future trust 
to evaluate issues with Qihoo. Many in the Mozilla community may not have 
direct interactions with Qihoo, but they have obtained some notoriety in 
security circles.

Q.A) Qihoo masking their browser as a critical Windows security update to IE 
users.
http://wmos.info/archives/7717 / 
http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
Qihoo displayed a misleading security update for Windows users that instead 
installed their browser.

Q.C) Qihoo browser actively enables insecure cryptography.
https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit
Qihoo's browser is notably insecure with respect to SSL/TLS, with some of the 
insecure changes requiring active modification to the low-level source 
libraries that Chromium (of which they're based on) uses.

Q.E) Qihoo apps removed from app stores due to malware
https://www.techinasia.com/qihoo-committing-fraud-google-making-huge-mistake / 
https://www.techinasia.com/qihoo-apps-banned-apple-app-store
Qihoo Apps have repeatedly been banned from Apple's App Store due to issues

Q.G) Qihoo "security" apps repeatedly found as unfair competition
https://www.techinasia.com/qihoo-360-loses-chinas-courts-ordered-pay-sogou-82-million-unfair-competition



I hope the above show that the odds are if the original StartCom systems are 
restored, we're likely to continue to have significant BR violations - a 
pattern StartCom has repeatedly demonstrated over several years. Similarly, if 
we were to accept trust in Qihoo, then we would be ignoring the precedent Qihoo 
has set of 

Re: WoSign: updated report and discussion

2016-10-12 Thread Jakob Bohm

On 09/10/2016 15:54, 谭晓生 wrote:

Dear All,
This is the information that would be released by Inigo in the coming week, 
Percy asked me to answer the question, so, it is here:

...

3. PKI – signing service
   Code: Same code with WoSign’s one.
   Server: Shared Server.
   Location: The primary one is hosted in Qihoo 360 head quarter’s data center 
in Beijing since Dec 2015, there is a backup server in Wosign’s office in 
Shenzhen.
   Business Process: Same



Wait: Does this mean that WoSign has a copy of the StartCOM root
private key at the WoSign office?

Are there any technical obstacles to ensure that Richard Wang or his
underlings have not used that key in ways not logged in the log files
and databases now controlled by the new StartCOM?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SHA-1 Phase-out

2016-10-12 Thread Nick Lamb
On Wednesday, 12 October 2016 14:50:22 UTC+1, Gervase Markham  wrote:
> However, we would counsel all sites to move
> away from SHA-1 as the user experience will be as bad as the security.

A message I've seen from some security vendors, that I don't want us 
reinforcing, is the idea that the SHA-1 certificates themselves are a security 
problem and "upgrading" to a SHA-256 certificate improves security.

I think bank notes (outside the US) are a useful analogy. Sometimes the central 
bank may begin issuing a new note with improved anti-forgery features. To 
ensure forgers can't just keep making the old, more easily forged notes, these 
are eventually withdrawn from general use once enough of the new are in 
circulation.

It would be a mistake to try to "improve" the security of your business by 
swapping all its cash for the latest notes. The new notes aren't "more secure" 
in a way that affects you, you haven't improved anything by doing this. Your 
business should pay attention to notices from the bank about new notes coming 
into circulation and about old ones being withdrawn, and make appropriate 
plans, but so long as it does that there's no problem.

Web PKI Subscribers should be switching to SHA-1 because their Issuer requires 
it. CA/B rules make that clear, compliance seems to be pretty good but browser 
vendors like Mozilla are taking out insurance against the possibility that 
somebody, somewhere, made a mistake. In my view for ordinary subscribers in the 
Web PKI it's primarily a compatibility issue, rather than a security issue. Off 
the Web PKI, in private systems, the risk/ reward may look very different. If 
your PKI only issues certificates on a sight basis to a handful of trusted 
individuals suddenly the chosen prefix attack doesn't look like a real security 
risk at all so SHA-1 seems fine.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SHA-1 Phase-out

2016-10-12 Thread Gervase Markham
On 12/10/16 14:46, Konstantinos Tsimaris wrote:
> I have seen various posts mentioning that after 1 of January 2017, browsers
> will stop support of SHA1 signed CAs. I am looking into a way to identify
> which WEB sites will not work until new certificate is applied and
> demonstrate that after change it will work. I know that can be done via
> checking the issued CA. Is there a way using a Firefox to replicate the
> behavior/block prior to that date?
> 
> Second, I would like to ask if a user has option to permit if required, for
> example using "security.pki.sha1_enforcement_level"

That preference is exactly how you test the behaviour prior to the date
the block is implemented. Set the value to 1 (entirely forbidden) or 3
(forbidden for public roots).

Users will be able to permit SHA-1 individually after the block is
enacted by default, using that pref. Also, the current plan is that the
error will be overridable. However, we would counsel all sites to move
away from SHA-1 as the user experience will be as bad as the security.

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


SHA-1 Phase-out

2016-10-12 Thread Konstantinos Tsimaris
Hi Security team,

I have 2 questions which I would be grateful if you can help.

I have seen various posts mentioning that after 1 of January 2017, browsers
will stop support of SHA1 signed CAs. I am looking into a way to identify
which WEB sites will not work until new certificate is applied and
demonstrate that after change it will work. I know that can be done via
checking the issued CA. Is there a way using a Firefox to replicate the
behavior/block prior to that date?

Second, I would like to ask if a user has option to permit if required, for
example using "security.pki.sha1_enforcement_level"

Kind Regards,
Kostas Tsimaris
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy