wsusscn2.cab signature verification failure

Re: wsusscn2.cab signature verification failure

Postby boco » 16.11.2016, 05:51

Using Win7 on all systems important to me.

Yet, P2P technique is found in many applictations (mostly messengers) and not evil. It can only be used for evil (but so can many things). For example, I'm using Torrent for getting Linux distro images and LibreOffice. Perfectly legal. Torrent uses plenty of hashing so the end result is always 100% identical.
Microsoft update catalog: http://catalog.update.microsoft.com/v7/site/
Windows Install media download: https://support.microsoft.com/en-us/help/15088/windows-create-installation-media
boco
 
Posts: 2391
Joined: 24.11.2009, 17:00
Location: Germany

Re: wsusscn2.cab signature verification failure

Postby jharris1993 » 16.11.2016, 05:59

boco wrote:Using Win7 on all systems important to me.

Yet, P2P technique is found in many applications (mostly messengers) and not evil. It can only be used for evil (but so can many things). For example, I'm using Torrent for getting Linux distro images and LibreOffice. Perfectly legal. Torrent uses plenty of hashing so the end result is always 100% identical.


Jigdo does a similar thing using a push/pull type of sync between two definite points. Probably just a mindless fear, but Torrents give me the creeps.

Go figure.

Jim (JR)
Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 13
Joined: 13.11.2016, 02:17

Re: wsusscn2.cab signature verification failure

Postby psloss » 16.11.2016, 17:29

I think there's a cloud aspect to this, which shouldn't be surprising. In other words, there are many websites that serve the same content for a given remote IP address from multiple different virtual machines.

In this case inconsistent content is being served for the same host name, but Microsoft's back-end content distribution appears to be borked -- and worse, neglected -- such that different, inconsistent content -- which should be static -- is also being served for a given remote IP address.

There's still some hope that these virtual IP addresses are grouped in some way (regionally maybe) and that there are groups of virtual servers where the signed CAB file is more prevalent.

For the last three weeks or so, I feel like I'm playing a slot machine when I check this URL or go to the trouble of downloading the bits. Yet another aspect of updating Windows that becomes less reliable as time goes by.

Here's what I saw last night (my time) with two HEAD requests to "download.windowsupdate.com" for "/microsoftupdate/v6/wsusscan/wsusscn2.cab"; these were about 10 seconds apart. Same URL, same request, same remote IP address, but different ETag, only 10 seconds apart:

First response headers and remote socket IP tuple:
Code: Select all
HTTP/1.1 200 OK
Cache-Control: max-age=0
Connection: close
Date: Tue, 15 Nov 2016 23:54:54 GMT
Pragma: no-cache
Content-Length: 201419112
Content-Type: application/vnd.ms-cab-compressed
Expires: Tue, 15 Nov 2016 23:54:54 GMT
Last-Modified: Wed, 09 Nov 2016 18:15:16 GMT
Accept-Ranges: bytes
Age: 0
ETag: W/"fb5afe38b53ad21:0"
Server: Footprint Distributor V4.11
MSRegion: N. America
x-ccc: US
x-cid: 3
X-Powered-By: ASP.NET

Remote socket addr: 8.254.243.126:80

Second response:
Code: Select all
HTTP/1.1 200 OK
Cache-Control: max-age=0
Connection: close
Date: Tue, 15 Nov 2016 23:55:05 GMT
Pragma: no-cache
Content-Length: 201419112
Content-Type: application/vnd.ms-cab-compressed
Expires: Tue, 15 Nov 2016 23:55:05 GMT
Last-Modified: Wed, 09 Nov 2016 18:15:16 GMT
Accept-Ranges: bytes
Age: 0
ETag: W/"9e7be538b53ad21:0"
Server: Footprint Distributor V4.11
MSRegion: N. America
x-ccc: US
x-cid: 3
X-Powered-By: ASP.NET

Remote socket addr: 8.254.243.126:80

