[gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Mark Knecht]

On Thu, Feb 23, 2012 at 2:43 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Thu, Feb 23, 2012 at 4:21 PM, Willie WY Wong <wongwwy@member.ams.org> wrote:
>> Actually, why is it that upstream does not provide 64bit binaries? (It
>> always bothers me to see my wife's Windows 7 machines running a copy
>> of firefox marked, in parenthesis, 32 bit.)
>
> They're working on it... They actually have started generating 64-bit
> nightly builds for Windows and Linux:
> https://nightly.mozilla.org/

What is it about my systems wherein every one of these https links
case my systems to barf with a "This Connection is Untrusted" message.
If I remove the 's' then things work fine.

Is there some part of Gentoo config that should take care of this but
that I don't know about?

- Mark

[gentoo-user] Re: This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 24/02/12 00:59, Mark Knecht wrote:
> On Thu, Feb 23, 2012 at 2:43 PM, Paul Hartman
> <paul.hartman+gentoo@gmail.com>  wrote:
>> On Thu, Feb 23, 2012 at 4:21 PM, Willie WY Wong<wongwwy@member.ams.org>  wrote:
>>> Actually, why is it that upstream does not provide 64bit binaries? (It
>>> always bothers me to see my wife's Windows 7 machines running a copy
>>> of firefox marked, in parenthesis, 32 bit.)
>>
>> They're working on it... They actually have started generating 64-bit
>> nightly builds for Windows and Linux:
>> https://nightly.mozilla.org/
>
> What is it about my systems wherein every one of these https links
> case my systems to barf with a "This Connection is Untrusted" message.
> If I remove the 's' then things work fine.
>
> Is there some part of Gentoo config that should take care of this but
> that I don't know about?

Nope, you can't do anything about that.  The warning appears because 
Mozilla is using a certificate that was issued for "www.mozilla.org" and 
"mozilla.org", but the actual domain is "nightly.mozilla.org".  You 
always get a warning when that happens.

HTTP does not use encryption and certificates, so in that case you will 
never get anything like that.

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Paul Hartman]

On Thu, Feb 23, 2012 at 4:59 PM, Mark Knecht <markknecht@gmail.com> wrote:
> What is it about my systems wherein every one of these https links
> case my systems to barf with a "This Connection is Untrusted" message.
> If I remove the 's' then things work fine.

https encompasses two basic functions: encryption and trust.

In this case the hostname in the SSL certificate installed on that
server does not match the hostname in the URL, so it does not trust
it. If they matched, it would then check to see if it was expired. If
it was not expired, it would then check to see if it was signed by a
CA that you trust (browsers come with a set of trusted CAs already).
If it was self-signed or signed by an untrusted CA (like DigiNotar...)
you'd get a warning as well.

If literally every https link is untrusted, maybe you have an issue
with the installation of certificates on your system, or have chosen
not to trust any CAs.

Commercial websites, banks, stores, etc. should always have valid and
trusted certificates. In OSS world, most people don't have the need or
money to pay for a certificate when all they're really interested in
is encrypting the connection. There are also servers that are
listening for https connections but aren't advertised as such... the
mozilla website is probably one of those. Using plug-ins like
HTTPS-everywhere will try to use https even on sites that don't use it
by default.

In all of those cases above, if you allowed the connection it would
still be SSL encrypted. You'd be protected against packet sniffers but
not against man-in-the-middle attack. By switching to http your
session occurs in plain-text and is vulnerable to both attacks.

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Mark Knecht]

On Thu, Feb 23, 2012 at 3:28 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Thu, Feb 23, 2012 at 4:59 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> What is it about my systems wherein every one of these https links
>> case my systems to barf with a "This Connection is Untrusted" message.
>> If I remove the 's' then things work fine.
>
> https encompasses two basic functions: encryption and trust.
>
> In this case the hostname in the SSL certificate installed on that
> server does not match the hostname in the URL, so it does not trust
> it. If they matched, it would then check to see if it was expired. If
> it was not expired, it would then check to see if it was signed by a
> CA that you trust (browsers come with a set of trusted CAs already).
> If it was self-signed or signed by an untrusted CA (like DigiNotar...)
> you'd get a warning as well.
>
> If literally every https link is untrusted, maybe you have an issue
> with the installation of certificates on your system, or have chosen
> not to trust any CAs.
>
> Commercial websites, banks, stores, etc. should always have valid and
> trusted certificates. In OSS world, most people don't have the need or
> money to pay for a certificate when all they're really interested in
> is encrypting the connection. There are also servers that are
> listening for https connections but aren't advertised as such... the
> mozilla website is probably one of those. Using plug-ins like
> HTTPS-everywhere will try to use https even on sites that don't use it
> by default.
>
> In all of those cases above, if you allowed the connection it would
> still be SSL encrypted. You'd be protected against packet sniffers but
> not against man-in-the-middle attack. By switching to http your
> session occurs in plain-text and is vulnerable to both attacks.
>

