Opened 4 years ago

Last modified 4 years ago

#9837 assigned Bug/Something is broken

*.mayfirst.org forwards to untrusted https

Reported by: https://id.mayfirst.org/jeremyjohn Owned by: https://id.mayfirst.org/ross
Priority: Urgent Component: Tech
Keywords: subdomain ssl Cc:
Sensitive: no

Description (last modified by https://id.mayfirst.org/jeremyjohn)

Hello there,

I've got a site on ossie I'm getting set up, http://mosaicchurchdc.mayfirst.org, but whenever I enter that URL, it forwards to https.

I ain't seeing https in the apache config.

Is this a bug or is this "works as designed?"

Specifically, I see this error, "The certificate is only valid for the following names: ossie.mayfirst.org, www.ossie.mayfirst.org"

Firefox isn't offering to let me add an exception as it normally does with self-signed certs, and I actually just tried to add an exception manually and it won't let me.

Peace, jj

Change History (20)

comment:1 Changed 4 years ago by https://id.mayfirst.org/jeremyjohn

  • Description modified (diff)

comment:2 Changed 4 years ago by https://id.mayfirst.org/jeremyjohn

  • Description modified (diff)

comment:3 Changed 4 years ago by https://id.mayfirst.org/jeremyjohn

  • Description modified (diff)

comment:4 Changed 4 years ago by https://id.mayfirst.org/dskallman

  • Keywords subdomain ssl added
  • Owner set to https://id.mayfirst.org/ross
  • Status changed from new to assigned

Hi Jeremy,

I'm looping Ross in to answer your ticket.

Dana

comment:5 Changed 4 years ago by https://id.mayfirst.org/ross

Hi jj,

I think this must be something specific with your version of firefox. I am not getting the behavior you describe. Can you try to open a new profile in firefox and test the address:

firefox --no-remote -ProfileManager

Let me know,

~/ross

comment:6 Changed 4 years ago by https://id.mayfirst.org/jeremyjohn

  • Resolution set to invalid
  • Status changed from assigned to closed

Well I'll be. Yep, it's Firefox. Opening in a new profile with no settings fixes the problem. That is, it doesn't forward from http to https.

Closing as invalid. If I come up with the particular extension that's at fault I'll post that here.

Thanks for your help!

Odd behavior, didn't suspect the browser and can't think of an extension that would be the culprit.

-jj

comment:7 Changed 4 years ago by https://id.mayfirst.org/mahood

  • Resolution invalid deleted
  • Status changed from closed to assigned

Hey all,

I ran into a similar issue a couple of weeks back when trying to visit dev.social.mayfirst.org and it also was pointing me to the https for the site, which is not configured. Upon chat conversation with ross I too did the same thing and changed my profile and that seemed to resolve the issue until yesterday when it happened again. This is also happening on bbb.mayfirst.org. The catch is that i am certain this is Iceweasel/Firefox related as I visited both sites successfully in chromium when entering http://dev.social.mayfirst.org & http://bbb.mayfirst.org but when I visit in Iceweasel it redirects to the https://<version of both above listed sites>

I am at a loss on what to do but felt this should be reopened to further investigation.

~mv

comment:8 Changed 4 years ago by https://id.mayfirst.org/ross

Okay, we tracked down a defining symptom of this problem. Apparently, anything with a .mayfirst.org sub-domain produces this behavior when the firefox/iceweasel instance is in the redirect state. I'm not sure why this is, but it definitely is related to how firefox is handling redirecting to https versions of mayfirst.org.

Still trying to figure this out,

~/ross

comment:9 Changed 4 years ago by https://id.mayfirst.org/dkg

hm, first off, we shouldn't have any MF/PL sites that involve authentication over http in the first place. secondly, dev.social.mayfirst.org should probably be social.dev.mayfirst.org.

It looks to me like the redirection is done because we're now mentioning includeSubDomains in the STS header for https://mayfirst.org:

0 dkg@alice:~$ wget -O- -q -S https://mayfirst.org 2>&1 | grep Strict-Transport
  Strict-Transport-Security: max-age=31536000; includeSubDomains
0 dkg@alice:~$ 

I'm a little surprised by this -- i would have thought that we didn't want to includeSubDomains for https://mayfirst.org/, since we have so many end-user sites that probably don't do https. Maybe this happened as a result of the implementation of #9777? But i don't see any documentation of that decision. Was there discussion about this tradeoff somewhere else?

Anyway, that max-age is a full year, so we've publicly committed to it for the next 365 days for anyone who has ever visited https://mayfirst.org. Not sure what the best next thing to do is...

comment:10 Changed 4 years ago by https://id.mayfirst.org/ross

Yes this is a result of #9777, thanks for figuring this out dkg. I wonder why firefox seems to exhibit this behavior but chromium does not.

comment:11 Changed 4 years ago by https://id.mayfirst.org/erq

  • Priority changed from Medium to Urgent

hi, apparently this issue if affecting http://bbb.mayfirst.org which is redirecting to https://bbb.mayfirst.org and now shows "Unable to connect" error message.

Unfortunately today (in 30min), a working group of Mutual Assistance Technical Communities had scheduled to run a test of evaluation of BBB in this instance, with participation of more-less ten persons of different latinamerican countries.

  • Is there a chance we could put http://bbb.mayfirst.org back online in a few minutes?
  • Do we have another instance available to share with this working group?

I will ask Apolinar about the condition of this installation.

comment:12 Changed 4 years ago by https://id.mayfirst.org/ross

Enrique,

BBB is still on line, you just need to use another firefox profile or a different browser.

~/ross

comment:13 Changed 4 years ago by https://id.mayfirst.org/jeremyjohn

From the above: "Anyway, that max-age is a full year, so we've publicly committed to it for the next 365 days for anyone who has ever visited ​https://mayfirst.org."

Are we saying that anybody who has https.mayfirst.org in their browser history will now hit an error on any subdomain of mayfirst.org until they clear their browser's history of visited sites? Seems like that would affect a fair number of people involved with mayfirst, possibly even strangers that would think that various MF hosted sites were down.

I don't know how difficult this would be, but it seems that a fix for this could be allowing https for all subdomains.

comment:14 Changed 4 years ago by https://id.mayfirst.org/ross

Hi Jeremey,

There are probably too many sub-domains for this to be viable. I've been experimenting with firefox, and what I've determined is that you can remove the permissions.sqlite file from your ~/.mozilla/firefox/profile, and the problem is resolved. It also may be possible to go to about:permissions and choose "Forget About This Site", for mayfirst.org to resolve the problem.

I have not experienced the problem in chromium, so I'm not sure what would be the fix there.

~/ross

P.S. I have removed the includeSubDomains directive for mayfirst.org

Last edited 4 years ago by https://id.mayfirst.org/ross (previous) (diff)

comment:15 follow-up: Changed 4 years ago by https://id.mayfirst.org/dkg

hm, i recommend strongly against removing permissions.sqlite -- that database is probably quite useful for many other things, and removing it is pretty drastic.

Instead, go visit https://mayfirst.org/ and hard-refresh the page.

since ross removed includeSubDomains from https://mayfirst.org, that should reset the flag in your browser's history.

after that, visiting http://whatever.mayfirst.org should *not* get an automatic redirection. if it still does, then you might try closing your browser and restarting it -- i haven't tested how the caching of this info works.

comment:16 in reply to: ↑ 15 Changed 4 years ago by https://id.mayfirst.org/ross

Replying to https://id.mayfirst.org/dkg:

hm, i recommend strongly against removing permissions.sqlite -- that database is probably quite useful for many other things, and removing it is pretty drastic.

As far as I can tell this database creates default site permissions for a small sub-set of sites one visits. Unless you've done some significant modifications to your permissions, I don't think it's that drastic to have this database re-created.

comment:17 Changed 4 years ago by https://id.mayfirst.org/dkg

0 dkg@alice:~$ echo .dump | sqlite3 .mozilla/firefox/*.default/permissions.sqlite | wc -l
10286
0 dkg@alice:~$ 

that seems like a lot of data to discard when you just want to tweak one setting which should be tweakable by revisiting a single webpage.

comment:18 Changed 4 years ago by https://id.mayfirst.org/ross

Yes dkg, you should not remove your permissions.sqlite file. Mine was about 1/20th the size of yours. Yet again proving that size does matter! :-)

comment:19 Changed 4 years ago by https://id.mayfirst.org/dkg

btw, i tested the suggested workflow from comment:15 (without a browser restart), and it is sufficient to fix the reported problem.

comment:20 Changed 4 years ago by https://id.mayfirst.org/mahood

dkg,

I can confirm that too! good work both of you on debugging this thing :)

~mv

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.