For reference, here's a typical DNS A record response from this Internet access point:
Code: Select all
"question" = [download.windowsupdate.com], type = [A]
Record 1: Name [download.windowsupdate.com], Type 5, CNAME = 2-01-3cf7-0009.cdx.cedexis.net, TTL = 230 / 0x000000E6
Record 2: Name [2-01-3cf7-0009.cdx.cedexis.net], Type 5, CNAME = fg.download.windowsupdate.com.c.footprint.net, TTL = 230 / 0x000000E6
Record 3: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.243.142, TTL = 230 / 0x000000E6
Record 4: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.194.190, TTL = 230 / 0x000000E6
Record 5: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.243.238, TTL = 230 / 0x000000E6
Record 6: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.220.78, TTL = 230 / 0x000000E6
Record 7: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.220.30, TTL = 230 / 0x000000E6
psloss
 
Posts: 14
Joined: 14.05.2016, 15:10

Re: wsusscn2.cab signature verification failure

Postby boco » 16.11.2016, 18:14

I'm accessing the server over IPv6 (AAAA-record, possibly different DNS), maybe that's why I'm lucky with the catalog.

Code: Select all
C:\>ping download.windowsupdate.com

Pinging a767.dspw65.akamai.net [2a02:8100:c2:4140::5886:b6da] with 32 bytes of data:
Reply from 2a02:8100:c2:4140::5886:b6da: time=40ms
Reply from 2a02:8100:c2:4140::5886:b6da: time=30ms
Reply from 2a02:8100:c2:4140::5886:b6da: time=29ms
Reply from 2a02:8100:c2:4140::5886:b6da: time=32ms

Ping statistics for 2a02:8100:c2:4140::5886:b6da:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 29ms, Maximum = 40ms, Average = 32ms
Microsoft update catalog: http://catalog.update.microsoft.com/v7/site/
Windows Install media download: https://support.microsoft.com/en-us/help/15088/windows-create-installation-media
boco
 
Posts: 2391
Joined: 24.11.2009, 17:00
Location: Germany

Re: wsusscn2.cab signature verification failure

Postby psloss » 17.11.2016, 02:01

I let this run during the workday here and got a longer, larger sample. As with the earlier post, I get footprint.net most of the time and that group of servers seems to be consistently inconsistent. Running a little while longer and I do find an occasional response from a different load balancing group; I saw a couple of different "outliers" that ironically may be more consistent than footprint.net.

The next "thing" to test is whether focusing content requests anywhere but footprint.net consistently provides a valid, signed CAB file. Or at least improves the odds of getting a valid, signed CAB file.

For compare and contrast, here's the DNS A record response I'm typically getting; probably 75% of the time (or more):
Code: Select all
"question" = [download.windowsupdate.com], type = [A]
Record 1: Name [download.windowsupdate.com], Type 5, CNAME = 2-01-3cf7-0009.cdx.cedexis.net, TTL = 230 / 0x000000E6
Record 2: Name [2-01-3cf7-0009.cdx.cedexis.net], Type 5, CNAME = fg.download.windowsupdate.com.c.footprint.net, TTL = 230 / 0x000000E6
Record 3: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.243.110, TTL = 230 / 0x000000E6
Record 4: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.243.238, TTL = 230 / 0x000000E6
Record 5: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.220.94, TTL = 230 / 0x000000E6
Record 6: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.254.243.62, TTL = 230 / 0x000000E6
Record 7: Name [fg.download.windowsupdate.com.c.footprint.net], Type 1, A = 8.253.129.249, TTL = 230 / 0x000000E6

DNS lookups for download.windowsupdate.com from this Internet access point always return the 2-01-3cf7-0009.cdx.cedexis.net CNAME, but sometimes that forwards elsewhere, like this one that forwards to edgesuite.net and finally akamai.net:
Code: Select all
"question" = [download.windowsupdate.com], type = [A]
Record 1: Name [download.windowsupdate.com], Type 5, CNAME = 2-01-3cf7-0009.cdx.cedexis.net, TTL = 20 / 0x00000014
Record 2: Name [2-01-3cf7-0009.cdx.cedexis.net], Type 5, CNAME = download.windowsupdate.com.edgesuite.net, TTL = 20 / 0x00000014
Record 3: Name [download.windowsupdate.com.edgesuite.net], Type 5, CNAME = a767.dspw65.akamai.net, TTL = 20 / 0x00000014
Record 4: Name [a767.dspw65.akamai.net], Type 1, A = 66.61.173.146, TTL = 20 / 0x00000014
Record 5: Name [a767.dspw65.akamai.net], Type 1, A = 66.61.173.115, TTL = 20 / 0x00000014

Response headers:
HTTP/1.1 200 OK
Cache-Control: max-age=0
Connection: close
Date: Wed, 16 Nov 2016 20:21:55 GMT
Pragma: no-cache
Content-Length: 201419112
Content-Type: application/vnd.ms-cab-compressed
Last-Modified: Wed, 09 Nov 2016 07:20:13 GMT
Accept-Ranges: bytes
ETag: "80f42bb6593ad21:0"
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
X-CCC: US
X-CID: 2

Remote socket addr: 66.61.173.146:80

Here's another "outlier," download.windowsupdate.com to 2-01-3cf7-0009.cdx.cedexis.net to au-msedge.net; HTTP response headers look like subset/superset, so probably from the same content distribution network:
Code: Select all
"question" = [download.windowsupdate.com], type = [A]
Record 1: Name [download.windowsupdate.com], Type 5, CNAME = 2-01-3cf7-0009.cdx.cedexis.net, TTL = 44 / 0x0000002C
Record 2: Name [2-01-3cf7-0009.cdx.cedexis.net], Type 5, CNAME = b1ns.au-msedge.net, TTL = 44 / 0x0000002C
Record 3: Name [b1ns.au-msedge.net], Type 5, CNAME = b1ns.c-0001.c-msedge.net, TTL = 44 / 0x0000002C
Record 4: Name [b1ns.c-0001.c-msedge.net], Type 5, CNAME = c-0001.c-msedge.net, TTL = 44 / 0x0000002C
Record 5: Name [c-0001.c-msedge.net], Type 1, A = 13.107.4.50, TTL = 44 / 0x0000002C

Response headers:
HTTP/1.1 200 OK
Cache-Control: max-age=0
Connection: close
Date: Wed, 16 Nov 2016 20:46:00 GMT
Pragma: no-cache
Content-Length: 201419112
Content-Type: application/vnd.ms-cab-compressed
Last-Modified: Wed, 09 Nov 2016 07:20:13 GMT
Accept-Ranges: bytes
ETag: "80f42bb6593ad21:0"
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
X-CID: 7
X-CCC: US
X-MSEdge-Ref: Ref A: BF0BFC5689F24DC8BBCFC31D5C5A7F93 Ref B: BCF7D294DC2484549471475CA5F39710 Ref C: Wed Nov 16 12:46:01 2016 PST

Remote socket addr: 13.107.4.50:80
psloss
 
Posts: 14
Joined: 14.05.2016, 15:10

Re: wsusscn2.cab signature verification failure

Postby lan14 » 17.11.2016, 14:30

I'm having the verification issue also. I have tried numerous times to download and still get the same error message. How/where do I verify the signature? I'm running Windows 7, internet explorer 11.
lan14
 

Re: wsusscn2.cab signature verification failure

Postby aker » 17.11.2016, 19:39

Sorry to say, but retry until you get a working one.
It takes about five attempts here. (Germany, Google DNS)
Wer Rechtschreibfehler findet, darf sie behalten oder an den Meistbietenden versteigern. / Everybody finding a misspelling is allowed to keep or sell it.
aker

WSUS Offline Update „Community Edition“
https://gitlab.com/wsusoffline/wsusoffline/-/releases
aker
 
Posts: 3999
Joined: 02.03.2011, 15:32

Re: wsusscn2.cab signature verification failure

Postby psloss » 18.11.2016, 16:02

So far, I've found three distribution networks, the same ones as from the last post:

1. footprint.net (INCONSISTENT)
2. download.windowsupdate.com.edgesuite.net
3. b1ns.au-msedge.net

As noted, DNS is being used to distribute the load across those networks (and any others).

footprint.net is randomly serving up a bad CAB file or a good CAB file; who knows when that will be fixed.

I haven't tried the other two as much, but aside from research and diagnostics I want to avoid the footprint.net distribution for this file.

