Under "Help/Check for Updates." the user can trigger a version check (it's also done in a frequent way automatically). Firefox) have build their own version check / update mechanisms.
There's the WSUS service, which is unfortunately only for microsoft products and not available for other projects. Normally, DNS responses coming within seconds are still awaited and accepted.On Windows, there's commonly no thing like a package manager as on (most?) linux systems. If you can isolate one of the machines from the rest of the network and let it bypass your current security elements (firewalls) when talking to the internet, and if it upgrades successfully this way, you'll know there is something wrong about your firewally.Īnother thing which surprises me is that your machine sends a DNS request, asking for an IP of, but doesn't wait for a response for a reasonable amount of time, as when the answer arrives in less than two milliseconds, it is already rejected with icmp "destination port unreachable". So if we leave aside a bug of the Microsoft upgrade client, the only idea I could have would be that some security element between the machine attempting the upgrade and the Microsoft server (reverse DNS shows that 157.56.96.58 does belong to Microsoft range) tampers with the Diffie-Hellman exchange and the client recognizes it somehow (or the server does and says the negotiation has failed). But it seems that there is actually no payload at all, as after the end of cipher suite negotiation, the client actively closes the TCP session without transferring any TLS payload at all.
As the encryption uses Diffie-Hellman key exchange, there is no way to decipher the payload and even the result of the handshake unless you would use a MITM-attack on it. You are looking at countless attempts of the machine to set up a TLS-encrypted connection with the Microsoft update server.
0 kommentar(er)
