Server migration - status, discussion

gaekwad · 2019-01-16 17:20:31

philwareham wrote #316159:

It was the Access-Control-Allow-Origin change (which affected both the forum and docs site).

Yeah, figured – I’d just not factored in that it would solve another snag, which is always nice.

uli · 2019-01-17 16:08:01

Hi Pete! Unfortunately, for me nothing changed when viewing the docs, no styles.

gaekwad wrote #316149:

Do you have any SSL errors thrown on textpattern.com?

Yes, the same as for the stylesheet there:

SSL_ERROR_PROTOCOL_VERSION_ALERT and one screen later SSL_ERROR_NO_CYPHER_OVERLAP.

gaekwad · 2019-01-17 17:46:59

Hi uli – thanks for checking.

Our server uses the Mozilla modern cipher suite for TLS, which includes coverage from Firefox 27 onwards, and currently comprises:

ECDHE-ECDSA-AES256-GCM-SHA384 (hex: 0xC0,0×2C)
ECDHE-RSA-AES256-GCM-SHA384 (hex: 0xC0,0×30)
ECDHE-ECDSA-CHACHA20-POLY1305 (hex: 0xCC,0xA9)
ECDHE-RSA-CHACHA20-POLY1305 (hex: 0xCC,0xA8)
ECDHE-ECDSA-AES128-GCM-SHA256 (hex: 0xC0,0×2B)
ECDHE-RSA-AES128-GCM-SHA256 (hex: 0xC0,0×2F)
ECDHE-ECDSA-AES256-SHA384 (hex: 0xC0,0×24)
ECDHE-RSA-AES256-SHA384 (hex: 0xC0,0×28)
ECDHE-ECDSA-AES128-SHA256 (hex: 0xC0,0×23)
ECDHE-RSA-AES128-SHA256 (hex: 0xC0,0×27)

