Nem sempre visível, a tecnologia hoje está entrelaçada em nossas vidas, não existe mais on-line e offline, estamos de uma forma ou de outra, sempre online.
Um problema aparentemente simples que me consumiu algo em torno de 12h entre pesquisas infinitas, estudo, testes, modificações nos códigos existentes.
Um conhecimento que vale pra nós que estamos atuando na área da tecnologia é que nunca poderemos nos dar ao luxo de achar que ficaremos livres de manutenção e monitoramento recorrente, isso vem com a tecnologia como a batata vem no lanche do Mc.
Os grandes evoluem e definem o que vai ser, nós na camada de software como negócios somos gradativamente empurrados na direção que é decidida por aqueles que de fato controlam a tecnologia.
Sem manutenção e acompanhamento leva pouco mais de algumas semanas pra tudo ruir, o ônus do bônus, sendo nós empresários de produtos baseado em tecnologia temos sempre que estar nos atualizando, é um misto de busca pela evolução, na constante apreensão da segurança, nesse segundo aspecto já passamos poucas e boas em nossos produtos também.
Cada vez mais nos apoiamos sobre estruturas as quais se param por 1 minuto, nós temos um grande surto de problemas consecutivos.
Minha última experiência
A minha última experiência aconteceu na última segunda-feira, 11 de novembro de 2019, onde um dos meus produtos, que possui parte codificada em .NET apresentou um defeito parcial, em resumo não conseguia conectar-se ao servidor para receber informações de uma API via requisição https.
Já há algum tempo eu venho estudando possibilidades de deixar de usar aplicações instaladas na máquina, mas como é sabido, o hardware físico sofre para comunicar-se com algo que não está instalado, e mais ainda, na hora do desenvolvimento torna-se mais complexo você tentar assumir essa bronca sozinho, visto que o fabricante do hardware que você está usando vai te entregar uma biblioteca e uma documentação de 1000 anos atrás na maioria das vezes. E é aquilo que você tem, reescreva se for capaz, mais ou menos isso.
Mesmo apenas uma fração bem pequena dos produtos do meu grupo ainda dependerem de software instalado na máquina do cliente, o pouco que se tem, atrapalha quando apresenta defeitos inesperados.
Queixa
Desde ontem não estamos obtendo informações da pessoa na biometria, estamos operando em contingência, apenas identificando se temos a pessoa cadastrada.
Reconhecimento do terreno
Meu primeiro movimento foi levantar as características do ambiente que eu estava lidando e como estava o comportamento e outras partes daquele ecossistema, o que você verão mais pra frente que foi uma estratégia acertada a se fazer.
- Percebi que conseguia acessar a API do servidor manualmente via navegador;
- Percebi que outras extremidades do mesmo cliente acessavam a API e rodavam o programa que não rodava nesse computador específico;
Nesse momento eu já eliminei:
- Problema na API decorrente de algum deploy anterior na aplicação;
- Problemas relacionados a DNS;
- Problema relacionado a firewall do servidor bloqueando IP do cliente;
- Problema ser fora da máquina que eu estava mexendo;
Equipamento que eu estava mexendo
Windows 7, .NET Framework 4.5 conectado a leitor biométrico e catraca.
Estratégia que usei
Primeiramente eu tentei estourar o erro na tela. A aplicação de produção utilizava try catch no algoritmo sem um log de contenção e não estava por isso exibindo nenhuma mensagem, ainda que com o erro de conexão ao servidor acontecendo.
Criei uma versão que estourava o erro e uma vez com a mensagem de erro em mãos iniciei a minha pesquisa.
A mensagem que obtive era:
Não foi possível criar um canal seguro para SSL/TLS
Iniciei as pesquisas e comecei a trombar com uma série de artigos contando sobre as convenções da indústria, na direção do que estava sendo considerado como válido para uso atualmente e quais versões daqueles protocolos estavam sendo descontinuadas e começadas a serem marcadas como inseguras, além de incompatibilidade de versões, caso seu servidor e seu cliente rodassem versões distintas.
Nesse ponto eu já começava a cair em algumas páginas de atualizações do Windows que citavam fixes em cima de problemas relacionados a protocolos SSL/TLS, mas eu estava escolhendo fixes a dedo, estava acessando essa máquina remotamente, não queria correr o risco de instalar um update do windows e a máquina não mais inicializar, uma clássico do nosso querido Windows.
Encontrei um fix e falei: É esse, esse fix vai me ajudar! Fui na sessão de downloads do catálogo da Microsoft e para minha surpresa a lista de pré-requisitos dele exigia a instalação de outros 3 fixes antes. Eu que só queria instalar um update, acabei instalando 4, toda vez que reiniciava o coração apertava até conectar novamente.
Pausa para reflexão sobre o contexto a nível do cliente
Lembra lá no início que eu falei sobre o fato de que cada vez nos apoiamos mais na tecnologia e 1 minuto parado começam a gerar problemas em série? Pois então, não temos como nos darmos ao luxo de parar algo muito tempo, no momento que eu decidi testar minhas hipóteses de rodar os fixes é o momento que tudo para no cliente e temos, neste caso, um cenário de catraca parada, perdendo assim o controle de entrada dos clientes e não clientes.
Retomando o raciocínio
Fixes instalados! Vamos testar e shazammm, nada feito, mesmo problema. Igualzinho, mesmo problema, exatamente a mesma coisa.
Parei com as pesquisas e decidi tentar resolver a nível de código, pensei que se de alguma forma eu pudesse forçar o protocolo TLS que eu queria usar isso resolveria meu problema.
Chequei a nível de servidor qual versão estávamos e fui ao código:
- Forcei a versão do TLS 1.2 (a mesma do servidor) a nível de código na aplicação;
Nada feito, problema persistiu. - Cruzei os dedos para não quebrar a aplicação, alterei a versão do .NET Framework para a mais recente e no cliente instalei a mesma versão.
Nada feito, problema persistiu.
Retornei as pesquisas
Agora fui na direção de Windows 7 e tentei achar alguma coisas que me fizesse ter certeza sobre como ele trabalhava com TLS 1.2. Comecei a achar artigos interessantes:
Windows 7 supports TLS 1.1 and TLS 1.2. However, these protocol versions are not enabled on Windows 7 by default. On Windows 8 and higher, these protocols are enabled by default.
Hmmm, então quer dizer que isso não é default, quero tornar default então, como faço? A interface mais intuitiva que a Microsoft criou até hoje, o Regedit. Lá estava eu mudando binários para tentar forçar aquela máquina a rodar sobre o TLS 1.2, que a essa altura eu já estava certo que ela não estava rodando.
Alterado o Regedit, reiniciando mais uma vez, cruzando os dedos…Bé bé bé, nada feito. Whaaaaat? Como pode!
Aqui já estava cogitando dizer: é o fim do uso do Windows 7, vou mandar formatar essa máquina e vou abraçar as novas dores possíveis que vou passar a ter com Windows 10 e seus infinitos updates. Mas na minha última fagulha de esperança, eis que de volta ao catálogo de updates da Microsoft encontro algo promissor.
KB3140245 – Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows
E sem outros fixes de outros pré-requisitos? Só podia ser pegadinha do João Kleber. Mais a fundo no texto sobre o fix estava lá citado também os binários que tinha alterado no Regedit. Achei que super valia a tentativa e baixei a singela atualização de 796kb.
A esperança é a última que …
Nessa altura, já desacreditado da vida, reiniciei, comemorei que mais uma vez não tinha ficado trancado pra fora, e com o pingo de esperança que me restava, cliquei pra abrir a aplicação.
Por um segundo achei que minha sessão remota tinha travado, pois em todas as outras vezes o erro era imediato, mas não, a aplicação estava finalmente carregando corretamente!
E sim, finalmente, na última gota de esperança que me restava, lá estava um bendito bug no Windows 7, corrigido com uma atualização de menos de 1mb que não me permitia usar o protocolo TLS 1.2 no Windows 7.
Conclusão que tirei disso tudo
Do ponto de vista técnico, novamente a realidade da tapa na cara, muitas vezes você pode desmontar o seu castelo inteiro, gastar mil horas, no final às vezes seu problema vai ser uma configuração, uma vírgula errada, uma instalação de atualização de 1 mb.
Do ponto de vista de negócio que abri esse artigo, esqueça achar que as coisas são imutáveis no contexto de software, se você é uma empresa que vende tecnologia, seja ela na forma de software ou hardware, você vai ter o passivo da manutenção e monitoramento, não existe o conceito de pronto mesmo quando tudo está pronto, é melhor dizer pronto até que alguém ou alguma coisa se atualize ou pare de dar suporte.
E daqui pra frente, pelo que já viemos vendo, é ter a tecnologia ao seu lado e se preocupar em entendê-la e se atualizar e monitorar constantemente, pois do contrário você e seu negócio ficarão reféns dela.
Se você gostou desse artigo, você pode encontrar meus outros artigos de temas presentes no meu dia a dia no trabalho na categoria Work aqui do blog.
