A W3C-ről a HTTPS-re tervezett átállást meghiúsították az örökölt lemaradók • A nyilvántartás

Több mint egy évtizeddel azután, hogy webhelyén bevezette a biztonságos HTTPS-kapcsolatok támogatását, a World Wide Web Consortium (W3C) végre azt tervezi, hogy átirányítja a nem biztonságos HTTP-kapcsolatokat a védettebb specifikációkhoz.

A szervezet, amely naponta több százmillió kérelmet kap webhelyére, elhalasztotta ezt az átállást, mert félt, hogy feltörik a régi webalkalmazásokat, amelyek közül sok a HTTP-n keresztül elérhető erőforrásokra támaszkodik. De most azt mondja, hogy egy ponton szinte jó indulni.

“Ennek fő oka az, hogy el akartuk kerülni a problémákat a www.w3.org oldalról géppel olvasható forrásokat kérő szoftverekkel, például HTML DTD-kkel, XML sémákkal és névtérdokumentumokkal” – mondta Gerald Oskoboiny, a W3C rendszergazdája egy bejegyzésben. júliusban. 25.

“Úgy gondoljuk, hogy elég idő telt el ahhoz, hogy a legtöbb ilyen szoftvert frissíteni lehessen az átirányítások és a https kezelésére, ezért azt tervezzük, hogy egy-két hónapon belül minden http-n keresztül kapott kérést átirányítunk a https-re.”

Az egy hónappal ezelőtt kitűzött céldátum hétfőn vált meghatározatlanná, amikor Oskoboiny egy követőblogot tett közzé a W3C-nek, amelyben felvázolja a HTTP-HTTPS tesztelés első tesztjeinek tanulságait.

Körülbelül két órával azelőtt, A regisztráció egy olvasó aggályai miatt érdeklődött az átállási tervről. Azt mondták nekünk, hogy a W3C blogfrissítés tervezett volt, és nem kapcsolódik a vizsgálatunkhoz.

“Nincs kitűzött dátum; a bevezetést a tesztelésünk és a kapott visszajelzések határozzák meg” – mondta Oskoboiny egy e-mailben. A regisztráció hétfőn.

Nem a Java frissíti fel a teájukat?

Az olvasó, aki egy nagy kommunikációs szolgáltatónál dolgozik, ezt írta: A regisztráció hétvégén, hogy megkérdőjelezzék a javasolt idővonalat. Ez a személy, aki nem kívánja magát megnevezni, mert nem kapott engedélyt a munkáltatójától, hogy a sajtónak nyilatkozzon, azt mondta, hogy támogatnia kell egy nagy Java-alapú webalkalmazást, amely körülbelül két évtizedes.

A nagy Java-alkalmazások HTTPS-re frissítése valószínűleg költségesnek tűnik, mert a kódot módosítani és tesztelni kell. És úgy véli, hogy a legtöbb rendszergazda nem lesz felkészülve arra, hogy a HTTPS-váltás milyen hatással lesz azokra az éles rendszerekre, amelyek külsőleg üzemeltetett W3C-erőforrásokra támaszkodnak. Az érintett XML-sémákat – javasolta – általánosan használják a hivatalok közötti kommunikációt szolgáló kormányzati alkalmazásokban.

Az első tesztek viharosak voltak. A HTTP-HTTPS átirányítás két kezdeti tesztje, augusztus 1-től nyolc órán át, augusztus 18-tól pedig valamivel több mint 27 órán át, több alkalmazási hibajelentést eredményezett. Valójában a második tesztet 72 órára tervezték, de „több olyan panasz miatt, amely szerint ez a változás a termelési szolgáltatásokat érintette” – magyarázza Oskoboiny, az elmaradt.

A HTTP-HTTPS átirányítási próba által érintettek elmondták, hogy a váltás kódja az XML-sémák érvényesítésére szolgál, ami egy opcionális, de erősen ajánlott lépés az XML-adatok helyes kialakításának biztosítására. A Microsoft Static Driver Verifier eszközéhez készült buildek, amelyek ellenőrzik a Windows kernel módú illesztőprogramok forráskódját, szintén meghiúsultak – mondta egy kommentelő.

“A kezdeti tesztelés során néhány embertől hallottuk, hogy ez problémákat okoz a rendszereikben, amelyek automatizált kéréseket küldenek webhelyünkre, például az XML-sémák érvényesítését” – mondta Oskoboiny hétfői bejegyzésében. “Reméljük, hogy ezeket a rendszereket át lehet alakítani úgy, hogy kövessék a https-re történő átirányítást, vagy egy XML-katalógus segítségével megőrizzük az összes szükséges fájl helyi másolatát, hogy elkerüljük a szükségtelen kéréseket a webhelyünkön.”

A kommentelők által említett alkalmazások némelyike ​​Java-összetevőket használ, mint például a javax.xml.validation csomag a JDK 11-ben vagy a javax.xml.validation.SchemaFactory a JDK 8-ban.

Ezek az összetevők viszont olyan szoftverektől függenek, mint az Apache Xerces, amely a Java-ban széles körben használt XML-feldolgozó eszközök nyílt forráskódú készlete, vagy a libxml2, egy nyílt forráskódú XML-elemző szoftverkönyvtár.

A libxml2 esetében két éve jelent meg egy probléma a HTTPS-támogatás kérésére. Egy évvel ezelőtt Nick Wellnhofer projektmenedzser visszautasította a https hozzáadására vonatkozó kérést, mondván, hogy a könyvtár ezt nem teszi meg, mert “rossz ötlet az erőforrásokat a hálózaton keresztül betölteni teljesítmény és elérhetőség okokból”.

Oskoboiny ezt az érzést visszhangozta. “Jó, ha tisztában vagyunk a harmadik felek webhelyeitől való függőségekkel” – mondta A regisztráció.

“Meglepő, hogy a HTTP-kéréseket készítő modern szoftverek nem képesek kezelni az átirányításokat vagy a https-t. Győződjön meg róla, hogy szoftvere naprakész, és szükség esetén jelentse a problémákat a fejlesztőknek.”

Három nappal ezelőtt Karl Brown fejlesztő csatlakozott a vitához, és arra kérte a Wellnhofert, hogy gondolja át újra a W3C HTTP-támogatásának megszüntetését. “Ez sok olyan eszközt tönkretesz, amelyek a libxml2-re támaszkodnak (például az lxml)” – áll Brown bejegyzésében. “Bár egyetértek azzal, hogy az interneten keresztüli sémaérvényesítés nem hatékony, valószínűleg széles körben használják, és a megoldások makacsok.”

Ahhoz, hogy ez megtörténjen, válaszolta Wellnhofer, valakinek előre kell lépnie a funkció bevezetése és támogatása érdekében az elkövetkező években. Üdvözöljük a nyílt forráskódú fejlesztésben.

A következő teszt 48 órát vesz igénybe, szeptember 1-jén 17:00 UTC és szeptember 3-i 17:00 UTC között. A biztonsági övcsat jelzése most világít. ®

Leave a Comment

%d bloggers like this: