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 () microsoft com> 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>