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
diafygi@gmail.com
0
Daniel
7/19/2014 6:54:18 PM
mozilla.dev.security.policy 1337 articles. 2 followers. Post Follow

27 Replies
515 Views

Similar Articles

[PageSpeed] 45

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
> diafygi@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.
0
David
7/20/2014 2:39:09 AM
----- Original Message -----
> From: "David E. Ross" <nobody@nowhere.invalid>
> To: mozilla-dev-security-policy@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
> > diafygi@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
0
Hubert
7/20/2014 10:23:37 AM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ltt5lwPead79cUI65iC2nhohBk03pdS7d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 20/07/14 06:23 AM, Hubert Kario wrote:
> ----- Original Message -----
>> From: "David E. Ross" <nobody@nowhere.invalid>
>> To: mozilla-dev-security-policy@lists.mozilla.org
>> Sent: Sunday, 20 July, 2014 4:39:09 AM
>> Subject: Re: Proposal: Switch generic icon to negative feedback for no=
n-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=3D1041087
>>>
>>> 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 sessio=
n
>>> 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
>>> diafygi@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 si=
te
>> 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.
>>
>=20
> I was able to get a certificate for a year for $3 that links up to COMO=
DO CA.
> That was without any promotions or coupons - regular price.
>=20
> You need to pay few times more for hosting than you need to pay for
> certificates.
>=20
> 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.
>=20
> 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?
>=20
>=20
> +1 on the idea of starting treating HTTP as insecure
>=20
> and while we're at it, let's get rid of those warnings about self
> signed certificates -- they are less insecure than HTTP (Firefox actual=
ly
> 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


--Ltt5lwPead79cUI65iC2nhohBk03pdS7d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJTy/bGAAoJEPnnEuWa9fIqL90P/2OIBZg2RpWH6VHvYx26jTBN
lS3jK9uWMOzykqhrMLj7HDBjss8KsZPROzNE+PFvEH9Ch7nD6eHakScomeDdhksy
1u+PbXemeo57ksgP3PUmZy7u2IXWlJrYkx2HanAxYBOxWlmpaDdkm5kKCT+9ncV5
yYXyvo6QuypP2r6OGgr5qMHsC1bggeXqj5WOfypVNlPEoxIq2D6gjmoGbeThTB9B
wWIjcsIEjpQevYdmC2YD3KdnaVXleuUxBY/8PmvWW54VgQylk9qcgBxg9cOYxp2W
u3sJTMUvmCiDHENG9jnsr10/pESUwOxpKqu+7EzsyhZBQfhdZnyd72PBUupuWNC7
rIksLtnhJ2UWFUDbCOotsIyRaYjqet7BlxCoQ1n4Djlvv1/2YdGPen6sNM4FPmfz
e0XvrPSga2hiPwAbebvTJF6IXN7NKE1Bgve+4bYAkRHBWW1sgERlRYAw+6R58jwf
Y4yo2xuqDrS3HNB8ig51xV1s29jvD2Yf/8QwhWTyiJs2ylofyy2+IMDPySD+0IOB
W1FxO5/ttgZDibqSqLmfsbwjw8tdBexBmqMde6F6p4dhgSSdJWwNld7NhlsIZ782
JO9sjv0jYVNWN9gLGEX3A6Bj7vdUDxmS+PT/pxWfWrUCBL0bikzoVj+D33HuUKmB
y/VeUrKSy8XaB6S6AaOY
=ntSD
-----END PGP SIGNATURE-----

--Ltt5lwPead79cUI65iC2nhohBk03pdS7d--
0
Daniel
7/20/2014 5:05:10 PM
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-policy@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
> 
> >>> diafygi@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

0
diafygi
7/21/2014 2:08:30 AM
----- Original Message -----
> From: diafygi@gmail.com
> To: mozilla-dev-security-policy@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
0
Hubert
7/21/2014 9:10:32 AM
On Sun, Jul 20, 2014 at 3:23 AM, Hubert Kario <hkario@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 =E2=80=94 will people know how to recover if the key(s) change(s=
)?
0
Chris
7/21/2014 11:08:57 PM
On Sun, Jul 20, 2014 at 7:08 PM,  <diafygi@gmail.com> wrote:

> 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.

https://sslmate.com/
0
Chris
7/21/2014 11:11:07 PM
Another complementary effort could be to ask apache and nginx to start
to use SSL in their example default config.

On Mon, Jul 21, 2014 at 4:11 PM, Chris Palmer <palmer@google.com> wrote:
> On Sun, Jul 20, 2014 at 7:08 PM,  <diafygi@gmail.com> wrote:
>
>> 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.
>
> https://sslmate.com/
0
Daniel
7/21/2014 11:36:54 PM
On Mon, Jul 21, 2014 at 4:36 PM, Daniel Roesler <diafygi@gmail.com> wrote:

> Another complementary effort could be to ask apache and nginx to start
> to use SSL in their example default config.

Including generating a certificate and CSR for each virtual host that
does not yet have a certificate. And warning about sub-optimal
deployments ("Say, looks like you aren't serving the intermediate that
links your end-entity cert to its trust anchor/root... want to fix
that?")

apache security-configtest :)
0
Chris
7/21/2014 11:50:16 PM
----- Original Message -----
> From: "Chris Palmer" <palmer@google.com>
> To: "Hubert Kario" <hkario@redhat.com>
> Cc: "David E. Ross" <nobody@nowhere.invalid>, mozilla-dev-security-policy=
@lists.mozilla.org
> Sent: Tuesday, 22 July, 2014 1:08:57 AM
> Subject: Re: Proposal: Switch generic icon to negative feedback for non-h=
ttps sites
>=20
> On Sun, Jul 20, 2014 at 3:23 AM, Hubert Kario <hkario@redhat.com> wrote:
>=20
> > and while we're at it, let's get rid of those warnings about self
> > signed certificates -- they are less insecure than HTTP (Firefox actual=
ly
> > uses certificate pinning for sites with previously waived cert problems=
!)
> > so let's not treat them worse than HTTP connections
>=20
> 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.
>=20
> Although I have proposed that for certain use-cases, its applicability
> is limited =E2=80=94 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.
--=20
Regards,
Hubert Kario
0
Hubert
7/22/2014 10:01:59 AM
On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario <hkario@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.
>>
>> Although I have proposed that for certain use-cases, its applicability
>> is limited =E2=80=94 will people know how to recover if the key(s) chang=
e(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.

I just ran this test:

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 goo=
d.
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)
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.
0
Chris
7/22/2014 8:55:44 PM
[+keeler, +cviecco]

On Tue, Jul 22, 2014 at 1:55 PM, Chris Palmer <palmer@google.com> wrote:
> On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario <hkario@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
0
Brian
7/22/2014 9:00:57 PM
On Tue, Jul 22, 2014 at 2:00 PM, Brian Smith <brian@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.
0
Chris
7/22/2014 9:04:27 PM
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
> diafygi@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>.
0
David
8/9/2014 11:53:46 PM
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-initiat=
ive-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 system=
s,
>  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 i=
t
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=3DcBhZ6S0PFCY

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.

0
Ryan
8/10/2014 6:52:16 AM
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).

