Hi @ll, yesterdays "Security update deployment information: February 13, 2018" <https://support.microsoft.com/en-us/help/20180213> links the following MSKB articles for the security updates of Microsoft's Office products: <https://support.microsoft.com/kb/4011715> <https://support.microsoft.com/kb/4011200> <https://support.microsoft.com/kb/3114874> <https://support.microsoft.com/kb/4011707> <https://support.microsoft.com/kb/4011711> <https://support.microsoft.com/kb/4011690> <https://support.microsoft.com/kb/4011697> <https://support.microsoft.com/kb/4011701> <https://support.microsoft.com/kb/3172459> <https://support.microsoft.com/kb/4011143> <https://support.microsoft.com/kb/4011686> <https://support.microsoft.com/kb/4011682> <https://support.microsoft.com/kb/4011680> Alternatively use yesterdays "February 2018 updates for Microsoft Office" <https://support.microsoft.com/en-us/help/4077965> and all the MSKB articles linked there, which are a superset of those named above. Each of these MSKB articles in turn contains one or two links to the download pages for the updates, which except 2 (of 22) are of the form <http://www.microsoft.com/downloads/details.aspx?familyid=GUID> (despite the HTTPS: used for the MSKB articles), ie. they use HTTP instead of HTTPS, inviting to MitM attacks, ALTHOUGH the server www.microsoft.com supports HTTPS and even redirects these requests to <https://www.microsoft.com/downloads/details.aspx?familyid=GUID>! JFTR: this bad habit is of course present in ALMOST ALL MSKB articles for previous security updates for Microsoft's Office products too ... and Microsoft does NOT CARE A B^HSHIT about it! Microsoft also links all the MSKB articles for their Windows security updates, for example <https://support.microsoft.com/kb/4074595>, in their "Security update deployment information: <month> <day>, <year>". Allmost all of these MSKB articles as well as those for Microsoft's Office products (see above) in turn contain a link to Microsoft's "Update Catalog", which ALL are of the form <http://catalog.update.microsoft.com/v7/site/search.aspx?q=4074595> (despite the HTTPS: used for the MSKB articles), ie. they use HTTP instead of HTTPS, inviting to MitM attacks, ALTHOUGH the server catalog.update.microsoft.com [*] supports HTTPS! JFTR: even if you browse the "Microsoft Update Catalog" via <https://www.catalog.update.microsoft.com/Home.aspx> [#], ALL download links published there use HTTP, not HTTPS! That's trustworthy computing ... the Microsoft way! Despite numerous mails sent to <secure@xxxxxxxxxxxxx> in the last years, and numerous replies "we'll forward this to the product groups", nothing happens at all. stay tuned Stefan Kanthak [*] catalog.update.microsoft.com is redirected to catalog.update.microsoft.com/v7/site, which in turn is redirected to www.catalog.update.microsoft.com/, for both HTTP and HTTPS CONNECT https://catalog.update.microsoft.com GET / http/1.1 | HTTP/1.1 302 Found | Cache-Control: private | Content-Length: 125 | Content-Type: text/html; charset=utf-8 | Location: /v7/site | Server: Microsoft-IIS/10.0 | X-AspNet-Version: 4.0.30319 | X-Powered-By: ASP.NET | Date: Wed, 14 Feb 2018 09:42:51 GMT | HTTP/1.1 301 Moved Permanently | Content-Length: 168 | Content-Type: text/html; charset=UTF-8 | Location: https://catalog.update.microsoft.com/v7/site/ | Server: Microsoft-IIS/10.0 | X-Powered-By: ASP.NET | X-Frame-Options: DENY | Date: Wed, 14 Feb 2018 09:42:51 GMT | HTTP/1.1 302 Redirect | Content-Length: 164 | Content-Type: text/html; charset=UTF-8 | Location: https://www.catalog.update.microsoft.com/ | Server: Microsoft-IIS/10.0 | X-Powered-By: ASP.NET | X-Frame-Options: DENY | Date: Wed, 14 Feb 2018 09:42:51 GMT | HTTP/1.1 200 OK | Cache-Control: private | Content-Length: 11135 | Content-Type: text/html; charset=utf-8 | Server: Microsoft-IIS/10.0 | X-AspNet-Version: 4.0.30319 | X-Powered-By: ASP.NET | X-Frame-Options: DENY | Strict-Transport-Security: max-age=31536000; includeSubDomains | Date: Wed, 14 Feb 2018 09:42:53 GMT [#] if your browser attemps to connect to these servers with HTTP/2, it fails: they use a blacklisted cipher suite with HTTP/2, see <https://www.ssllabs.com/ssltest/analyze.html?d=catalog.update.microsoft.com>