…while your browser cipher suite is:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (hex: 0xC0,0×2B)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (hex: 0xC0,0×2F)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (hex: 0xC0,0×24)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (hex: 0xC0,0×09
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (hex: 0xC0,0×13)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (hex: 0xC0,0×14)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (hex: 0×00,0×33)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (hex: 0×00,0×39)
TLS_RSA_WITH_AES_128_CBC_SHA (hex: 0×00,0×2F)
TLS_RSA_WITH_AES_256_CBC_SHA (hex: 0×00,0×35)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (hex: 0×00,0×0A)

The naming schemes differ between vendors, but the hex value can be used to identify a common cipher. In this case, the common ciphers are:

0xC0,0×2F
0xC0,0×24

…so there is a way to talk back and forth securely. My gut feeling at this stage is your browser might not have support for TLS 1.2 enabled, so please try this: open about:config in your browser bar, and set security.tls.version.max to 3 (which translates to TLS 1.2). Our server runs TLS 1.3 with TLS 1.2 as a fallback…and TLS 1.2 support exists in earlier Firefox versions than yours…so give that a try and see what ~~explodes~~ happens.

Edit: further reading for you kb.mozillazine.org/Security.tls.version.%2A

Last edited by gaekwad (2019-01-17 17:47:49)

uli · 2019-01-17 18:54:59

Pete, I have already a 3 for security.tls.version.max. Hope this doesn’t make you lose any hair. The min value is 1, BTW.

(I’ve of course closed all windows, emptied the cache, and quit/restarted FF, plus I shift-reloaded the page several times. Also: Just to be absolutely sure, I’ve looked for the checkmark in the View > Website Style menu, and “Default Style” is checked.)

I then experimented a little with the source code and Web Inspector: I saw that I can open/view the favicons and /site.webmanifest (all without https:// in their hrefs) without SSL errors and so edited the css href value to be simply /assets/css/style.css, and voila: I had styles. Does that give you any hint?

gaekwad · 2019-01-18 10:34:26

Uli – someone with the same error message as you found it went away when IPv6 was disabled – can you try: about:config and then network.dns.disableIPv6 to true, please, to see if that helps.

uli · 2019-01-18 12:29:24

First of all: Thanks, Pete for all your time and efforts in trying to find a solution, be it fine-tuning the TXP cipher suites, be it seeking out third party literature, be it giving tips on how to ping via terminal or how to fiddle with my browser config. Much appreciated!

I was aiming at a wider audience, though, not just me. For myself, I could set up a local stylesheet copied over from another browser, or use that browser if I don’t have access at all (not just the stylesheet), like when I currently want to read the .com website. But I can reach other https-websites, no problem. That’s mostly what I’m trying to point out. Sorry if I didn’t say that clear enough.

Edit: The network.dns.disableIPv6 setting did not help, BTW.

Last edited by uli (2019-01-18 12:31:22)

gaekwad · 2019-01-18 15:49:29

Hey uli – I had some time to look into this. I want to see if there’s anything that can be resolved at the server side without compromising security. According to a Mozilla employee, Firefox 45 ESR is no longer supported (which is probably something you already know), and their recommendation was to upgrade to ESR 60 – including fixing “massive security issues” (their words).

So, on the basis that your browser works with the version of TLS that we fly with, and there are common ciphers, I can’t think of anything else at a high level that might be resolvable here – I’ve asked for some guidance on why ESR 45 doesn’t play nicely, but I don’t have an answer on that right now. I was wondering whether your browser is aware of Let’s Encrypt! certificates – perhaps it might be too old, but then any LE-secured site would throw an error, not just Textpattern.

Recommendation, either until we know why this is happening or have a solution: continue to use ESR 45 for QuarkXPress files as needed, but use a vendor-supported browser as a daily driver.

gaekwad · 2019-01-18 21:01:23

Got it: TLS 1.3 implementation. Back when ESR 45 was supported, TLS 1.3 was in draft stage. ESR 60 is aware of the approved TLS 1.3 implementation, but something in ESR 45 is not able to negotiate the TLS 1.2 fallback. Hence, it chokes.

Follow up, and not wanting to pile woe on your tech stack, uli: I’m told ESR 45 hasn’t received a security update since April 2017 and is vulnerable to various remote code execution exploits and Spectre – so as part of a bigger issue I would seriously think about having an action plan to retire it at a suitable time. Perhaps having it run in a virtual machine for XPress files would be appropriate, since using as a daily driver might present risks.

I’m going to deep dive the server TLS fallback over the weekend, hopefully – I’ve run out of steam today. If we need to fine-tune things, I will do that.

jakob · 2019-01-18 22:27:55

Uli can say for sure, but I’m not sure that it’s actually Firefox that’s needed for Quark Xpress. I think it’s because he needs to stick with Snow Leopard to work with older Quark Xpress files and Firefox ESR 45 was I believe the last version that worked with Snow Leopard.

If the machine is capable of running a more modern MacOS, and has enough power, you might be able to upgrade and keep the entire earlier Snow Leopard as a virtual machine. The other option is to move files over from Xpress to something like InDesign, which if my memory serves me correctly was not always straightforward depending on the complexity of the layout (not to mention the cost in time, money and familiarisation with new software).

philwareham · 2019-01-19 15:43:14

Or a newer version of QuarkXPress that runs on recent OSes. Depends how critical it is to your business I suppose.

gaekwad · 2019-02-23 23:43:58

bici wrote #316695:

I hope i am posting in the right thread.
Yesterday i moved my TxP based site to a new hosting server.

Hi bici – this thread is for the migration progress of Textpattern’s own servers from Joyent to Digital Ocean, so not the right place.

gaekwad · 2019-06-06 16:37:56

For completeness, here’s the current situation with Textpattern web hosting. This post should be considered the final word on the migration.

All known Textpattern properties have been migrated from Joyent to DigitalOcean.
Our old server on Joyent was powered off this week (thanks, wet!) and will be wiped next week.

The forum was the last property to move. Thank you for your patience and understanding as we ironed out a few creases.

It’s been a considerable project to audit various sites, legacy code, quirks of yesteryear and the related activities. Security and performance have improved, and the sustainability of our web platforms is in good shape. There is still a bunch of work to do — things are not yet perfect — although the changes coming over the next 12 months will be focussed on further improvements and not wholesale server migration. New stuff is coming, though. Please stay tuned.

My special thanks go to Phil and Julian for all their behind-the-scenes work and assistance with the technicals, forum regulars (and irregulars…) who provided vital feedback, anyone who accessed our websites with peculiar browsers, broken or outdated TLS, and the various drive-by hackers/fuzzers who keep trying to get in…every…single…day.

Textpattern CMS

Textpattern CMS support forum

#121 2019-01-16 17:20:31

Re: Server migration - status, discussion

philwareham wrote #316159:

#122 2019-01-17 16:08:01

Re: Server migration - status, discussion

gaekwad wrote #316149:

#123 2019-01-17 17:46:59

Re: Server migration - status, discussion

#124 2019-01-17 18:54:59

Re: Server migration - status, discussion

#125 2019-01-18 10:34:26

Re: Server migration - status, discussion

#126 2019-01-18 12:29:24

Re: Server migration - status, discussion

#127 2019-01-18 15:49:29

Re: Server migration - status, discussion

#128 2019-01-18 21:01:23

Re: Server migration - status, discussion

#129 2019-01-18 22:27:55

Re: Server migration - status, discussion

#130 2019-01-19 15:43:14

Re: Server migration - status, discussion

#131 2019-02-23 23:43:58

Re: Server migration - status, discussion

bici wrote #316695:

#132 2019-06-06 16:37:56

Re: Server migration - status, discussion

Board footer