In case anyone is interested, one can use a tool like WGET or CURL to force the request for the CAB file to go to one of the other networks.

1. Explicitly specify the Host: header in the request
2. Replace the host in the URL with one of the two other distro network host names

For example, with WGET:
Code: Select all
wget --server-response --verbose --header="Host: download.windowsupdate.com" "http://b1ns.au-msedge.net/microsoftupdate/v6/wsusscan/wsusscn2.cab"

-OR-
Code: Select all
wget --server-response --verbose --header="Host: download.windowsupdate.com" "http://download.windowsupdate.com.edgesuite.net/microsoftupdate/v6/wsusscan/wsusscn2.cab"

I have only tried this on Windows machines so far, but WGET and CURL should behave elsewhere, certainly more consistently than the content distribution for wsusscn2.cab. (One could also force the HTTP request down to the IP address level, but I'm not sure of the advantage in this case.)

There is no guarantee this will scale, of course, but waiting for Microsoft to test or fix this issue is an even bigger waste of time.
psloss
 
Posts: 14
Joined: 14.05.2016, 15:10

Re: wsusscn2.cab signature verification failure

Postby hbuhrmester » 18.11.2016, 18:01

I suspect, that ETags with the prefix W/ indicate some intermediate state.

Wikipedia says:

Strong and weak validation

The ETag mechanism supports both strong validation and weak validation. They are distinguished by the presence of an initial "W/" in the ETag identifier, as:

"123456789" – A strong ETag validator
W/"123456789" – A weak ETag validator

A strongly validating ETag match indicates that the content of the two resource representations is byte-for-byte identical and that all other entity fields (such as Content-Language) are also unchanged. Strong ETags permit the caching and reassembly of partial responses, as with byte-range requests.

A weakly validating ETag match only indicates that the two representations are semantically equivalent, meaning that for practical purposes they are interchangeable and that cached copies can be used. However the resource representations are not necessarily byte-for-byte identical, and thus weak ETags are not suitable for byte-range requests. Weak ETags may be useful for cases in which strong ETags are impractical for a web server to generate, such as with dynamically-generated content.

https://en.wikipedia.org/wiki/HTTP_ETag


Such ETags may actually indicate broken files, which fail at the verification of digital file signatures.

For example, I have one file with the ETag: W/"3f3846a1a3ad21:0", and it failed:

Code: Select all
Sigcheck v2.1 - File version and signature viewer
Copyright (C) 2004-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

D:\WSUS Offline Update\2016-11-08_22-54\wsusscn2.cab:
        Verified:       Es handelt sich nicht um eine kryptografische Meldung, oder die kryptografische Meldung hat ein
falsches Format.
        File date:      22:54 08.11.2016
        Publisher:      n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a


Another file with the ETag: "817d2250b53ad21:0" succeeded:

Code: Select all
Sigcheck v2.1 - File version and signature viewer
Copyright (C) 2004-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

D:\WSUS Offline Update\2016-11-09_18-15-55_GMT\wsusscn2.cab:
        Verified:       Signed
        Signing date:   04:32 09.11.2016
        Publisher:      Microsoft Corporation
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a


So, two files are not a big sample, but it could give us a hint in the right direction.

Then such files could be excluded with the conditional header "If-None-Match":

Code: Select all
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"


https://tools.ietf.org/html/rfc7232#section-3.2

PS

I found two more examples from July 2016:
  • one good file: ETag: "0a4bbc34adcd11:0"
  • and another bad file: ETag: W/"f4b6d9e38cdcd11:0"
hbuhrmester
 
Posts: 525
Joined: 11.10.2013, 20:59

Re: wsusscn2.cab signature verification failure

Postby pentup » 18.11.2016, 18:04

I was able to download a signed copy today from windows update at the following link.

http://download.windowsupdate.com/micro ... usscn2.cab

I've also stashed a copy on Mega just in case.

https://mega.nz/#!EVJFjBAT!P_8f0FbPfTBe ... Kf0eCrEwRU
pentup
 

PreviousNext

Return to Download

Who is online

Users browsing this forum: No registered users and 48 guests