I will say that having more certificates issued appears to at least be a
factor in determining whether or not you get de-trusted as a result of a
breach.  While the difference in behaviour between Comodo and DigiNotar in
response to their respective breaches no doubt played a part in the
different outcomes, there was a *lot* of hand-wringing about how many
end-users would be adversely impacted by de-trusting Comodo roots,
indicating it was a factor in the decision-making process.  

- Matt

0
Matt
8/10/2014 11:06:27 PM
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

0
Matt
8/10/2014 11:09:23 PM
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.

-- 
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>.
0
David
8/11/2014 3:16:42 AM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qJ3wtDtPdbfFfDpbw0iwinf4dWMoOBOxL
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 sit=
e
>>> certificates -- should first read
>>> <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initia=
tive-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 syste=
ms,
>>> 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 com=
puter
>> systems profession (in the very precise definition of "for a livelihoo=
d"),
>> but beyond that, you're drawing an *exceptionally* long bow.
>>
>> - Matt
>>
>=20
> I was a computer systems integrator for over 30 years.  I fully
> understand what "integrator" means.  In my career, sopftware integratio=
n
> often included dealing with secure systems and how they were made secur=
e.
>=20
> 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?
>=20
> 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.


--qJ3wtDtPdbfFfDpbw0iwinf4dWMoOBOxL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJT6EdXAAoJEPnnEuWa9fIqNZ0P/ihBiv72nkCcUyADuBnMW+J1
UmidmM3H9lHwrZVClokkopQmNg8mYrMXandm3Dzw7ujRRooKSPIBMN/hxZ/wKb0B
B4mGAQ5UlkjG3/Hg93Zoorzjv8iXaoSo2gGXi45D/jbamO0aVZ7uv7/N4VWM12Ri
+XgXEk8WrjGofC5B3TH/lU/IJY7fhmc4aQ2v9TUz9AU2esoJtqrEdTR+cP/F2gbV
7Wz8DqV9zWDfhTWZ1OLykC5QpoxPZMNaW9dNRgF+KzABaqQ/ScVFRtkm9POmnbq2
KcxCAOA7XGNXtkaq+ycgc6VYOn+ng9IbpY7PFUWRcEYVrh+yswOiRMEAmSqPdqBJ
8datjU6NO4B/7hcqpLeCKS/VyGgmJZ7HJFkMeKo5hgex8u30hMdGfCmCq1q8FLsx
4qtLp+KHu5WpJzOiTi+fghdjqjyLjV5EgiS8EEnnhUBDXXKYG9iRUVPQMPrNxxlE
vi2mspKDG1KjIXzR37Il+7WFtOV9e5VNLjnuNvx80UIsNo6C9G6/FXccbMDO9b/K
ZyeEMi/gs4CuXOr96NrDUgnjkF5C7SPN4tE5Ci6H1aCmsX3ldYY/CHqJ44EKVUka
TIK6oR1uyohwheUm12g6VUB3pNDq8URGRjpK4AntKL3s/odEUMKeX7Mr70VGLKCT
hgsGecXCR1mPlCWj4Kfx
=Oztf
-----END PGP SIGNATURE-----

--qJ3wtDtPdbfFfDpbw0iwinf4dWMoOBOxL--
0
Daniel
8/11/2014 4:32:10 AM
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-attributa=
ble
> > 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 compromi=
se.
> > Evidence demonstrates the opposite, but either way, they're orthogona=
l
> > issues entirely. Having more certificates issued does not directly ma=
ke
> > 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 *a=
re*
>  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.

0
Ryan
8/11/2014 4:47:04 AM
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 integrati=
on
>  often included dealing with secure systems and how they were made secu=
re.

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 !=3D registration authority. The two are,
unsurprisingly, unrelated concepts.

I say this because my dog could be a reseller, if she was allowed to ente=
r
into legal contracts. That's really the ONLY requirement, at the core, of
a reseller.

0
Ryan
8/11/2014 4:50:28 AM
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

0
Matt
8/11/2014 4:58:41 AM
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>.
0
David
8/11/2014 6:01:44 AM
----- Original Message -----
> From: "David E. Ross" <nobody@nowhere.invalid>
> To: mozilla-dev-security-policy@lists.mozilla.org
> Sent: Monday, August 11, 2014 8:01:44 AM
> Subject: 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.

You mean satellites like those?:
http://arstechnica.com/security/2014/04/mission-critical-satellite-communications-wide-open-to-malicious-hacking/

Working in a business for 10/20/30/90 years doesn't make you an expert
yet alone authority. One year of experience repeated 20 times doesn't make
you even skilled.

Bring arguments to the table and argue arguments, not who they come from.

And the arguments you brought are weak - only TLS can protect against drive
by eavesdropping - think bored kid with Firesheep in St***ucks. Ergo
you should deploy TLS even on your family instance of OwnCloud, let
alone any commercial website.

Properly deployed TLS has minimal impact on servers running current webapps
and is below measurement uncertainty as far as network load goes.
If you want us to have a different opinion, show us that it is not the case.

-- 
Regards,
Hubert Kario
0
Hubert
8/11/2014 10:46:20 AM
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


0
Gervase
8/11/2014 12:10:59 PM
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,
>>=20
>> Yesterday, I created a bug proposing that Firefox switch the generic
>> url icon to a negative feedback icon for non-https sites.
>>=20
>> https://bugzilla.mozilla.org/show_bug.cgi?id=3D1041087
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Thanks and looking forward to any discussion,
>> Daniel Roesler
>> diafygi@gmail.com
>>=20
>=20
> 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.
>=20
> --=20
> David E. Ross
>=20
> 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

0
Richard
8/11/2014 7:02:19 PM
Yes, I started this thread. I officially declare this thread closed...even though I have no ability to enforce it.
0
diafygi
8/12/2014 5:33:44 AM
Reply:

Similar Artilces:

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 o= f=0A= mail from here has been lost, this is a resend of the backlog]=0A= =0A= Chris Palmer <palmer@google.com> writes:=0A= =0A= >Firefox 31 data:=0A= >=0A= >on desktop the median successful OCSP validation took 261ms, and the 95th= =0A= >percentile (looking at just the universe of successful ones) was over 1300= ms.=0A= >9% of all OCSP requests on desktop timed out completely and aren't counted= in=0A= >those numbers.=0A= =0A= Do you have equivalent data for the TL...