OK, clearly I'm overstating the problem then. I haven't ever had any
problems logging into password protected, little closed lock in the
bottom corner web sites so that's not a problem. The real problem I've
noticed the most is just with these links that arrive as https:// type
links and Firefox asking me to specifically accept these certificates
which I don't really want to do.

And I've not had any problems I've noticed by just removing the 's'
and using the site like a regular site.

So, I guess there really isn't any problem with my system.

I appreciate the info folks. As always, thanks!

Cheers,
Mark

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Adam Carter]

>> In all of those cases above, if you allowed the connection it would
>> still be SSL encrypted. You'd be protected against packet sniffers but
>> not against man-in-the-middle attack.

And the reason someone will man-in-the-middle you, is so they can
sniff your traffic and get passwords or other sensitive information.
This is done by terminating the SSL session from you, and then
creating a new SSL session to the real server.

>> By switching to http your
>> session occurs in plain-text and is vulnerable to both attacks.
>>
>
> OK, clearly I'm overstating the problem then. I haven't ever had any
> problems logging into password protected, little closed lock in the
> bottom corner web sites so that's not a problem. The real problem I've
> noticed the most is just with these links that arrive as https:// type
> links and Firefox asking me to specifically accept these certificates
> which I don't really want to do.

Is the problem that accepting the certificate is inconvenient?

> And I've not had any problems I've noticed by just removing the 's'
> and using the site like a regular site.

That's ok if you understand that you're turning off the security
features, so it will be possible for an attacker to see your traffic.

> So, I guess there really isn't any problem with my system.

Correct - the problem is on the server that you're connecting to is
presenting an untrusted certificate. That could be because its a
server that's impersonating the server you really want to connect to,
or the server's administrator is not doing their job. In rare cases it
could also be that the certificate has been revoked or the CA is no
longer trusted by your web browser (eg the Diginotar mentioned
earlier).

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

Am 24.02.2012 04:01, schrieb Adam Carter:
>>> In all of those cases above, if you allowed the connection it would
>>> still be SSL encrypted. You'd be protected against packet sniffers but
>>> not against man-in-the-middle attack.
> 
> And the reason someone will man-in-the-middle you, is so they can
> sniff your traffic and get passwords or other sensitive information.
> This is done by terminating the SSL session from you, and then
> creating a new SSL session to the real server.
> 
>>> By switching to http your
>>> session occurs in plain-text and is vulnerable to both attacks.
>>>
>>
>> OK, clearly I'm overstating the problem then. I haven't ever had any
>> problems logging into password protected, little closed lock in the
>> bottom corner web sites so that's not a problem. The real problem I've
>> noticed the most is just with these links that arrive as https:// type
>> links and Firefox asking me to specifically accept these certificates
>> which I don't really want to do.
> 
> Is the problem that accepting the certificate is inconvenient?
> 
>> And I've not had any problems I've noticed by just removing the 's'
>> and using the site like a regular site.
> 
> That's ok if you understand that you're turning off the security
> features, so it will be possible for an attacker to see your traffic.
> 
>> So, I guess there really isn't any problem with my system.
> 
> Correct - the problem is on the server that you're connecting to is
> presenting an untrusted certificate. That could be because its a
> server that's impersonating the server you really want to connect to,
> or the server's administrator is not doing their job. In rare cases it
> could also be that the certificate has been revoked or the CA is no
> longer trusted by your web browser (eg the Diginotar mentioned
> earlier).
> 

Let's not forget that whenever you are presented with that warning, it
could also be a man-in-the-middle attack. Therefore just clicking on
"Accept" on every site is about the stupidest thing you can do.

I'm unsure how the warning looks when you have previously accepted a
normally untrusted certificate on that site and now it is different
(which could be an indication of MITM). I hope there is a big red flashy
warning but I doubt it.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Michael Orlitzky]

On 02/24/12 02:45, Florian Philipp wrote:
> 
> Let's not forget that whenever you are presented with that warning, it
> could also be a man-in-the-middle attack. Therefore just clicking on
> "Accept" on every site is about the stupidest thing you can do.
> 
> I'm unsure how the warning looks when you have previously accepted a
> normally untrusted certificate on that site and now it is different
> (which could be an indication of MITM). I hope there is a big red flashy
> warning but I doubt it.
> 

Not if the certificate is "valid."

The only sane way to handle certificates with parties you've never met
(i.e. every website) is the SSH method: you accept that, no matter what,
there's always going to be one opportunity for a man-in-the-middle
attack. The first time you connect, you save the remote server's
certificate. If it changes, freak out.

The certificate patrol extension does this:

  http://patrol.psyced.org/

With it, self-signed certificates become more secure than CA-signed ones.

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Paul Hartman]

