Mais de uma década depois de implementar o suporte para conexões HTTPS seguras em seu site, o World Wide Web Consortium (W3C) está finalmente planejando começar a redirecionar conexões HTTP inseguras para a especificação mais protegida.
A organização, que recebe centenas de milhões de solicitações por dia para seu site, atrasou essa transição por medo de quebrar aplicativos da web herdados, muitos dos quais dependem de recursos alcançados via HTTP. Mas agora diz que está quase pronto, em algum momento.
“A principal razão para isso é que queríamos evitar causar problemas para software que solicitasse recursos legíveis por máquina de www.w3.org como HTML DTDs, XML Schemas e documentos de namespace”, explicou o administrador de sistemas do W3C, Gerald Oskoboiny, em um post em 25 de julho.
“Acreditamos que já passou tempo suficiente para que a maioria desses softwares tenha sido lidar com redirecionamentos e https, por isso estamos planejando começar a redirecionar todas as solicitações recebidas por http para https dentro de um mês ou dois.”
Essa data de destino, definida há um mês, tornou-se indeterminada na segunda-feira, quando Oskoboiny publicou uma postagem no blog de acompanhamento do W3C descrevendo os aprendizados dos testes iniciais dos testes HTTP para HTTPS.
Cerca de duas horas antes, perguntou sobre o plano de transição devido a preocupações levantadas por um leitor. Fomos informados de que a atualização do blog do W3C foi planejada e não está relacionada à nossa consulta.
“Não há data definida; o lançamento será informado por nossos testes e pelo feedback que recebermos”, disse Oskoboiny em um e-mail na segunda-feira.
Atualizando Java não é o seu copo de tea
O leitor que trabalha para um grande provedor de comunicações escreveu no fim de semana para questionar o cronograma proposto. Esse indivíduo, que pediu para não ser identificado porque não tem autorização de seu empregador para falar com a imprensa, disse que precisa dar suporte a um grande aplicativo da web baseado em Java com cerca de duas décadas.
Atualizar grandes aplicativos Java para HTTPS, disse ele, provavelmente será caro porque o código precisará ser alterado e testado. E ele acredita que a maioria dos administradores de sistemas não estará pronta para o impacto que a alternância HTTPS tem em sistemas de produção que dependem de recursos W3C hospedados externamente. Os esquemas XML implicados, ele sugeriu, são frequentemente usados em aplicativos governamentais para comunicações entre departamentos, máquina a máquina.
Os testes preliminares foram turbulentos. Dois testes iniciais do redirecionamento HTTP para HTTPS, por oito horas a partir de 1º de agosto e por pouco mais de 27 horas a partir de 18 de agosto, geraram vários relatórios de falhas de aplicativos. De fato, o segundo teste estava programado para 72 horas, mas foi interrompido “devido a várias reclamações de que essa mudança estava afetando os serviços de produção”, explicou Oskoboiny.
Aqueles afetados pelo teste HTTP-to -O redirecionamento HTTPS disse que a mudança quebrou o código destinado a validar esquemas XML, uma etapa opcional, mas altamente recomendável, para garantir que os dados XML sejam formados corretamente. As compilações para a ferramenta Static Driver Verifier da Microsoft, que verifica o código-fonte dos drivers do modo kernel do Windows, também falharam, de acordo com um comentarista.
“Durante nossos testes iniciais, ouvimos de algumas pessoas que isso estava causando problemas com seus sistemas que fazem solicitações automatizadas ao nosso site, por exemplo, ao fazer a validação do XML Schema”, disse Oskoboiny no post de segunda-feira. “Esperamos que esses sistemas possam ser reformulados para seguir os redirecionamentos para https ou usar um catálogo XML para manter cópias locais de quaisquer arquivos necessários para evitar solicitações desnecessárias ao nosso site.”
Os criadores de bloqueadores de anúncios e extensões de privacidade do navegador temem que o fim esteja próximo
Alguns dos aplicativos citados pelos comentaristas usam componentes Java como o pacote javax.xml.validation no JDK 11 ou javax.xml.validation.SchemaFactory no JDK 8.
Esses componentes, por sua vez, dependem de software como Apache Xerces, uma coleção de ferramentas de código aberto para lidar com XML que é amplamente usado em Java, ou libxml2 , uma biblioteca de software de código aberto para análise XML.
No caso da libxml2, um problema foi aberto há dois anos para solicitar suporte HTTPS. Há um ano, o mantenedor do projeto Nick Wellnhofer rejeitou um pedido para adicionar https, dizendo que a biblioteca não faz isso porque “é uma má ideia carregar recursos pela rede por motivos de desempenho e disponibilidade.”
Oskoboiny ecoou esse sentimento. “É bom estar ciente de quaisquer dependências que você possa ter em sites de terceiros”, disse ele.
“É surpreendente que o software moderno que faz solicitações HTTP não teria a capacidade de lidar com redirecionamentos ou https. Verifique se o software está atualizado e informe os problemas aos desenvolvedores, se necessário.”
Three days ago , o desenvolvedor Karl Brown se juntou à discussão para pedir a Wellnhofer que reconsiderasse à luz da depreciação do suporte HTTP do W3C. “Isso vai quebrar muitas ferramentas que dependem de libxml2 (como lxml)”, diz o post de Brown. “Embora eu concorde que a validação de esquema pela Internet não seja eficiente, provavelmente é amplamente usada e as soluções alternativas são complicadas.”
Para que isso aconteça, respondeu Wellnhofer, alguém precisaria passo à frente para implementar o recurso e apoiá-lo nos próximos anos. Bem-vindo ao desenvolvimento de código aberto.
O próximo teste está programado para ser executado por 48 horas, das 17:00 UTC de 1º de setembro às 17:00 UTC de 3 de setembro O sinal para apertar o cinto de segurança agora está iluminado.