Request: Re-open #1041087
I would like to request that Bug #1041087 be re-opened for discussion. https://bugzilla.mozilla.org/show_bug.cgi?id=3D1041087 Much has changed since this bug was closed: 1. CloudFlare started offering free SSL certificates[1]. 2. The EFF, Mozilla, IdenTrust, Akamai, and Cisco will start offering free = SSL certificates[2]. 3. Google is now ranking websites that use https higher[3]. 4. Chrome plans to start marking http as non-secure[4]. 5. Wireless carriers have begun modifying headers in transit[5]. All of these are a fantastic group effort to make the web more secure...

security message("page contains secure and non secure items") coming on https: site
Hi we have developed a site and url of that site begins with https . Now everwhever page loads it gives a security message that " page contains secure and non secure items'. We donot want this message to come on our site. I read a few articles saying that my image should come from relative path or I should use css classes for images or there should not be any http url in my page. I have implemented these solutions also but still my page is giving this security message.   If any body could tell me how to avoid this message.   A lot of thanks in advance..  ...

returning from secure site to non secure site
Hi, I want to return from secure site to non secure site using Response.Redirect method but it stays in secure site dowsn't redirect to non https site. How can I fix this problem, and why it is a problem. Kind regards,Fatih UÇAR To redirect between a SSL site to a non SSL site, you have to specify the full qualified url (including the protocol) as the parameter for response.redirect. For example: Response.Redirect("http://.....") or Response.Redirect("https://.....") Thanks zhuhua for your answer yes I have specified fully qualified name that's why an alert box appears by i...

