Próxima vez, após o lançamento do Chrome 154 em outubro de 2026, mudaremos as configurações padrão do Chrome para habilitar “Usar sempre conexões seguras”. Isso significa que o Chrome solicitará permissão antes de acessar qualquer site público sem HTTPS. A configuração “Usar sempre conexões seguras” alerta os usuários antes de acessar um site sem HTTPS. A equipe de segurança do Chrome tem como missão tornar mais seguro clicar em links. Uma parte de ser seguro significa garantir que, quando um usuário digita um URL ou clica em um link, o navegador chegue ao destino pretendido. Quando os links não usam HTTPS, um invasor pode tomar o controle da navegação e forçar os usuários do Chrome a carregar recursos controlados por invasores, e expor os usuários a malware, ataques direcionados ou ataques de engenharia social. Ataques como este não são hipotéticos; software para controlar a navegação está disponível e os invasores já usaram HTTP inseguro para comprometer dispositivos dos usuários em um ataque direcionado. Como os invasores só precisam de uma conexão insegura, não precisam se preocupar com o fato de que muitos sites adotaram HTTPS; qualquer conexão HTTP pode oferecer uma entrada. Além disso, muitas conexões HTTP hoje são completamente invisíveis para os usuários, pois os sites HTTP podem redirecionar imediatamente para sites HTTPS. Isso impede que os usuários vejam as mensagens de aviso do Chrome sobre URLs inseguras após o risco ter ocorrido, e impede que eles se protejam. Para resolver esse problema, lançamos a configuração “Usar sempre conexões seguras” em 2022. Nesse modo, o Chrome tenta conectar-se por HTTPS e mostra um aviso ao usuário se o HTTPS não estiver disponível. Também discutimos anteriormente a intenção de migrar para HTTPS por padrão. Acreditamos que agora é o momento de habilitar “Usar sempre conexões seguras” para todos os usuários. Por mais de uma década, o Google publicou o relatório de transparência HTTPS, que rastreia a porcentagem de conexões no Chrome que usam HTTPS. Nos primeiros anos do relatório, os números aumentaram impressionantemente, começando em torno de 30-45% em 2015 e terminando em torno de 95-99% em 2020. Desde então, o progresso tem sido em grande parte estático. A adoção de HTTPS, expressa como uma porcentagem de cargas de página principais, representa uma melhoria significativa na segurança da web e demonstra que HTTPS é agora maduro e difundido. Esse nível de adoção torna possível considerar medidas mais fortes contra o HTTP inseguro restante. Equilibrar a segurança do usuário com a fricção Embora pareça que 95% de HTTPS significa que o problema está resolvido, a verdade é que alguns pontos percentuais de conexões HTTP ainda são muitas conexões. Como as conexões HTTP ainda são uma ocorrência regular para a maioria dos usuários do Chrome, uma abordagem simples de exibir avisos para todas as conexões HTTP seria bastante disruptiva. Ao mesmo tempo, como o ponto de estagnação demonstra, não fazer nada permitiria que esse risco persistisse indefinidamente. Para equilibrar esses riscos, tomamos medidas para garantir que possamos ajudar a web a se mover para configurações mais seguras, ao mesmo tempo em que limitamos o potencial de irritação que os avisos podem causar aos usuários. Uma maneira de equilibrar os riscos é garantir que o Chrome não exiba avisos repetidamente para os mesmos sites. Em todas as variantes das configurações “Usar sempre conexões seguras”, enquanto um usuário visita regularmente um site inseguro, o Chrome não exibirá repetidamente um aviso para esse site. Isso significa que, em vez de avisar os usuários sobre 1 em cada 50 conexões, o Chrome avisará os usuários apenas quando eles visitarem um novo (ou não visitado recentemente) site sem usar HTTPS. Para abordar ainda mais a questão, é importante entender quais tipos de tráfego ainda usam HTTP. O maior contribuinte para o HTTP inseguro, e o maior contribuinte para a variação em plataformas, é a conexões inseguras para sites privados. O gráfico acima inclui conexões para sites públicos, como example.com, bem como conexões para sites privados, como endereços IP locais como 192.168.0.1, nomes de host de rótulo único e links curtos como intranet/. Embora seja fácil e gratuito obter um certificado HTTPS confiável para um site público, obter um certificado HTTPS para um site privado ainda é complicado. Isso ocorre porque os nomes privados não são únicos; os nomes privados podem se referir a diferentes hosts em diferentes redes. Não há uma única entidade que possa validar e emitir um certificado para um nome privado. As conexões HTTP para sites privados ainda podem ser arriscadas, mas geralmente são menos perigosas do que as conexões para sites públicos, porque há menos maneiras para um invasor aproveitar essas conexões HTTP. O HTTP em sites privados só pode ser usado por um invasor também na mesma rede local, como em uma rede doméstica ou em uma rede corporativa. Se excluirmos conexões para sites privados, a distribuição se torna muito mais consistente em plataformas. Em particular, o Linux passa de 84% de HTTPS para quase 97% de HTTPS quando restringimos a análise apenas para sites públicos. O Windows passa de 95% para 98% de HTTPS, e tanto o Android quanto o Mac passam para mais de 99% de HTTPS. Em reconhecimento do risco reduzido que as conexões HTTP para sites privados representam, no ano passado, introduzimos uma variante de “Usar sempre conexões seguras” apenas para sites públicos. Para usuários que acessam com frequência sites privados (como aqueles em ambientes corporativos ou desenvolvedores), excluir avisos para sites privados reduz significativamente o volume de avisos que esses usuários verão. Ao mesmo tempo, para usuários que não acessam sites privados com frequência, essa opção introduz apenas uma pequena redução na proteção. Essa é a opção que pretendemos habilitar para todos os usuários no próximo ano. A configuração “Usar sempre conexões seguras”, disponível em chrome://settings/security Em Chrome 141, experimentamos habilitar “Usar sempre conexões seguras” para sites públicos por padrão para uma pequena porcentagem de usuários. Queríamos validar nossas expectativas de que essa configuração tornaria os usuários mais seguros sem sobrecarregá-los com avisos excessivos. Ao analisar os dados do experimento, confirmamos que o número de avisos que qualquer usuário vê é consideravelmente menor do que 3% das conexões; na verdade, o usuário médio vê menos de um aviso por semana, e o usuário do percentil 95 vê menos de três avisos por semana. Entendendo o uso de HTTP Depois que “Usar sempre conexões seguras” for o padrão e mais sites migrarem para HTTP, esperamos que o volume real de avisos seja ainda menor. Paralelamente aos nossos experimentos, nos comunicamos com várias empresas responsáveis pelas conexões HTTP mais, e esperamos que elas possam migrar para HTTP antes da mudança no Chrome 154. Para muitas dessas organizações, a transição para HTTPS não é desproporcionalmente difícil, mas simplesmente não recebeu atenção. Por exemplo, muitos desses sites usam HTTP apenas para conexões que redirecionam imediatamente para HTTPS; essa é uma interação insegura que anteriormente era completamente invisível aos usuários. Outro caso de uso atual para HTTP é evitar o bloqueio de conteúdo misto ao acessar dispositivos na rede local. Os endereços de rede privada, como discutido acima, frequentemente não têm certificados HTTPS confiáveis, devido às dificuldades de validar a propriedade de um nome não único. Isso significa que a maior parte do tráfego de rede local é sobre HTTP, e não pode ser iniciado a partir de uma página HTTPS; o tráfego HTTP é considerado conteúdo misto inseguro, e é bloqueado. Um caso de uso comum para a necessidade de acessar a rede local é configurar um dispositivo de rede, por exemplo, o fabricante pode hospedar um portal de configuração em config.example.com, que então envia solicitações para um dispositivo local para configurá-lo. Anteriormente, essas páginas precisavam ser hospedadas sem HTTPS para evitar o bloqueio de conteúdo misto. No entanto, recentemente introduzimos uma permissão de acesso à rede local, que impede que os sites acessem a rede local sem consentimento, mas também permite que uma página HTTPS pule as verificações de conteúdo misto para a rede local uma vez que a permissão foi concedida. Isso pode desbloquear a migração desses domínios para HTTPS. Mudanças no Chrome Habilitaremos a configuração “Usar sempre conexões seguras” na sua variante pública por padrão em outubro de 2026, com o lançamento do Chrome 154. Antes de habilitá-la para todos os usuários, habilitaremos a configuração “Usar sempre conexões seguras” na sua variante pública para os mais de 1 bilhão de usuários que optaram por obter proteções de navegação seguras aprimoradas no Chrome. Embora esperemos que essa transição seja relativamente tranquila para a maioria dos usuários, os usuários ainda poderão desativar os avisos desativando a configuração “Usar sempre conexões seguras”. Se você é um desenvolvedor de sites ou profissional de TI, e tem usuários que podem ser afetados por essa função, recomendamos fortemente habilitar a configuração “Usar sempre conexões seguras” hoje para ajudá-lo a identificar sites que você precisa trabalhar para migrar. Os profissionais de TI podem encontrar útil ler nossos recursos adicionais para entender melhor as circunstâncias em que serão exibidos avisos, como mitigar e como as organizações que gerenciam clientes Chrome (como empresas ou instituições de ensino) podem garantir que o Chrome exiba os avisos corretos para atender às necessidades dessas organizações. Olhando para o futuro Embora acredite que avisar sobre sites públicos inseguros representa um passo significativo para a segurança da web, ainda há mais trabalho a ser feito. No futuro, esperamos trabalhar ainda mais para reduzir as barreiras à adoção de HTTPS, especialmente para sites de rede local. Isso permitirá que ainda mais conexões HTTP obtenham proteção.
Kapcsolódó cikkek
Új dél-korei kampány hamis programozási interjúkat használ a fejlesztők adatai ellopásához
Koreai-ligához tartozó hackerek a SVG zászló képeken rejtették el a rosszindulatú szoftvert, hogy a fejlesztővizsgálatok során a programozási feladatokat is megvizsgálhassák. Egyetlen antivírus-szolgáltató sem talált rá.
Az Abbott két számítógépes incidenset vizsgál meg, miután kártételezési vádak merültek fel.
Az Abbott Laboratories két különálló számítógépes biztonsági incidenset vizsgál, miután megerősítette, hogy a Cancer Diagnostics üzletágában található belső Exact Sciences rendszerekhez történt jogosulatlan hozzáférést. Emellett egy másik vádot is vizsgál, amely szerint támadók megsebeztek a LabCentral portált, és vállalatadatokat elloptak.
A HollowByte-nak talált DDoS-es hibát az OpenSSL szerveren, 11 bájtos payloadokkal.
Egy biztonsági rést, melyet HollowByte-nak neveztek, segítségével hitelesítés nélküli támadók az OpenSSL szervereken elindíthatnak egy szolgáltatási elutasítás (DoS) állapotot, csak 11 bájtnyi kártékony terheléssel.