News: 1661209208

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

W3C's planned transition to HTTPS stymied by legacy laggards

(2022/08/23)


More than a decade after implementing support for secure HTTPS connections on its website, the World Wide Web Consortium (W3C) is finally planning to begin redirecting insecure HTTP connections to the more protected spec.

The organization, which gets hundreds of millions of requests per day to its website, had delayed that transition for fear of breaking legacy web applications, many of which rely on resources reached via HTTP. But it now says it's nearly good to go, at some point.

"The primary reason for this is that we wanted to avoid causing issues for [1]software requesting machine-readable resources from www.w3.org such as HTML DTDs, XML Schemas, and namespace documents," explained W3C sysadmin Gerald Oskoboiny in [2]a post on July 25.

[3]

"We believe enough time has passed for most such software to have been updated to handle redirects and https, so we are planning to start redirecting all requests received over http to https within a month or two."

[4]

[5]

That target date, set one month ago, became indeterminate on Monday when Oskoboiny published [6]a follow-up blog post for the W3C outlining learnings from the initial tests of the HTTP-to-HTTPS tests.

About two hours prior, The Register had inquired about the transition plan due to concerns raised by a reader. We're told that the W3C blog update was planned and unrelated to our inquiry.

[7]

"There is no firm date; the rollout will be informed by our tests and the feedback we receive," said Oskoboiny in an email to The Register on Monday.

Refreshing Java not their cup of tea

The reader who works for a major communications provider wrote to The Register over the weekend to question the proposed timeline. This individual, who asked not to be named because he does not have his employer's authorization to speak to the press, said he has to support a large Java-based web app that's about two decades old.

Updating large Java apps to HTTPS, he said, looks likely to prove costly because the code will need to be changed and tested. And he believes the majority of sysadmins won't be ready for the impact that the HTTPS switchover has on production systems that depend on externally hosted W3C resources. The implicated XML schemas, he suggested, are often used in government applications for inter-department, machine-to-machine communications.

Preliminary testing has been turbulent. Two initial tests of the HTTP-to-HTTPS redirection, for eight hours starting August 1 and for just over 27 hours starting August 18, prompted multiple reports of application failures. In fact, the second test had been scheduled for 72 hours but was cut short "due to several complaints that this change was impacting production services," explained Oskoboiny.

Those affected by the trial HTTP-to-HTTPS redirection said the changeover broke code intended to validate XML schemas, an optional but highly advisable step to ensure that XML data is properly formed. Builds for Microsoft's [8]Static Driver Verifier tool, which verifies the source code of Windows kernel-mode drivers, also failed, according to one commenter.

[9]

"During our initial tests we heard from a few people that this was causing issues with their systems that make automated requests to our site, for example when doing XML Schema validation," said Oskoboiny in Monday's post. "We are hoping these systems can be reworked to either follow the redirects to https, or use an XML catalog to keep local copies of any files needed to avoid making unnecessary requests to our site."

[10]W3C overrules objections by Google, Mozilla to decentralized identifier spec

[11]Mozilla edict: 'Web-accessible' features need 'secure contexts'

[12]What if Chrome broke features of the web and Google forgot to tell anyone? Oh wait, that's exactly what happened

[13]Makers of ad blockers and browser privacy extensions fear the end is near

Some of the applications cited by commenters use Java components like the javax.xml.validation package in JDK 11 or javax.xml.validation.SchemaFactory in JDK 8.

These components in turn rely on software like [14]Apache Xerces , an open source collection of tools for handling XML that's used widely in Java, or [15]libxml2 , an open source software library for XML parsing.

In the case of libxml2, an issue was opened two years ago to ask for HTTPS support. A year ago, project maintainer Nick Wellnhofer rebuffed a request to add https, [16]saying that the library doesn't do so because "it's a bad idea to load resources over the network for performance and availability reasons."

Oskoboiny echoed that sentiment. "It's good to be aware of any dependencies you might have on third-party sites," he told The Register .

"It's surprising that modern software that makes HTTP requests wouldn't have the ability to handle redirects or https. Please make sure your software is up to date, and report issues to the developers if needed."

Three days ago, developer Karl Brown joined the discussion to ask Wellnhofer to reconsider in light of the W3C's deprecation of HTTP support. "This is going to break a lot of tools that rely on libxml2 (such as lxml)," Brown's [17]post says. "While I agree schema validation over the internet is not efficient, it is likely widely used and the work-arounds are kludgy."

In order for that to happen, Wellnhofer responded, someone would need to step forward to implement the feature and support it in the years to come. Welcome to open source development.

The next test is scheduled to run for 48 hours, from 1700 UTC [18]on Sep 1 until 1700 UTC Sep 3 The sign to fasten your seatbelt is now illuminated. ®

Get our [19]Tech Resources



[1] https://www.w3.org/blog/2008/02/w3c_s_excessive_dtd_traffic/

[2] https://www.w3.org/blog/2022/07/redirecting-to-https-on-www-w3-org/

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[6] https://www.w3.org/blog/2022/08/https-redirection-observations/

[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[8] https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/static-driver-verifier

[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YwRQ3SFVzkctuCeyAhfuEAAAANI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[10] https://www.theregister.com/2022/07/01/w3c_overrules_objections/

[11] https://www.theregister.com/2018/01/18/mozilla_secure_contexts_edict/

[12] https://www.theregister.com/2021/10/04/chrome_breaks_web/

[13] https://www.theregister.com/2022/06/08/google_blocking_privacy_manifest/

[14] https://xerces.apache.org/

[15] https://gitlab.gnome.org/GNOME/libxml2/-/wikis/home

[16] https://gitlab.gnome.org/GNOME/libxml2/-/issues/160#note_1005174

[17] https://gitlab.gnome.org/GNOME/libxml2/-/issues/160#note_1532589

[18] https://status.w3.org/

[19] https://whitepapers.theregister.com/



Wellnhofer is incoherent

Fazal Majid

If his concern is about loading schemas over the network, he should disable unencrypted HTTP as well.

Re: Wellnhofer is incoherent

VoiceOfTruth

Some points.

1. Are you offering to write and maintain the HTTPS support, as suggested by Wellnhofer? If no, then why complain?

2. If you followed the link and read it, you would see a couple of points. Wellnhofer wrote a year ago that "adding HTTP support directly to the library was a mistake". And six months ago he wrote "I'll probably start by disabling HTTP and FTP support by default.".

He is far from being incoherent. He has made his position clear. You can always fork the code and provide your own solution instead of lobbing in uninformed insults.

appeal to incompetence

Anonymous Coward

Tech A "you should update that." Maintainer, "you're right". Tech B "That broke my deployment" Maintainer "Fix your shit" Tech B "NO"

Maintainer to tech A "Sorry, you can't have nice things because that guy is an idiot."

The lazy ones already hacked together something with SQUID. The smart ones are either also lazy or unwilling to do a strict validation test over an unvalidateable connection.

Corollary: We are all using the part of the Internet built for the dumbest half of the web developers. That's the whole internet. No other part exists.

msobkow

Critical component "A" REQUIRES JDK 8.

Without critical component "A", none of us have jobs and the owners get sued for failing to deliver.

Higher level JDKs are NOT an option at this time, and even the NEWER versions of that component require JDK 11 as their portability base, so they will NOT be using newer functionality.

Anonymous Coward

Only because after JDK 8, there is a license cost to users associated with using Java.

I do not seek the ignorant; the ignorant seek me -- I will instruct them.
I ask nothing but sincerity. If they come out of habit, they become tiresome.
-- I Ching