atlas Hover Menu secure/non-secure warning on HTTPS site on mouseover for popup
I'm getting "This page contains both secure and non secure items.  Do you want to display the non-secure" warning  when I mouseover the linkbutton that launches the popup menu.  It works fine on my http dev server but not, of course, on my production https box.  The interesting thing is the popup works fine  regardless of whether you click yes, no, or cancel and it only prompts once for that page - all the popup menus (I have multiple) work fine after that on the same page. I've built in a little preference toggle so my peeps can turn it off, but do you at...

superreview cancelled: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 201824] patch v2
Kai Engert <kaie.bugs@gmail.com> has cancelled Gavin Sharp <gavin.sharp@gmail.com>'s request for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering https://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 201824: patch v2 https://bugzilla.mozilla.org/attachment.cgi?id=201824&action=edit ------- Additional Comments from Kai Engert <kaie.bugs@gmail.com> I'm rejecing this patch for now, because we don't have a wording agreement yet. While the patch is fine for simple wording, we'd have to...

superreview granted: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 202857] patch v3
Daniel Veditz <dveditz@cruzio.com> has granted Gavin Sharp <gavin.sharp@gmail.com>'s request for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering https://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 202857: patch v3 https://bugzilla.mozilla.org/attachment.cgi?id=202857&action=edit ------- Additional Comments from Daniel Veditz <dveditz@cruzio.com> sr=dveditz ...