On Fri, Feb 24, 2012 at 10:43 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 02/24/12 02:45, Florian Philipp wrote:
>>
>> Let's not forget that whenever you are presented with that warning, it
>> could also be a man-in-the-middle attack. Therefore just clicking on
>> "Accept" on every site is about the stupidest thing you can do.
>>
>> I'm unsure how the warning looks when you have previously accepted a
>> normally untrusted certificate on that site and now it is different
>> (which could be an indication of MITM). I hope there is a big red flashy
>> warning but I doubt it.
>>
>
> Not if the certificate is "valid."
>
> The only sane way to handle certificates with parties you've never met
> (i.e. every website) is the SSH method: you accept that, no matter what,
> there's always going to be one opportunity for a man-in-the-middle
> attack. The first time you connect, you save the remote server's
> certificate. If it changes, freak out.
>
> The certificate patrol extension does this:
>
>  http://patrol.psyced.org/
>
> With it, self-signed certificates become more secure than CA-signed ones.

Thanks for the link. The MultiZilla extension way back in the
Netscape/Mozilla/Seamonkey 1.x days treated certificates like this:
you had to approve all certs the first time, even if they were from a
trusted CA and if it ever changed for any reason, it would refuse to
connect unless you approved the new cert.

It seems to me that's how it should *always* work, in all software
that uses SSL certificates, but I understand wanting to keep it simple
for non-technical users... but those are the very users most at risk,
probably the most likely to use hostile wifi networks (in my mind,
hostile is anything other than the router I control at my house).

Additionally http://perspectives-project.org/ or
http://convergence.io/ can help you in establishing the initial trust
and are an attempt at eliminating the need to trust CAs at all.

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

Am 24.02.2012 18:33, schrieb Paul Hartman:
> On Fri, Feb 24, 2012 at 10:43 AM, Michael Orlitzky <michael@orlitzky.com> wrote:
>> On 02/24/12 02:45, Florian Philipp wrote:
>>>
>>> Let's not forget that whenever you are presented with that warning, it
>>> could also be a man-in-the-middle attack. Therefore just clicking on
>>> "Accept" on every site is about the stupidest thing you can do.
>>>
>>> I'm unsure how the warning looks when you have previously accepted a
>>> normally untrusted certificate on that site and now it is different
>>> (which could be an indication of MITM). I hope there is a big red flashy
>>> warning but I doubt it.
>>>
>>
>> Not if the certificate is "valid."
>>
>> The only sane way to handle certificates with parties you've never met
>> (i.e. every website) is the SSH method: you accept that, no matter what,
>> there's always going to be one opportunity for a man-in-the-middle
>> attack. The first time you connect, you save the remote server's
>> certificate. If it changes, freak out.
>>
>> The certificate patrol extension does this:
>>
>>  http://patrol.psyced.org/
>>
>> With it, self-signed certificates become more secure than CA-signed ones.
> 
> Thanks for the link. The MultiZilla extension way back in the
> Netscape/Mozilla/Seamonkey 1.x days treated certificates like this:
> you had to approve all certs the first time, even if they were from a
> trusted CA and if it ever changed for any reason, it would refuse to
> connect unless you approved the new cert.
> 
> It seems to me that's how it should *always* work, in all software
> that uses SSL certificates, but I understand wanting to keep it simple
> for non-technical users... but those are the very users most at risk,
> probably the most likely to use hostile wifi networks (in my mind,
> hostile is anything other than the router I control at my house).
> 
> Additionally http://perspectives-project.org/ or
> http://convergence.io/ can help you in establishing the initial trust
> and are an attempt at eliminating the need to trust CAs at all.
> 


Just a small follow-up: A neat server-sided trick I didn't know until
now is HTTP Strict Transport Security [1]. It prevents users from
clicking away SSL warnings and prevents mixed content.

[1] http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Michael Orlitzky]

On 02/27/12 13:43, Florian Philipp wrote:
> 
> Just a small follow-up: A neat server-sided trick I didn't know until
> now is HTTP Strict Transport Security [1]. It prevents users from
> clicking away SSL warnings and prevents mixed content.
> 
> [1] http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
> 
> Regards,
> Florian Philipp

This is nice, although, as with all nice things, it doesn't work in
Internet Explorer.

We try to hack together the same effect using Apache's mod_rewrite and
redirects, but it's hard to get right. Most off-the-shelf web apps (e.g.
Wordpress) do their best to thwart you.

Re: [gentoo-user] This Connection is Untrusted: WAS: Firefox-10.0.1 fails to compile on x86

[Willie WY Wong]

On Thu, Feb 23, 2012 at 02:59:31PM -0800, Penguin Lover Mark Knecht squawked:
> > They're working on it... They actually have started generating 64-bit
> > nightly builds for Windows and Linux:
> > https://nightly.mozilla.org/
> 
> What is it about my systems wherein every one of these https links
> case my systems to barf with a "This Connection is Untrusted" message.
> If I remove the 's' then things work fine.

Every https link, or just some (such as nightly.mozilla.org)? 
If the former, you may have some problem with your certificates
(app-misc/ca-certificates). 

W
-- 
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton