Re: Proposal: Switch generic icon to negative feedback for non-https sites
FWIW, that's a misquote; I didn't write that. On Aug 12, 2014 4:38 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: [Apologies if you've seen this before, it looks like up to a week's worth of mail from here has been lost, this is a resend of the backlog] Chris Palmer pal...@google.com writes: Firefox 31 data: on desktop the median successful OCSP validation took 261ms, and the 95th percentile (looking at just the universe of successful ones) was over 1300ms. 9% of all OCSP requests on desktop timed out completely and aren't counted in those numbers. Do you have equivalent data for the TLS connect times? In other words how much was TLS being slowed down by including OCSP? Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
Chris Palmer pal...@google.com writes: FWIW, that's a misquote; I didn't write that. Ooops, sorry, it was posted by Patrick McManus pmcma...@mozilla.com (I used a script to try and resurrect the lost emails for re-send, I suspect something got mangled somewhere). So the question should have been addressed to Patrick (or anyone else who wants to answer, enciphering minds want to know :-). Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Wed, August 13, 2014 6:14 pm, Peter Gutmann wrote: Chris Palmer pal...@google.com writes: FWIW, that's a misquote; I didn't write that. Ooops, sorry, it was posted by Patrick McManus pmcma...@mozilla.com (I used a script to try and resurrect the lost emails for re-send, I suspect something got mangled somewhere). So the question should have been addressed to Patrick (or anyone else who wants to answer, enciphering minds want to know :-). Peter. Peter, I suspect you haven't received an answer because your question doesn't quite make sense. In the other thread, Patrick provided the details for how to look up the details for Mozilla telemetry (http://telemetry.mozilla.org - unfortunately, HTTPS doesn't work for this domain) The answer for how much the TLS connection was being affected by OCSP is sort of answered by How long did OCSP take, which Patrick provided the details of. Phrasing the data in terms of overall connection handshake time doesn't really work either - OCSP is, by design, a serial and blocking process. You check one cert, then the next, then the next. So that time accumulates. However, if you wish to slice the data for your own analysis, well, as Pat mentioned, Mozilla's data is there. From the looks of it, Chrome is capturing a lot more data points in terms of the SSL connection details, but we saw similar-to-worse performance across our platforms, including dominant platforms (like Windows), which have a number of optimizations for revocation checks, and 'marginal' platforms like OS X, which have a number of limitations in their revocation checking ability. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
[Apologies if you've seen this before, it looks like up to a week's worth of mail from here has been lost, this is a resend of the backlog] Chris Palmer pal...@google.com writes: Firefox 31 data: on desktop the median successful OCSP validation took 261ms, and the 95th percentile (looking at just the universe of successful ones) was over 1300ms. 9% of all OCSP requests on desktop timed out completely and aren't counted in those numbers. Do you have equivalent data for the TLS connect times? In other words how much was TLS being slowed down by including OCSP? Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 8/10/2014 8:16 PM, David E. Ross wrote: On 8/10/2014 4:09 PM, Matt Palmer wrote: On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. How do you get from resells certificates and bolts parts together to he is a professional in [...] security? I won't deny that he is in the computer systems profession (in the very precise definition of for a livelihood), but beyond that, you're drawing an *exceptionally* long bow. - Matt I was a computer systems integrator for over 30 years. I fully understand what integrator means. In my career, sopftware integration often included dealing with secure systems and how they were made secure. Let me put dealing in context. I wrote the specifications for the software including the components that handled the security of databases, displays, and printouts. I tested the software in an end-user environment, after which I sometimes rejected it and sent it back to the developer. I prepared the user documentation for the software. And I taught classes to U.S. Air Force officers on how to use the software. All this was for software systems used to operate earth-orbiting, classified, military space satellites. I understand secure software systems, and Rosenthal's blog makes sense to me. Rosenthal is also a reseller of X.509 subscriber certificates, which should mean he understands Internet security. Otherwise, how is he allowed to sell such certificates? Add those two concepts together. I will not further defend Rosenthal. I think he is competent to defend himself. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 11/08/14 04:16, David E. Ross wrote: Rosenthal is also a reseller of X.509 subscriber certificates, which should mean he understands Internet security. Otherwise, how is he allowed to sell such certificates? I don't often say this, because it's not often true, but... LOL. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
Can we please declare this thread closed? The level of debate has gotten a little low. --Richard On Aug 9, 2014, at 7:53 PM, David E. Ross nobody@nowhere.invalid wrote: On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. Although he has a vested interest in selling site certificates, he argues against the idea that all Web sites should be HTTPS. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ 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: Proposal: Switch generic icon to negative feedback for non-https sites
Yes, I started this thread. I officially declare this thread closed...even though I have no ability to enforce it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Sat, August 9, 2014 4:53 pm, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. Although he has a vested interest in selling site certificates, he argues against the idea that all Web sites should be HTTPS. David, At the risk of engaging what may be trolling behaviour (non-attributable email addresses and all that good jazz), and while a point-by-point takedown is not particularly worthy, the author makes a number of demonstrably false or misleading claims. 1) That the issuance of certs increases the likelihood of CA compromise. Evidence demonstrates the opposite, but either way, they're orthogonal issues entirely. Having more certificates issued does not directly make it more likely for a CA (like DigiNotar) to be breached. 2) The author continues to make the claim of additional server overhead and network/router/internet traffic, except leading experts and implementers have shown time and time again that these are not true. 3) The author makes spurious leaps to seem to bolster their argument, but frankly, they're misleading and FUD. There are attacks which bypass cookies altogether, thus rendering the threat from cookies themselves if not obsolete, on their way in that direction - the threat is not FROM cookies, but TO cookies. Will we soon need to encrypt our DNS queries ignores the purpose of SSL (authenticity and integrity, and not just privacy), but as a strawman, sure. If we're going to quote random blogs, why not https://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/ or http://scn.sap.com/community/netweaver/blog/2013/06/23/whos-afraid-of-ssl or https://www.youtube.com/watch?v=cBhZ6S0PFCY Now, I don't know the author, I have nothing personal against them, but there are a lot of genuine mistakes in that article. Hopefully you can realize them now. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. How do you get from resells certificates and bolts parts together to he is a professional in [...] security? I won't deny that he is in the computer systems profession (in the very precise definition of for a livelihood), but beyond that, you're drawing an *exceptionally* long bow. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 10/08/14 11:16 PM, David E. Ross wrote: On 8/10/2014 4:09 PM, Matt Palmer wrote: On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. How do you get from resells certificates and bolts parts together to he is a professional in [...] security? I won't deny that he is in the computer systems profession (in the very precise definition of for a livelihood), but beyond that, you're drawing an *exceptionally* long bow. - Matt I was a computer systems integrator for over 30 years. I fully understand what integrator means. In my career, sopftware integration often included dealing with secure systems and how they were made secure. Rosenthal is also a reseller of X.509 subscriber certificates, which should mean he understands Internet security. Otherwise, how is he allowed to sell such certificates? Add those two concepts together. An appeal to authority isn't much of an argument. HTTPS and HSTS are still very important for an entirely static site. The alternative is allowing an attacker to masquerade as the site and leverage the trust it has built for malicious purposes. If it's a blog, the latest post may appear to be a link to the attacker's payload with a stellar review. Encryption is only half of the picture, as HTTP connections offer no way to assure the authenticity of the source. Informing users that the browser is unable to verify the authenticity of the source is not a bad thing. It's possible to have authenticated but unencrypted data for a use case like this, but it's best if the opportunity to screw up by making the wrong choice is not there in the first place. There's no compelling reason not to encrypt everything because it's so cheap. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Sun, August 10, 2014 4:06 pm, Matt Palmer wrote: On Sat, Aug 09, 2014 at 11:52:16PM -0700, Ryan Sleevi wrote: At the risk of engaging what may be trolling behaviour (non-attributable email addresses and all that good jazz), and while a point-by-point takedown is not particularly worthy, the author makes a number of demonstrably false or misleading claims. 1) That the issuance of certs increases the likelihood of CA compromise. Evidence demonstrates the opposite, but either way, they're orthogonal issues entirely. Having more certificates issued does not directly make it more likely for a CA (like DigiNotar) to be breached. I'm curious to know what evidence you think demonstrates that issuing more certificates *reduces* the risk of CA compromise. I would say they *are* orthogonal issues, but you can't have it both ways -- they're meta-orthogonal (as it were). The evidence is that the majority of compromises/CA events in the past several years (DigiNotar, TurkTrust, India CCA, ANSSI ) have been nation-state vanity CAs that issue certificates to small populations. The 'big' CA's events (read: Comodogate, StartSSL) have been significantly more limited in scope, and have been contained, and have been quickly remediated (with quick communication on the CA's behalf) That's not to suggest correlation implies causation, merely that if the author (or David, by virtue of referencing the author) wishes to support such an idea, the evidence runs counter to their conclusion. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Sun, August 10, 2014 8:16 pm, David E. Ross wrote: I was a computer systems integrator for over 30 years. I fully understand what integrator means. In my career, sopftware integration often included dealing with secure systems and how they were made secure. That's a very... liberal... conclusion of what integrator means. I've known integrators who just glued together CMS systems. Does that mean they're also experts in computer systems? Rosenthal is also a reseller of X.509 subscriber certificates, which should mean he understands Internet security. Otherwise, how is he allowed to sell such certificates? There are no security requirements for resellers. Resellers are just the middlemen that facilitate the introduction of the CA to the customer, get a cut of the proceeds, and in return for such introductions, get to pretend they have a brand. Most importantly, resllser != registration authority. The two are, unsurprisingly, unrelated concepts. I say this because my dog could be a reseller, if she was allowed to enter into legal contracts. That's really the ONLY requirement, at the core, of a reseller. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Sun, Aug 10, 2014 at 08:16:42PM -0700, David E. Ross wrote: On 8/10/2014 4:09 PM, Matt Palmer wrote: On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote: Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. How do you get from resells certificates and bolts parts together to he is a professional in [...] security? I won't deny that he is in the computer systems profession (in the very precise definition of for a livelihood), but beyond that, you're drawing an *exceptionally* long bow. I was a computer systems integrator for over 30 years. I fully understand what integrator means. In my career, sopftware integration often included dealing with secure systems and how they were made secure. Dealing with != competent to assess and recommend. I deal with the electrical system in my house, by virtue of using it. Doesn't mean I'm a professional electrican. Rosenthal is also a reseller of X.509 subscriber certificates, which should mean he understands Internet security. How do you figure? Being a reseller of SSL certs just means that you're taking people's money and giving them someone else's certificates. Even if a reseller should understand Internet security (which isn't the case), is there any evidence to suggest that he does understand Internet security? Otherwise, how is he allowed to sell such certificates? Who assesses his competence, and is capable of prohibiting him (with meaningful sanctions) if he is not, in fact, competent? Add those two concepts together. My calculator laughed at me, muttering something about apples and oranges. I wonder what that means? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Anyone wishing to argue this issue further -- to argue in favor of implementing a scheme to encourage all Web sites to be HTTPS with site certificates -- should first read http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/. The blogger is a certificate reseller and also a computer systems integrator. Thus, he is a professional in the area of computer systems, including security. Although he has a vested interest in selling site certificates, he argues against the idea that all Web sites should be HTTPS. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Thursday, 7 August 2014 01:27:29 UTC+2, Matt Palmer wrote: On Wed, Aug 06, 2014 at 12:02:57AM -0700, andrew.be...@gmail.com wrote: Is there anything browser vendors can do to make SSL easier and cheaper across the board before punishing you for not using it? Implement support for DANE. It won't fix the 0.001% (by number, not traffic volume) of sites that use CDNs that charge outrageously for SSL support, but it will remove the cost and operational hassle barrier for the vast majority of sites. - Matt I second that: DANE support is the right direction to go! It considerably raises the effort required to do MITM attacks, it allows the site ops to cut out the CAs and take control back. If Firefox/Mozilla really want to be on the forefront: go for DANE! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
DANE (was Re: Proposal: Switch generic icon to negative feedback for non-https sites)
On Aug 7, 2014, at 2:17 PM, Chris Palmer pal...@google.com wrote: On Thu, Aug 7, 2014 at 7:11 AM, husem...@gmail.com wrote: I second that: DANE support is the right direction to go! It considerably raises the effort required to do MITM attacks, it allows the site ops to cut out the CAs and take control back. DANE relies on DNSSEC, which (apart from having had and lost its chance to be widely deployed) ossifies trust in fewer, more powerful third parties who use weaker keys. But now we are off the topic of this thread. Switched the subject line :) You're talking as if those fewer, more powerful third parties can't *already* subvert the CA system. Whether you like the DNS or not, all the many DV certs in the world are attesting to DNS names. All the CAs are supposed to be doing is verifying that the person requesting a cert is the person that holds a DNS name. Since the parent zones are authoritative for that, they can already screw you. (Verisign can get a cert for your .com domain; the Libyan government for your .ly domain.) DANE just centralizes the risk in one place. I don't disagree with the weaker keys point, but that can be fixed. Likewise, the brokenness of the DNS protocol as a way of fetching DNSSEC records can be mitigated with things like AGL's proposal for carrying DANE records in TLS. I'm not saying that DANE is a panacea, but we should be honest about the tradeoffs. --Richard ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Wed, Aug 6, 2014 at 12:02 AM, andrew.be...@gmail.com wrote: I'm all for pushing people onto SSL, and of course if you stigmatise non-secure connections the demand for SSL increases and CDNs will need to compete on their ability to support it at a reasonable cost. But there's a chicken and egg problem, to some extent. Is there anything browser vendors can do to make SSL easier and cheaper across the board before punishing you for not using it? The value proposition of CDNs has never been quite clear to me, especially at volume and especially with any requirement of security. If they choose to bilk people who ask for HTTPS, that just strengthens the rent your own rack on each continent argument. But that's another matter... I don't know what browsers can do to make it easier for server operators — I'm busy with Chrome; I don't work on Nginx or Apache. There's work they need to do to make configuration easier. That said, part of our activism campaign should probably involve nagging server vendors to ship better configurations by default, auto-generating keys and CSRs for each configured hostname/domain that doesn't already have one, et c. The default configurations of a lot servers are bad in a lot of ways, not even just HTTPS- or security-related. For getting certs, https://sslmate.com/ seems pretty good. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
on Tue, 22 Jul 2014 12:24:30 -0700, Brian Smith wrote: Having said all of that, I remember that Mozilla did some user research ~3 years ago that showed that when we show a negative security indicator like the broken lock icon, a significant percentage of users interpreted the problem to lie in the browser, not in the website--i.e. the security problem is Firefox's fault, not their favorite website. It would be important to do research to confirm or (hopefully) refute this finding. How about showing a red border around the webpage, possibly with a banner at the top (but inside the page area)? -- begin .sig Jernej Simončič ◊ jernej|s-ng at eternallybored.org end ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
- Original Message - From: Chris Palmer pal...@google.com To: Hubert Kario hka...@redhat.com Cc: David E. Ross nobody@nowhere.invalid, mozilla-dev-security-pol...@lists.mozilla.org Sent: Tuesday, 22 July, 2014 1:08:57 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites On Sun, Jul 20, 2014 at 3:23 AM, Hubert Kario hka...@redhat.com wrote: and while we're at it, let's get rid of those warnings about self signed certificates -- they are less insecure than HTTP (Firefox actually uses certificate pinning for sites with previously waived cert problems!) so let's not treat them worse than HTTP connections I'm pretty sure Firefox merely remembers your decision to click through the warning, not that it pins the keys/certificates in the chain you clicked through on. Although I have proposed that for certain use-cases, its applicability is limited — will people know how to recover if the key(s) change(s)? No, I'm sure it remembers the certificate. I have setup a SNI-enabled server that returns one certificate for two different virtual hosts. When the certificate was about to expire, I changed it to a new one signed by a trusted CA, for the site for which the CN matched, the Firefox didn't even bat an eye, for the site for which I had to waive the mismatched CN in the past, I had to waive the certificate again. I can retests with self signed certificates, but I'd be very surprised if it didn't work exactly the same. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Tue, Jul 22, 2014 at 12:24 PM, Brian Smith br...@briansmith.org wrote: On Mon, Jul 21, 2014 at 4:10 PM, Adrienne Porter Felt f...@chromium.org wrote: I would very much like to make http sites look insecure. But we face a very real problem: a large fraction of the web is still http-only. That means that: - Users will get used to the insecure icon, and it will start looking meaningless pretty quickly. - This might also make users ignore the broken https icon. I'm not sure how to reconcile this. I think they key to reconciling this is to recognize that the primary audience for the address bar UI elements for this are website *makers*, not website visitors, regardless of what we'd like. That is, if the indicators in the address bar are already so confusing or useless for end-users that they generally ignore them or take them to have the opposite meaning from what's intended, and yet users are still using our products, then that means that we don't have to worry so much about the possibility of adding end-user confusion by making such a change. Yet, it is in the economic interests of every website to avoid being branded not secure; it is likely that the marginal utility of avoiding that is significant enough that it will be the tipping point for many websites to make the switch. To see if this is a workable strategy, we should learn whether or not end-user apathy and confusion is so high that we can turn it from a negative into a positive this way. Further, like I said in my previous message, we should be able to do a lot more to ensure that the browser navigates to https:// instead of http:// when https:// is available. This would likely significantly reduce the number of websites for which the negative branding would be shown. Having said all of that, I remember that Mozilla did some user research ~3 years ago that showed that when we show a negative security indicator like the broken lock icon, a significant percentage of users interpreted the problem to lie in the browser, not in the website--i.e. the security problem is Firefox's fault, not their favorite website. It would be important to do research to confirm or (hopefully) refute this finding. I suspect this is still sometimes true. We've been working on the SSL interstitial and people sometimes believe that the fault lies with Chrome (Chrome can't set up a secure connection because of a bug in Chrome...). We've been trying to tweak the wording to avoid this misconception, but we have a lot more space in an interstitial than in the URL bar. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 7/22/2014 11:27 AM, Chris Palmer wrote [in part]: On Tue, Jul 22, 2014 at 10:49 AM, I previously wrote [also in part]: (Your intentionally broken email address suggests that you don't really want to communicate, so mostly this message is directed to the public list subscribers in general.) Someone please explain to me how my non-HTTPS personal Web site at http://www.rossde.com/ creates any risk to visitors. When I post to a newsgroup, yes, I munge my E-mail address. I expect to communicate in a public discussion, not a private exchange of E-mail. My E-mail address, however, can be found in the Organization header field if you view the message source. Also, you can go to my home Web page and select the E-mail link with the envelope graphic near the top of the page; on the resulting Send Me E-Mail Web page, you will see my address in a graphic. All this is to reduce my exposure to spam. I am not the only participant in news.mozilla.org newsgroups who munges his or her E-mail address. -- David E. Ross http://www.rossde.com/ On occasion, I filter and ignore all newsgroup messages posted through GoogleGroups via Google's G2/1.0 user agent because of spam, flames, and trolling from that source. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
[+keeler, +cviecco] On Tue, Jul 22, 2014 at 1:55 PM, Chris Palmer pal...@google.com wrote: On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario hka...@redhat.com wrote: I'm pretty sure Firefox merely remembers your decision to click through the warning, not that it pins the keys/certificates in the chain you clicked through on. No, I'm sure it remembers the certificate. 1. Generate a self-signed cert; configure Apache to use it; restart Apache. 2. Browse to the server with Firefox. Add Exception for the cert. 3. Quit Firefox; restart Firefox; browse to server again. Everything is good. 4. Generate a *new* self-signed cert; configure Apache to use it; restart Apache. 5. Quite Firefox; restart Firefox; browse to server again. Results: A. On first page-load after step (5), no certificate warning. (I assume a cached page was being shown.) B. Reload the page; now I get a cert warning as expected. But, crucially, this not a key pinning validation failure; just an unknown authority error. (Error code: sec_error_untrusted_issuer) Firefox's cert override mechanism uses a different pinning mechanism than the key pinning feature. Basically, Firefox saves a tuple (domain, port, cert fingerprint, isDomainMismatch, isValidityPeriodProblem, isUntrustedIssuer) into a database. When it encounters an untrsuted certificate, it computes that tuple and tries to find a matching one in the database; if so, it allows the connection. C. I do the clicks to Add Exception, but it fails: In the Add Security Exception dialog, the [ ] Permanently store this exception checkbox is grayed out, and the [ Confirm Security Exception ] button is also grayed out. I can only click [ Cancel ]. I take it this is a Firefox UI bug...? Everything was working as I expected except (C). I think the button and the checkbox should be active and should work as normal. It seems like a UI bug to me. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On Tue, Jul 22, 2014 at 2:00 PM, Brian Smith br...@briansmith.org wrote: Firefox's cert override mechanism uses a different pinning mechanism than the key pinning feature. Basically, Firefox saves a tuple (domain, port, cert fingerprint, isDomainMismatch, isValidityPeriodProblem, isUntrustedIssuer) into a database. When it encounters an untrsuted certificate, it computes that tuple and tries to find a matching one in the database; if so, it allows the connection. Interesting! Thanks for the clue. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
- Original Message - From: diaf...@gmail.com To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Monday, 21 July, 2014 4:08:30 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites So the general top criticism I'm seeing to this proposal is that it's too expensive (in both time and money) get an SSL certificate. I'm feeling a general consensus that HTTPS is desired, but it's too difficult to attain for many sysadmins. So what can be done to lower the threshold to get sysadmins to start serving over HTTPS? Allowing self-signed certs is one proposal. What are some others? This is actually what most Linux distributions do by default, so I'd say that any other solutions should be *in addition* to accepting self signed certs. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
Gotta start somewhere. I actually kind of like the idea of showing the current generic icon for self-signed ssl certificates, and the broken lock icon for insecure connections. On Mon, Jul 21, 2014 at 4:10 PM, Adrienne Porter Felt f...@chromium.org wrote: I would very much like to make http sites look insecure. But we face a very real problem: a large fraction of the web is still http-only. That means that: Users will get used to the insecure icon, and it will start looking meaningless pretty quickly. This might also make users ignore the broken https icon. I'm not sure how to reconcile this. On Mon, Jul 21, 2014 at 2:27 PM, 'Chris Palmer' via Security-dev security-...@chromium.org wrote: +security-...@chromium.org I also think it's a good idea to affirmatively label non-secure origins as such, in some way. On Sat, Jul 19, 2014 at 12:10 PM, Eric Mill e...@konklone.com wrote: A good idea, though you need to be careful. Just posted to the bug: What you definitely *don't* want to do is give the user such negative feedback that they stop noticing when there's a direct problem (insecure HTTPS). A grey unlocked padlock would be a nice way to ease people into the idea that they are browsing a normal website that is insecure. On Sat, Jul 19, 2014 at 2:54 PM, Daniel Roesler diaf...@gmail.com wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- konklone.com | @konklone https://twitter.com/konklone ___ 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: Proposal: Switch generic icon to negative feedback for non-https sites
Best case: no one will notice it after the first few days. Worst case: people notice it, and therefore start ignoring all https authentication errors. Is there a way to make the best case better, without ending up at the worst case? At least for Firefox, the gray broken lock icon option is pretty tame[1]. I don't think the worst case is likely with that option since it's not red and scary like all the other https errors. Also, it's just annoying enough to be an eyesore to sysadmins (who might upgrade to https), even if their users tend to ignore it. [1] - https://bugzilla.mozilla.org/attachment.cgi?id=8459203action=edit ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
Not claiming to have the solution at hand, but the best first step might be non-scolding, non-lock-related imagery that clearly and affirmatively gets across that this is a *public* connection. Just brainstorming a bit here: * A charming low-fi icon of the all-seeing eye http://img1.wikia.nocookie.net/__cb20121208115833/deusex/en/images/8/8e/All_seeing_eye.jpg * A tiny tower beaming circular waves (inspired by EFF's Open Wireless https://openwireless.org/ iconography) * If a cartoony spy icon weren't already used for Chrome's Incognito Mode, I'd suggest that * Maybe just an eye (it could blink every 10 minutes, for extra fun) -- Eric On Mon, Jul 21, 2014 at 9:15 PM, Chris Palmer pal...@google.com wrote: On Mon, Jul 21, 2014 at 5:29 PM, 'Michal Zalewski' via Security-dev security-...@chromium.org wrote: The number of security states for the address bar seems to have gotten a bit out of control. Depending on the browser, you will have different indicators for plain HTTP; HTTPS; EV SSL HTTPS; HTTPS with cert errors (often without distinguishing between their severity); HTTPS with passive mixed content; and HTTPS with active mixed content. I'd wager that most people just want to know if the connection can be snooped on or tampered with, a notion only loosely coupled to the use of HTTPS. Since Chrome is already omitting http://; in URLs, maybe we should go all the way through and just provide a simple, two-state indicator for that instead of reshuffling the current UI? I agree, but I think a 3-state solution is warranted (Good, Non-Fatal Problems, Bad). Non-Fatal Problems would include the most minor TLS errors and passive mixed content; Bad would include HTTP. Given that Bad includes HTTP, it might need to be a gentle indicator rather than a burning screaming fire. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- konklone.com | @konklone https://twitter.com/konklone ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 22/07/14 12:58 AM, Brian Smith wrote: On Mon, Jul 21, 2014 at 8:50 PM, Eric Mill e...@konklone.com wrote: Not claiming to have the solution at hand, but the best first step might be non-scolding, non-lock-related imagery that clearly and affirmativ' ely gets across that this is a *public* connection. I think you have the right idea. Keep in mind that browsers reserve a significant amount of space in the address bar for the organization name in an EV certificate. So, we don't have to limit ourselves to the square space that the lock icon occupies. For example, we could replace the globe icon with gray text Not Secure. That would be a clear message for people who looked at it, and it would encourage websites to switch to HTTPS, but it probably wouldn't be overly scary (at least it's not red!). People who object to getting a certificate for their website should be willing to accept browsers saying their non-secure website is not secure. This would be a fantastic improvement. It would make attacks like sslstrip much more obvious to users. Although the lock icon is often interpreted to mean Secure, we know that there are a lot of factors that go into whether a website is secure. But, clearly HTTPS is necessary condition. Thus, it makes sense to say Not Secure for non-HTTPS, but it doesn't make sense to say explicitly Secure for HTTPS. I think the existence of EV certificates is proof that browsers have a lot of power here. Secure should imply perfect forward secrecy, as we're aware that there's mass surveillance of these connections and keys can and will be exposed in the future. Further, this would work better if we stopped cutting off the http://; prefix for non-secure sites, and if browsers made more of an effort to try https:// URIs when the scheme is omitted from a domain name or URL typed (or pasted) into the address bar. Right now, browsers omit the http://; as a hint that it is not necessary to type it in. But, we should make browsers such that it isn't necessary to type in https://; to get the secure variant of a page too, so the current UI doesn't make sense. A good start for this might be building, maintaining, and sharing a list of websites that should default to https:// in the address bar, even if they are not HSTS. This would include, for example, https://www.google.com, https://en.wikipedia.org/, and https://bing.com/. There's a lot of existing work on this: https://www.eff.org/https-everywhere I fully support efforts to make address bar UI changes like this happen. They are overdue; at least, it is unlikely things will change dramatically in the future to make it easier to make changes later than it is to make them now. Cheers, Brian signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
- Original Message - From: David E. Ross nobody@nowhere.invalid To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Sunday, 20 July, 2014 4:39:09 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Your concept would cast a negative shadow over many non-commercial Web sites, blogs, and legitimate freeware sources. Are you willing to pay the cost of site certificates for such sites? How about just the cost of a site certificate for my own site? I have no advertising on my site and thus no revenues to pay for a certificate. Yes, I know there are some certification authorities that issue free certificates. For various reasons, I have marked many of their root certificates as untrusted. I was able to get a certificate for a year for $3 that links up to COMODO CA. That was without any promotions or coupons - regular price. You need to pay few times more for hosting than you need to pay for certificates. Also, while you might have marked them as untrusted, I'm sure that the vast majority (over 99%) of users didn't. Rightfully so. They are not supposed to thwart any and all attacks. They are there so that trivial attacks can't be launched. There are about 1000 CA's that are trusted by Firefox (by linking up to root CA certs or by being in the root store directly), how many of them have you marked as untrustworthy? +1 on the idea of starting treating HTTP as insecure and while we're at it, let's get rid of those warnings about self signed certificates -- they are less insecure than HTTP (Firefox actually uses certificate pinning for sites with previously waived cert problems!) so let's not treat them worse than HTTP connections -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 20/07/14 06:23 AM, Hubert Kario wrote: - Original Message - From: David E. Ross nobody@nowhere.invalid To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Sunday, 20 July, 2014 4:39:09 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-httpssites On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Your concept would cast a negative shadow over many non-commercial Web sites, blogs, and legitimate freeware sources. Are you willing to pay the cost of site certificates for such sites? How about just the cost of a site certificate for my own site? I have no advertising on my site and thus no revenues to pay for a certificate. Yes, I know there are some certification authorities that issue free certificates. For various reasons, I have marked many of their root certificates as untrusted. I was able to get a certificate for a year for $3 that links up to COMODO CA. That was without any promotions or coupons - regular price. You need to pay few times more for hosting than you need to pay for certificates. Also, while you might have marked them as untrusted, I'm sure that the vast majority (over 99%) of users didn't. Rightfully so. They are not supposed to thwart any and all attacks. They are there so that trivial attacks can't be launched. There are about 1000 CA's that are trusted by Firefox (by linking up to root CA certs or by being in the root store directly), how many of them have you marked as untrustworthy? +1 on the idea of starting treating HTTP as insecure and while we're at it, let's get rid of those warnings about self signed certificates -- they are less insecure than HTTP (Firefox actually uses certificate pinning for sites with previously waived cert problems!) so let's not treat them worse than HTTP connections They shouldn't show up with a lock icon, but treating HTTPS connections as less secure than an HTTP connection is counterproductive. Self-signed certificates should still be forbidden with HSTS. It prevents an attacker from using sslstrip, so it should also prevent them from providing their own certificate. The sslstrip technique already prevents HTTPS from having *any* value without basic user education (or HSTS). Looking for a lock icon instead of https:// wouldn't be a big change. In Chromium, the leading http:// is hidden, so they're in the position to start allowing self-signed HTTPS with the leading https:// hidden. It would only be there when copying the URL. http://tools.ietf.org/html/draft-dukhovni-opportunistic-security-00 signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
So the general top criticism I'm seeing to this proposal is that it's too expensive (in both time and money) get an SSL certificate. I'm feeling a general consensus that HTTPS is desired, but it's too difficult to attain for many sysadmins. So what can be done to lower the threshold to get sysadmins to start serving over HTTPS? Allowing self-signed certs is one proposal. What are some others? Could Mozilla start their own root CA and give out SSL certs for free? How about a kickstarter to make a free root CA? Now is the time for creative solutions! And it will likely take pushing from many different fronts to make this happen :) On Sunday, July 20, 2014 10:05:10 AM UTC-7, Daniel Micay wrote: On 20/07/14 06:23 AM, Hubert Kario wrote: - Original Message - From: David E. Ross nobody@nowhere.invalid To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Sunday, 20 July, 2014 4:39:09 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Your concept would cast a negative shadow over many non-commercial Web sites, blogs, and legitimate freeware sources. Are you willing to pay the cost of site certificates for such sites? How about just the cost of a site certificate for my own site? I have no advertising on my site and thus no revenues to pay for a certificate. Yes, I know there are some certification authorities that issue free certificates. For various reasons, I have marked many of their root certificates as untrusted. I was able to get a certificate for a year for $3 that links up to COMODO CA. That was without any promotions or coupons - regular price. You need to pay few times more for hosting than you need to pay for certificates. Also, while you might have marked them as untrusted, I'm sure that the vast majority (over 99%) of users didn't. Rightfully so. They are not supposed to thwart any and all attacks. They are there so that trivial attacks can't be launched. There are about 1000 CA's that are trusted by Firefox (by linking up to root CA certs or by being in the root store directly), how many of them have you marked as untrustworthy? +1 on the idea of starting treating HTTP as insecure and while we're at it, let's get rid of those warnings about self signed certificates -- they are less insecure than HTTP (Firefox actually uses certificate pinning for sites with previously waived cert problems!) so let's not treat them worse than HTTP connections They shouldn't show up with a lock icon, but treating HTTPS connections as less secure than an HTTP connection is counterproductive. Self-signed certificates should still be forbidden with HSTS. It prevents an attacker from using sslstrip, so it should also prevent them from providing their own certificate. The sslstrip technique already prevents HTTPS from having *any* value without basic user education (or HSTS). Looking for a lock icon instead of https:// wouldn't be a big change. In Chromium, the leading http:// is hidden, so they're in the position to start allowing self-signed HTTPS with the leading https:// hidden. It would only be there when copying the URL. http://tools.ietf.org/html/draft-dukhovni-opportunistic-security-00 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Proposal: Switch generic icon to negative feedback for non-https sites
Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Your concept would cast a negative shadow over many non-commercial Web sites, blogs, and legitimate freeware sources. Are you willing to pay the cost of site certificates for such sites? How about just the cost of a site certificate for my own site? I have no advertising on my site and thus no revenues to pay for a certificate. Yes, I know there are some certification authorities that issue free certificates. For various reasons, I have marked many of their root certificates as untrusted. -- David E. Ross http://www.rossde.com/ On occasion, I filter and ignore all newsgroup messages posted through GoogleGroups via Google's G2/1.0 user agent because of spam, flames, and trolling from that source. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
