{"id":21736,"date":"2023-09-15T14:12:44","date_gmt":"2023-09-15T17:12:44","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=21736"},"modified":"2023-09-15T14:12:44","modified_gmt":"2023-09-15T17:12:44","slug":"windows-system-time-sudden-changes","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/windows-system-time-sudden-changes\/21736\/","title":{"rendered":"Os perigos da hora do sistema errada e o recurso Propaga\u00e7\u00e3o de Tempo Segura"},"content":{"rendered":"

De vez em quando, os usu\u00e1rios e administradores do Windows 10 se perguntam<\/a> por que, repentinamente, o rel\u00f3gio do sistema local salta v\u00e1rias semanas, meses ou at\u00e9 anos (tanto para frente<\/a> quanto para tr\u00e1s<\/a>).<\/p>\n

Qual poderia ser a causa desses saltos? Os jornalistas da Ars Technica fizeram uma pequena pesquisa<\/a> e descobriram que isso pode estar vinculado ao recurso Secure Time Seeding, ou em portugu\u00eas, Propaga\u00e7\u00e3o de Tempo Segura. Neste post, explico como esse recurso parece funcionar e o que pode ser feito para evitar tais saltos inesperados.<\/p>\n

O que \u00e9 o Secure Time Seeding ou Propaga\u00e7\u00e3o de Tempo Segura?<\/h2>\n

Secure Time Seeding (STS)<\/a> ou Propaga\u00e7\u00e3o de Tempo Segura<\/a> foi adicionado ao Windows 10 em 2015. O recurso tem como objetivo corrigir discrep\u00e2ncias entre a hora definida no sistema e o valor temporal real \u2013 principalmente quando a bateria de um dispositivo que alimenta o rel\u00f3gio de tempo real<\/a> interno acaba e as configura\u00e7\u00f5es do hor\u00e1rio n\u00e3o t\u00eam rela\u00e7\u00e3o com o tempo presente. Mais importante ainda, o STS \u00e9 capaz de corrigir a hora do sistema sem acessar os servidores da infraestrutura existente.<\/p>\n

Mas por que \u00e9 necess\u00e1ria tal corre\u00e7\u00e3o de discrep\u00e2ncias de tempo? Curiosamente, por seguran\u00e7a. Normalmente, a troca de dados cliente-servidor (incluindo a conex\u00e3o do sistema aos servidores online de sincroniza\u00e7\u00e3o de tempo<\/a>) \u00e9 protegida com protocolos de criptografia SSL\/TLS. Para estabelecer tal conex\u00e3o com o servidor, aquele que faz o papel de cliente primeiro precisa verificar o certificado digital, e esses certificados possuem um determinado per\u00edodo de validade. Portanto, se o valor temporal do sistema for definido com um erro significativo, o certificado poder\u00e1 ser considerado expirado e uma conex\u00e3o segura n\u00e3o ser\u00e1 estabelecida.<\/p>\n

Surge ent\u00e3o um c\u00edrculo vicioso: para saber o valor temporal presente, o computador deve ter a informa\u00e7\u00e3o correta da hora atual. N\u00e3o \u00e9 necess\u00e1rio que seja perfeitamente preciso; o tempo aproximado tamb\u00e9m pode funcionar. Por\u00e9m, quanto maior a diferen\u00e7a entre a hora do sistema e a hor\u00e1rio real, maior ser\u00e1 a chance do certificado receber a indica\u00e7\u00e3o de expirado.<\/p>\n

O STS introduz (pelo menos na mente de seus desenvolvedores) uma forma do sistema identificar e corrigir automaticamente grandes discrep\u00e2ncias, mesmo quando uma conex\u00e3o segura n\u00e3o pode ser estabelecida com nenhum servidor. Isso \u00e9 poss\u00edvel por meio da utiliza\u00e7\u00e3o de carimbos de data\/hora presente e datas de expira\u00e7\u00e3o de certificados digitais contidos nos dados enviados pelos servidores cliente durante os procedimentos iniciais de uma conex\u00e3o segura (os handshakes SSL e TLS).<\/p>\n

O algoritmo exato do STS \u00e9 desconhecido. Mas a ideia geral \u00e9 que o Windows extraia dados dos protocolos SSL e os use para calcular um intervalo confi\u00e1vel para o hor\u00e1rio atual e atribuir-lhe uma probabilidade. \u00c0 medida que novos dados ficam dispon\u00edveis, o intervalo \u00e9 atualizado e a probabilidade pode aumentar gradualmente. Quando atinge um determinado limite, o STS decide alterar o rel\u00f3gio do sistema local para o tempo mediano do intervalo que considera confi\u00e1vel. Em teoria, essa precis\u00e3o deveria ser suficiente para estabelecer uma conex\u00e3o segura, conectar-se a um servidor com valor temporal presente e obter a hora exata.<\/p>\n

Por que voc\u00ea deve desabilitar o recurso de Propaga\u00e7\u00e3o de Tempo Segura<\/h2>\n

O principal problema \u00e9 que o recurso est\u00e1 habilitado no Windows 10 por padr\u00e3o e funciona independentemente de o rel\u00f3gio do sistema local estar fora de sincronia. Como resultado, o STS pode redefinir a hora a qualquer momento quando o algoritmo secreto da Microsoft decidir que h\u00e1 sinais suficientes de que o rel\u00f3gio est\u00e1 marcando um hor\u00e1rio incorreto e precisa ser ajustado.<\/p>\n

A raz\u00e3o para tais problemas neste recurso de Propaga\u00e7\u00e3o de Tempo Segura n\u00e3o \u00e9 totalmente compreendida. Uma causa sugerida \u00e9 o aumento significativo na popularidade das implementa\u00e7\u00f5es SSL\/TLS que enviam um carimbo de data\/hora incorreto durante os protocolos de seguran\u00e7a. O principal suspeito aqui \u00e9 a biblioteca OpenSSL frequentemente usada (que, em vez da hora atual do servidor, coloca valores aleat\u00f3rios no carimbo de data\/hora).<\/p>\n

Al\u00e9m disso, esse bug tamb\u00e9m pode ocorrer em vers\u00f5es de servidor do sistema operacional: Windows Server 2016, Windows Server 2019 e Windows Server 2022. E embora para usu\u00e1rios comuns de computador o problema seja pouco mais que um inc\u00f4modo, para infraestruturas maiores tende a ser catastr\u00f3fico, j\u00e1 o funcionamento correto geralmente depende da precis\u00e3o do tempo.<\/p>\n

H\u00e1 um conselho n\u00e3o oficial<\/a> sobre isso de um profissional s\u00eanior de suporte t\u00e9cnico da Microsoft para administradores de controladores de dom\u00ednio do Active Directory:<\/p>\n

\u201cEi, pessoal, se voc\u00eas gerenciam controladores de dom\u00ednio do Active Directory, quero dar alguns conselhos N\u00c3O OFICIAIS que s\u00e3o apenas minha opini\u00e3o pessoal: Desative o recurso Propaga\u00e7\u00e3o de Tempo Segura para w32time em seus DCs.\u201d<\/p><\/blockquote>\n

\"Conselho<\/a>

Conselho n\u00e3o oficial de um engenheiro s\u00eanior altamente especializado em Windows: desabilite o Secure Time Seeding<\/p><\/div>\n

\u00a0<\/p>\n

Desabilitando o recurso Propaga\u00e7\u00e3o de Tempo Segura<\/h2>\n

Para desabilitar o STS, localize a seguinte chave no registro do Windows:<\/p>\n

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\Config<\/div>\n

Encontre o valor UtilizeSslTimeData e o defina como 0.<\/p>\n

W32tm.exe \/config \/update<\/div>\n

Alternativamente, voc\u00ea pode executar o seguinte procedimento<\/a> como administrador no prompt de comando do Windows (CMD):<\/p>\n

reg add HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\w32time\\Config \/v UtilizeSslTimeData \/t REG_DWORD \/d 0 \/f<\/div>\n

Ap\u00f3s alterar o valor, voc\u00ea precisa reinicializar o sistema imediatamente. Se isso for dif\u00edcil ou imposs\u00edvel, voc\u00ea pode for\u00e7ar a atualiza\u00e7\u00e3o com este comando:<\/p>\n

Feito isso, o recurso STS deixar\u00e1 de ser um problema para voc\u00ea. Agora s\u00f3 falta garantir que o rel\u00f3gio do sistema permane\u00e7a sempre atualizado e preciso. Sobre este ponto, o artigo da Ars Technica<\/a> fornece algumas dicas \u00fateis para administradores de servidores.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Por que a hora do sistema Windows pode mudar repentinamente e como impedir que isso aconte\u00e7a.<\/p>\n","protected":false},"author":2726,"featured_media":21737,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655,1656],"tags":[40,217,267,230],"class_list":{"0":"post-21736","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-seguranca","11":"tag-ssl","12":"tag-vulnerabilidades","13":"tag-windows"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/windows-system-time-sudden-changes\/21736\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/windows-system-time-sudden-changes\/26162\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/windows-system-time-sudden-changes\/21623\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/windows-system-time-sudden-changes\/28859\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/windows-system-time-sudden-changes\/26469\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/windows-system-time-sudden-changes\/26655\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/windows-system-time-sudden-changes\/29140\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/windows-system-time-sudden-changes\/35996\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/windows-system-time-sudden-changes\/48956\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/windows-system-time-sudden-changes\/20952\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/windows-system-time-sudden-changes\/30440\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/windows-system-time-sudden-changes\/26743\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/windows-system-time-sudden-changes\/32471\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/windows-system-time-sudden-changes\/32125\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/windows\/","name":"Windows"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21736","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/comments?post=21736"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21736\/revisions"}],"predecessor-version":[{"id":21741,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21736\/revisions\/21741"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/21737"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=21736"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=21736"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=21736"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}