Yesterday I noticed that I was unable to load http://www.osgeo.org
But I checked http://downforeveryoneorjustme.com/osgeo.org and it was fine.
Today I still cannot connect to osgeo.org
Do others have this issue?? (maybe I'm on the unlucky slice of the internet backbone on the Atlantic)
If so, can someone tackle?
-jeff
2015-06-02 13:43 GMT+02:00 Jeff McKenna <jmckenna@gatewaygeomatics.com>:
Yesterday I noticed that I was unable to load http://www.osgeo.org
But I checked http://downforeveryoneorjustme.com/osgeo.org and it was fine.
Today I still cannot connect to osgeo.org
Do others have this issue?? (maybe I'm on the unlucky slice of the internet
backbone on the Atlantic)If so, can someone tackle?
-jeff
I've been experiencing that problem "Too many redirects", at least on
Chrome, I changed to another browser and it worked. I also asked
others and they weren't having this issue so I assumed was something
with my browser.
--
Jorge Sanz
http://www.osgeo.org
http://wiki.osgeo.org/wiki/Jorge_Sanz
GPG: 86F8 3EA0 BD19 0CA2 801D 4FB2 6B45 68E4 6FB2 D89D
On Tue, Jun 02, 2015 at 08:43:34AM -0300, Jeff McKenna wrote:
Do others have this issue?? (maybe I'm on the unlucky slice of the internet
backbone on the Atlantic)
I confirm failure to connect with HTTP*S* - same symptom as on the
Wiki. Apparently the occasional switch from unencrypted to encrypted
HTTP in Drupal as well as MediaWiki doesn't work with the latest
security features enabled. Therefore I disabled one of these features
and now my browser connects with and without SSL.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On 2015-06-02 8:50 AM, Jorge Sanz wrote:
2015-06-02 13:43 GMT+02:00 Jeff McKenna <jmckenna@gatewaygeomatics.com>:
Yesterday I noticed that I was unable to load http://www.osgeo.org
But I checked http://downforeveryoneorjustme.com/osgeo.org and it was fine.
Today I still cannot connect to osgeo.org
Do others have this issue?? (maybe I'm on the unlucky slice of the internet
backbone on the Atlantic)If so, can someone tackle?
-jeff
I've been experiencing that problem "Too many redirects", at least on
Chrome, I changed to another browser and it worked. I also asked
others and they weren't having this issue so I assumed was something
with my browser.
hmm good point. Safari works for me but not Chrome or FF. I'm not sure why....
-jeff
Hi SAC, following Jeff’s instructions I send this message to the list, maybe it’s nothing but maybe not.
Jorge Sanz
Sent from my phone, excuse my brevity.
---------- Mensaje reenviado ----------
De: “Jorge Sanz” <jsanz@osgeo.org>
Fecha: 04/06/2015 12:01
Asunto: Re: [SAC] osgeo.org problems
Para: “Alex Mandel” <tech@wildintellect.com>, “Jeff McKenna” <jmckenna@gatewaygeomatics.com>
Cc:
2015-06-02 13:57 GMT+02:00 Jeff McKenna <jmckenna@gatewaygeomatics.com>:
On 2015-06-02 8:50 AM, Jorge Sanz wrote:
2015-06-02 13:43 GMT+02:00 Jeff McKenna <jmckenna@gatewaygeomatics.com>:
Yesterday I noticed that I was unable to load http://www.osgeo.org
But I checked http://downforeveryoneorjustme.com/osgeo.org and it was
fine.Today I still cannot connect to osgeo.org
Do others have this issue?? (maybe I’m on the unlucky slice of the
internet
backbone on the Atlantic)If so, can someone tackle?
-jeff
I’ve been experiencing that problem “Too many redirects”, at least on
Chrome, I changed to another browser and it worked. I also asked
others and they weren’t having this issue so I assumed was something
with my browser.hmm good point. Safari works for me but not Chrome or FF. I’m not sure
why…-jeff
Jeff, Alex, I was going to send this to SAC but I’m not sure to make
this public, you’ll better know what to do with this information,
maybe it’s nothing but I’m a little bit alarmed, yes. At this time I
can only access the website as a logged user and only to admin pages,
normal node pages have the redirect loop problem. I tried this on
Chrome, Firefox and Safari.
Best
Jorge
Hi,
I’ve just removed a bunch o pages from the website. They had php code
tags with non sense code to me and were created by the admin user
along with a content type (see screenshot).
I’ve disabled the PHP input format and have no idea if this is related
with the redirects loop event but certainly I’m worried.
Has anyone created this content type and entries?
–
Jorge Sanz
http://www.osgeo.org
http://wiki.osgeo.org/wiki/Jorge_Sanz
GPG: 86F8 3EA0 BD19 0CA2 801D 4FB2 6B45 68E4 6FB2 D89D
Hi Jorge,
On Thu, Jun 04, 2015 at 02:50:09PM +0200, Jorge Sanz wrote:
Jeff, Alex, I was going to send this to SAC but I'm not sure to make
this public, you'll better know what to do with this information,
maybe it's nothing but I'm a little bit alarmed, yes. At this time I
can only access the website as a logged user and only to admin pages,
normal node pages have the redirect loop problem. I tried this on
Chrome, Firefox and Safari.
Note that I don't distrust your expertise, but unfortunately this is
difficult to reproduce. Maybe we need to compile a list of browsers
and platforms in order to find out which ones are ok and which ones
don't. Let me have a simple start:
***** worksforme (HTTP and HTTPS, anonymous and logged in) *****
Firefox 38 on FreeBSD 10
Firefox 31 on Mac OS X 10.10
Safari 8 on Mac OS X 10.10
***** failed to connect *****
<add yours>
Are you sure you checked *after* Tue, 2 Jun 2015 ?
I've just removed a bunch o pages from the website. They had php code
tags with non sense code to me and were created by the admin user
along with a content type (see screenshot).I've disabled the PHP input format and have no idea if this is related
with the redirects loop event but certainly I'm worried.Has anyone created this content type and entries?
No idea, but I'm aware that the main web site is in bad state: We're
using Drupal and PHP versions which are known to be unsafe. We can't
update PHP because the site is using custom PHP code for the service
providers inventory which fails on modern PHP versions and, on the
other hand, we can't update Drupal because it would require a modern
PHP version.
Thus, by upgrading PHP we'll break the service providers, by updating
Drupal we'll break most of the site. Updating PHP *and* Drupal (which
would be essential from a security point of view) is guaranteed to
break everything 
As far as I understand the most advisable approach to escape this lock
is to find a maintainer for the service providers PHP code.
Best regards,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On 6/4/2015 5:07 PM, Martin Spott wrote:
Hi Jorge,
On Thu, Jun 04, 2015 at 02:50:09PM +0200, Jorge Sanz wrote:
Jeff, Alex, I was going to send this to SAC but I'm not sure to make
this public, you'll better know what to do with this information,
maybe it's nothing but I'm a little bit alarmed, yes. At this time I
can only access the website as a logged user and only to admin pages,
normal node pages have the redirect loop problem. I tried this on
Chrome, Firefox and Safari.Note that I don't distrust your expertise, but unfortunately this is
difficult to reproduce. Maybe we need to compile a list of browsers
and platforms in order to find out which ones are ok and which ones
don't. Let me have a simple start:***** worksforme (HTTP and HTTPS, anonymous and logged in) *****
Firefox 38 on FreeBSD 10
Firefox 31 on Mac OS X 10.10
Safari 8 on Mac OS X 10.10***** failed to connect *****
<add yours>Are you sure you checked *after* Tue, 2 Jun 2015 ?
I've just removed a bunch o pages from the website. They had php code
tags with non sense code to me and were created by the admin user
along with a content type (see screenshot).I've disabled the PHP input format and have no idea if this is related
with the redirects loop event but certainly I'm worried.Has anyone created this content type and entries?
No idea, but I'm aware that the main web site is in bad state: We're
using Drupal and PHP versions which are known to be unsafe. We can't
update PHP because the site is using custom PHP code for the service
providers inventory which fails on modern PHP versions and, on the
other hand, we can't update Drupal because it would require a modern
PHP version.Thus, by upgrading PHP we'll break the service providers, by updating
Drupal we'll break most of the site. Updating PHP *and* Drupal (which
would be essential from a security point of view) is guaranteed to
break everything
As far as I understand the most advisable approach to escape this lock
is to find a maintainer for the service providers PHP code.
Is there a copy of the existing code posted somewhere people could take a look at?
--- Harrison
On Thu, Jun 04, 2015 at 05:31:07PM -0500, Harrison Grundy wrote:
Is there a copy of the existing code posted somewhere people could take a
look at?
As far as I can tell, the code is stored in one or more database
fields, but I don't know how to get it out there or how it got in,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On 6/4/2015 11:50 PM, Martin Spott wrote:
On Thu, Jun 04, 2015 at 05:31:07PM -0500, Harrison Grundy wrote:
Is there a copy of the existing code posted somewhere people could take a
look at?As far as I can tell, the code is stored in one or more database
fields, but I don't know how to get it out there or how it got in,Martin.
Ouch. Is there a description somewhere of what it does?
--- Harrison
2015-06-05 0:07 GMT+02:00 Martin Spott <Martin.Spott@mgras.net>:
Hi Jorge,
On Thu, Jun 04, 2015 at 02:50:09PM +0200, Jorge Sanz wrote:
Jeff, Alex, I was going to send this to SAC but I'm not sure to make
this public, you'll better know what to do with this information,
maybe it's nothing but I'm a little bit alarmed, yes. At this time I
can only access the website as a logged user and only to admin pages,
normal node pages have the redirect loop problem. I tried this on
Chrome, Firefox and Safari.Note that I don't distrust your expertise, but unfortunately this is
difficult to reproduce. Maybe we need to compile a list of browsers
and platforms in order to find out which ones are ok and which ones
don't. Let me have a simple start:***** worksforme (HTTP and HTTPS, anonymous and logged in) *****
Firefox 38 on FreeBSD 10
Firefox 31 on Mac OS X 10.10
Safari 8 on Mac OS X 10.10***** failed to connect *****
<add yours>Are you sure you checked *after* Tue, 2 Jun 2015 ?
I have in front of me a Linux and an OSX and it works on the first but
it fails (both in normal and private modes) on the second.
https://dl.pushbulletusercontent.com/hN3ZePbY6S3lGAUphXW4xYRKvwhvFWCp/WtNCKhL.png
What I've find out on firefox is that it works on privacy mode but on
normal mode, even if I clean the cookies, it enters the loop and the
cookie is there again.
Anyway, if it's just me I don't mind of course.
Best
--
Jorge Sanz
http://www.osgeo.org
http://wiki.osgeo.org/wiki/Jorge_Sanz
GPG: 86F8 3EA0 BD19 0CA2 801D 4FB2 6B45 68E4 6FB2 D89D
On 2015-06-05 4:43 AM, Jorge Sanz wrote:
I have in front of me a Linux and an OSX and it works on the first but
it fails (both in normal and private modes) on the second.https://dl.pushbulletusercontent.com/hN3ZePbY6S3lGAUphXW4xYRKvwhvFWCp/WtNCKhL.png
What I've find out on firefox is that it works on privacy mode but on
normal mode, even if I clean the cookies, it enters the loop and the
cookie is there again.Anyway, if it's just me I don't mind of course.
Best
I confirm problems loading osgeo.org in Firefox. I believe it is a serious problem.
-jeff
On Fri, Jun 5, 2015 at 1:52 PM, Jeff McKenna
<jmckenna@gatewaygeomatics.com> wrote:
I confirm problems loading osgeo.org in Firefox. I believe it is a serious
problem.
I made a fest tests this morning:
- Android 4: ok
- Chromium 40/Fedora21: ok
- Firefox 38/Fedora21: failure
So, FF issue confirmed also here.
Markus
On Fri, Jun 05, 2015 at 02:18:13PM +0200, Markus Neteler wrote:
- Firefox 38/Fedora21: failure
So, FF issue confirmed also here.
Ouch - same version of Firefox on a different platform was fine ....
A few days ago I disabled a config change for OSGeo Drupal which
required the Apache "headers" module as a pre-requisite, but apparently
the issue still persists. Now I've disabled the module itself - so
could you please check again ?
Thanks,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Sun, Jun 07, 2015 at 05:44:18PM +0200, Martin Spott wrote:
Ouch - same version of Firefox on a different platform was fine ....
Norman says he's still having issues with Firefox 38.0.5 on OSX 10.8, I
just updated my Firefox to 38.0.5 as well and it's fine on OSX 10.10.3
(Safari 8.0.6 on the same system is ok as well).
The only remaining changes affect the selection of HTTPS protocols and
ciphers:
SSLCipherSuite "<a very large string>"
SSLHonorCipherOrder On
SSLProtocol all -SSLv2 -SSLv3
SSLInsecureRenegotiation Off (which is already off by default)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
2015-06-07 18:21 GMT+02:00 Martin Spott <Martin.Spott@mgras.net>:
On Sun, Jun 07, 2015 at 05:44:18PM +0200, Martin Spott wrote:
Ouch - same version of Firefox on a different platform was fine ....
Norman says he's still having issues with Firefox 38.0.5 on OSX 10.8, I
just updated my Firefox to 38.0.5 as well and it's fine on OSX 10.10.3
(Safari 8.0.6 on the same system is ok as well).The only remaining changes affect the selection of HTTPS protocols and
ciphers:SSLCipherSuite "<a very large string>"
SSLHonorCipherOrder On
SSLProtocol all -SSLv2 -SSLv3
SSLInsecureRenegotiation Off (which is already off by default)
Still having the same behaviour: working fine on my linux workstation
and failing on this OSX 10.10.3 and Chrome 43, Firefox 38.0.5 and
Safari 8.0.6
Best
--
Jorge Sanz
http://www.osgeo.org
http://wiki.osgeo.org/wiki/Jorge_Sanz
GPG: 86F8 3EA0 BD19 0CA2 801D 4FB2 6B45 68E4 6FB2 D89D
Hi,
right now I tried to connect to www.osgeo.org with Firefox 39.0.3 on Fedora 21:
- http://www.osgeo.org --> "Waiting.." forever
- https://www.osgeo.org -->
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for
this address in a way that will never complete.
--> while it is then on https://www.osgeo.org/home
Perhaps an indication of the true problem?
Markus
On 15-08-15 12:14, Markus Neteler wrote:
Hi,
right now I tried to connect to www.osgeo.org with Firefox 39.0.3 on Fedora 21:
- http://www.osgeo.org --> "Waiting.." forever
- https://www.osgeo.org -->
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for
this address in a way that will never complete.
--> while it is then on https://www.osgeo.org/homePerhaps an indication of the true problem?
I think I found the crux (have had that with qgis.org too, but used
another workaround).
Issuing the url's using curl ( -L to see the headers -v to see verbose),
and googling for Firefox issues, I found [0] an answer:
"Are there any parts of your site where you use HTTPS? Sometimes an
administrative page will send Firefox a header indicating that it must
always use HTTPS ("Strict Transport Security"), and that is remembered
for the entire domain, even for pages that should not use HTTPS."
Looking into some https url's it seems that mailman on osgeo.org has
this Strict-Transport-Security header (more about it: [1] and [2]
$ curl -vL https://lists.osgeo.org/mailman/listinfo/qgis-developer
* Trying 140.211.15.134...
...
< Cache-control: no-cache
< Strict-Transport-Security: max-age=15768000
< Vary: Accept-Encoding
...
(probably there are more places)
So apparently you and I have visited https parts of osgeo.org and hit
the Strict-Transport-Security header, which is remembered.
To confirm this theory I try to open https://www.osgeo.org in a 'private
window' of firefox (no history, cookies etc), and that just works!
But I'm afraid there is not a proper solution...
- we can either remove the HTTP_Strict_Transport_Security header from
our servers (but hey, that is there for a reason)
- we can serve osgeo.org ALL over https
Other ideas?
Regards,
Richard Duivenvoorde
[0] https://support.mozilla.org/en-US/questions/1027355
[1] https://support.mozilla.org/en-US/questions/978166
[2] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Hi Richard,
On Sat, Aug 15, 2015 at 01:31:48PM +0200, Richard Duivenvoorde wrote:
- we can serve osgeo.org ALL over https
My intention was to remove HSTS after a couple of complaints came in,
but I probably missed one ....
My favourite solution would be to enable HTTPS on *all* OSgeo servers.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
One option here would be to spin up an nginx instance to reverse proxy those sites that aren't configured for it to HTTPS, along the lines of the Netflix SSL accelerators. This way the individual projects don't have to handle SSL configuration if they don't want to, while those that do can simply be passed through.
--- Harrison
Martin Spott wrote:
Hi Richard,
On Sat, Aug 15, 2015 at 01:31:48PM +0200, Richard Duivenvoorde wrote:
- we can serve osgeo.org ALL over https
My intention was to remove HSTS after a couple of complaints came in,
but I probably missed one ....
My favourite solution would be to enable HTTPS on *all* OSgeo servers.Cheers,
Martin.
Hi Martin
On Sat, Aug 15, 2015 at 7:43 PM, Martin Spott <Martin.Spott@mgras.net> wrote:
Hi Richard,
On Sat, Aug 15, 2015 at 01:31:48PM +0200, Richard Duivenvoorde wrote:
- we can serve osgeo.org ALL over https
My intention was to remove HSTS after a couple of complaints came in,
but I probably missed one ....
My favourite solution would be to enable HTTPS on *all* OSgeo servers.
I can still not connect to www.osgeo.org with Firefox.
Should that work now?
best
Markus