superreview cancelled: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 153847] Patch v1
neil@parkwaycc.co.uk <neil.parkwaycc.co.uk@myrealbox.com> has cancelled Chris Thomas <cst@andrew.cmu.edu>'s request for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering http://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 153847: Patch v1 http://bugzilla.mozilla.org/attachment.cgi?id=153847&action=edit ------- Additional Comments from neil@parkwaycc.co.uk <neil.parkwaycc.co.uk@myrealbox.com> Personally I think a better place to fix this would be in nsNSSCallbacks.cpp, because otherwise you&#...

superreview requested: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 153847] Patch v1
Chris Thomas <cst@andrew.cmu.edu> has asked neil@parkwaycc.co.uk <neil.parkwaycc.co.uk@myrealbox.com> for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering http://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 153847: Patch v1 http://bugzilla.mozilla.org/attachment.cgi?id=153847&action=edit ...

superreview requested: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 201824] patch v2
Gavin Sharp <gavin.sharp@gmail.com> has asked Daniel Veditz <dveditz@cruzio.com> for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering https://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 201824: patch v2 https://bugzilla.mozilla.org/attachment.cgi?id=201824&action=edit ------- Additional Comments from Gavin Sharp <gavin.sharp@gmail.com> I chose simply "Contains unsigned content" for now to fit in with the current "secure" tooltip. I think that if the wording needs revisiting ...

superreview requested: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 202857] patch v3
Gavin Sharp <gavin.sharp@gmail.com> has asked Daniel Veditz <dveditz@cruzio.com> for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering https://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 202857: patch v3 https://bugzilla.mozilla.org/attachment.cgi?id=202857&action=edit ------- Additional Comments from Gavin Sharp <gavin.sharp@gmail.com> Here's the same patch as v2, with "Warning: Contains unauthenticated content" instead of "Contains unsigned content." per Nelson and Mike...

superreview requested: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 202995] patch v3 addition
Kai Engert (kaie) <kengert@redhat.com> has asked Daniel Veditz <dveditz@cruzio.com> for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering https://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 202995: patch v3 addition - to achieve wording consistency https://bugzilla.mozilla.org/attachment.cgi?id=202995&action=edit ...

superreview granted: [Bug 251123] HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering : [Attachment 202995] patch v3 addition
Daniel Veditz <dveditz@cruzio.com> has granted Kai Engert (kaie) <kengert@redhat.com>'s request for superreview: Bug 251123: HTTPS lock icon does not explain mixed secure/non-encrypted icon when hovering https://bugzilla.mozilla.org/show_bug.cgi?id=251123 Attachment 202995: patch v3 addition - to achieve wording consistency https://bugzilla.mozilla.org/attachment.cgi?id=202995&action=edit ------- Additional Comments from Daniel Veditz <dveditz@cruzio.com> sr=dveditz ...

Why not DNS records Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure
There's a lot of lists on CC here - I've pruned them to bcc, and left the discussion for https://groups.google.com/a/chromium.org/forum/#!forum/security-dev . This is also no longer related to the proposal at hand - which was marking HTTP as not secure. Finally, apologies for the length. You asked for a detailed response, and here it is. I suppose at some point we need to write a FAQ on why DNS is often the problem, and not the solution. TL;DR: 1) DNS without DNSSEC is insecure in the face of a network attacker (which we presume we're dealing with) 2) Using plainte...

Web resources about - Proposal: Switch generic icon to negative feedback for non-https sites - mozilla.dev.security.policy

Resources last updated: 1/11/2016 11:30:31 PM