Re: TLS everywhere has a major flaw and needs refining to the page level.
On Fri, 16 Feb 2018 08:15:10 -0800 > Given this group focused on Mozilla, it is likely out of scope to > discuss Chromium design. I do suggest you look at > https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html > It seems reasonably clear the marking is per top level page load. > This is very similar to the UI for Firefox which shows the lock (and > EV info) per top level page load. "helped users understand that HTTP sites are not secure by gradually marking a larger subset of HTTP pages as “not secure”. not secure example.com webpage not secured example.com - may be better? To me it seems to be saying that the domain is "not secure" which is incorrect. The page is "not secured" and the domain may be more secure than another labelled secure (not not secure). If the goal is to move everyone to https in fear of their sites looking insecure rather than inform the user then I understand. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TLS everywhere has a major flaw and needs refining to the page level.
On Thu, 15 Feb 2018 15:55:27 -0600 > I'm not sure this can be worked around. A setup where time is not > pulled from the network is abnormal now, and most people who have such > a system soon realize what the issue is. OpenNTP has a constraint system but considering NTP is a latent, insecure, untrusted server protocol, synchronising the clock in one go is not the recommended default. Instead it used https constraints and 8 UDP server samples before skewing slightly. I don't know if the windows version is a less latent but secured protocol. > > The certificate warnings are a good reminder to update my clock > (seriously). Perhaps offer this information on the error page? Yeah, I don't think the messages are as clear these days as to what the issue is. The idea being to reduce click through, perhaps they could manually update their clock in that case but not understand the messages otherwise or been taught to stop when strange things happen or not to click on error boxes. On that subject I think the chromium reported plan to label sites as insecure should perhaps be revised to page insecured or something more accurate? Additionally it infers sites labelled secure or not labelled insecure are secure when they may have terrible security but utilise TLS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
TLS everywhere has a major flaw and needs refining to the page level.
The cookies etc. should be SSL only. Particular pages enforced, sure. Enforcing TLS with HSTS sitewide means that users with failed bios/laptop batteries have to know to reset their clock or get used to bypassing SSL warnings or use out of date browsers to access sites. A fairly common problem, not good. Think real world, please. This hurts the most vulnerable. Another solution may be to remove the cert is not valid YET restriction but that is a can of worms. Thankyou ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On Tuesday, November 15, 2016 at 6:03:07 AM UTC-5, wangs...@gmail.com wrote: > 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道： > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: > > > We have uploaded the lastest translantion of CP/CPS. > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546 > > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547 > > > > > > Because of our English level, there maybe some mistakes. If you have any > > > questions, please contact us. > > > > > > Thanks to all of you who have reviewed and commented on this request from > > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 > > ROOT" certificate, turn on the Websites trust bit, and enabled EV > > treatment. > > > > There were some recommendations to deny this request due to the versioning > > problems between the English documents and the original documents. > > > > Do you all still feel that is the proper answer to this root inclusion > > request? > > > > Or should we proceed with reviewing these new English translations of the > > documents, and make our decision based on the new versions? > > > > Thanks, > > Kathleen > > Because we misunderstand that we only need to provide the related chapters of > CP/CPS in English, and non-related sections are not required. We are terribly > sorry that we misinterpreted your requirement and upload an inconsistent > CP/CPS in English. Someone inferred that we don’t utilize a version control > for CP/CPS. In fact, we do have a strict control for master version CP/CPS > (see section 1.5 in CP/CPS). > We understand that it is our responsibility to provide accurate English > versions and ensure consistency and synchronicity between Chinese and English > versions. Hence, we have decided to strictly implement version controlling of > English version CP/CPS according to section 1.5 in CP/CPS. The auditor is > reviewing our complete CP/CPS in English and the new version will be > published as soon as possible. > We will keep open mind to process any further issues. Read through this discussion thread, here is my take on this. GDCA has taken action to address the discrepancies between English and Chinese CP/CPS and put in place stricter version control. So we should look at the updated version, if that's deemed good I don't see other reason to reject. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
