Is big CDN cheating on us, see this report...Akamai equals Redmond...

[polonus]

Somehow Big Cloud and Content Delivery Networks do not want us to know what exactly goes on on their servers.
Read from this report: https://www.grc.com/fingerprints.htm

One or more errors were encountered when querying:
a72-247-92-82.deploy.akamaitechnologies.com
The SSL/TLS security certificate obtained from the remote server was invalid FOR THE EXACT DOMAIN YOU ENTERED. However, we were still able to obtain the certificate's common name and fingerprint, which appear below. Since something is wrong, please examine it carefully and give your close attention to the additional diagnostic note(s) appearing next:
The Domain Name (where the certificate was obtained) DOES NOT MATCH any of the names INSIDE the certificate: (And it must.) Trustworthy certificates contain a list of one or more domain names for which they are valid. The leftmost portion of such names MAY also contain an asterisk ( * ) acting as a “wildcard character” which is valid for any domain name appearing in place of the asterisk. The trouble with the certificate returned by the server that accepted the connection at the IP for the domain name shown above, is that no matter how we look at it, IT IS NOT VALID for the domain name. This would be like a web server using someone else's security certificate. It should not happen and you should proceed with caution.

You should examine the Domain Name and Certificate Name (also known as the “Common Name”) shown below. They will often be nearly identical. For example, the Certificate Name might simply have a ‘www’ prefix which is missing from the Domain Name. And if you were to enter the domain name with the leading ‘www’ everything would be fine. But if the names are very different, something is not right.
The trouble may be something you can remedy by altering the domain name submitted, or the trouble might lie with the configuration of the remote secure web server. You should examine the domain name submitted, above, the errors returned, and the error comments to determine your best course of action.
Domain Name   Certificate Name   EV   Security Certificate's Authentic Fingerprint   Click to view complete certificate chain
a72-247-92-82.deploy.akamaitechnologies.com   *.img.s-msn.com   —   63:88:58:4B:79:FB:C6:A8:90:D5:8D:CD:D4:F9:2D:64:0A:CA:BA:CB

  Is this like it should be, and can they get away with it?

Certificate is not installed correctly
a72-247-92-82.deploy.akamaitechnologies.com

Please contact the Certificate Authority for further verification.
You have 1 error
Wrong certificate installed.
The domain name does not match the certificate common name or SAN.
Warnings
RC4
Your server's encryption settings are vulnerable. This server uses the RC4 cipher algorithm which is not secure. More information.

Who is the certifier then?

Microsoft IT SSL SH2 *.img.s-msn.com
SAN:
 *.img.s-msn.com, img.s-msn.com, img.stb.s-msn.com, int.img.s-msn.com, int.img.stb.s-msn.com, intsd.img.s-msn.com, ppe.img.s-msn.com, ppe.img.stb.s-msn.com, ppesd.img.s-msn.com, sd.img.s-msn.com
Certificate Transparency:
 Not embedded in certificate
Serial number:
 5a000392f92c18f4a1560469360001000392f9
 SHA256withRSA
Strict Transport Security (HSTS):
 Not Enabled
SSL/TLS compression:
 Not Enabled
 

The trouble with the certificate returned by the server that accepted the connection at the IP for the domain name shown above, is that no matter how we look at it, IT IS NOT VALID for the domain name. This would be like a web server using someone else's security certificate. It should not happen and you should proceed with caution. What is the reason for M$ to do this?

Google is visible everywhere. On the other hand, Akamai’s very existence is hidden and their power is obscured. But Akamai’s role as an intermediary is no less important due its invisibility. Errors provide one opportunity to highlight Akamai’s role and the power they retain.

polonus (volunteer website security analyst and website error-hunter)

[polonus]

I was not the first to notice this, but we saw very little reactions, read:

http://www.zdnet.com/article/akamais-https-fail-sets-a-bad-example/

It's one of the world's largest content distribution networks — it claims to serve out 30 percent of all web traffic by volume — and yet, it hasn't bothered to get this basic bit of security configuration sorted out.

We demonstrated it in the start of the topic above, we now found we are not the only ones to report it.
Still however nobody apparently gives a hoot!

polonus

[DavidR]

Well some companies still refuse to comment, presumably because they think that it only generates more attention to the issue.

[polonus]

Microsoft has become leaning on Akamai with outsourcing, as Alphabet also does for that matter,
because of a number of outages they experienced  in the past.

Akamai delivers their content for Net-speeding infrastructure services.

polonus

[DavidR]

As they say data is king and those that hold it control it have a valuable resource, 'marketing data' and they are all at it. Or if you take that as the situation you can't go far wrong.

For me I won't/don't use cloud storage, but these content CDN networks have their own business plan and any terms/conditions of use, but those terms of use would apply to the companies using the resource and not the end user, so who knows what they get up to.

You have probably guessed I'm a trusting sort, NOT. For many years I wouldn't even use Gmail, but now, I don't care as any email I send/receive using it isn't personal, confidential, etc. etc.

[polonus]

Hi DavidR,

Know I would agree with you, as I seem to be very familiar with your line of thinking and the standards for you to go by and to cling to.
I cannot but respect such an attitude. And also this time I should agree with your analysis.

A lot of such joint partnerships however go unnoticed. That is why I reported it here and reported Steve Gibson's remarks when scanning the certificate.

Did not know akamai and microsoft founded a bond on FedRAMP JAB's highest certification. So there is always something good in whatever bad action as well. For those that are on that list see: https://www.gsa.gov/portal/category/105279 &  https://marketplace.fedramp.gov/index.html#/products?status=Compliant&sort=productName
See that akamai is over-positioned there with 61 authorizations.

The final consideration at least should be if they can guarantee secure delivery for a custom domain. That is all that should interest us here.  No more, no less, whether we can conclusively trust the cloud under all circumstances.

And in that respect I am just one of the non-trusting kind like my avast forum colleage, DavidR. As is said in the Scriptures: "but test all things; hold firmly or fast that which is good".

polonus

[polonus]

Hi DavidR and others,

I had to so some look-ups to arrive at a place where such ssl connections can be tested against for akamai: https://ssl-tools.net/webservers/a248.e.akamai.net

But scan against https://ssl-tools.net/webservers/a72-247-92-82.deploy.akamaitechnologies.com there and you get
Certificate problems and Protocol Problems (invisibility issue). Supported: TLSv1.0
And as this is bad, but apparently for compatibility reasons for a big CDN like they are: Weak ciphers
 supported
SSL_RSA_WITH_RC4_128_SHA

Also what we had found already: the name mismatch Certificate chain
*.img.s-msn.com
285 days remaining  2048 bit sha256WithRSAEncryption
 Hostname Mismatch
Microsoft IT SSL SHA2
344 days remaining  4096 bit sha256WithRSAEncryption
Baltimore CyberTrust Root (Certificate is self-signed.)
2906 days remaining  2048 bit sha1WithRSAEncryption

All stemming from Redmond, as had to be demonstrated in this topic and  thread.

Despite a lot of people think SSL does not say anything about the real security of a particular website, just the secure connection to it.

Also consider these scan results: https://urlscan.io/result/c314d489-6c5e-4aa7-be50-c9f064d81f77#summary

For DNS I get a bad zone: bad zone: Could not get name servers for 'a72-247-92-82.deploy.akamaitechnologies.com'.
errors with serial numbers on nameservers    http://www.dnsinspect.com/akamaitechnologies.com/10114995

So this hidden internal website at internal.akamaistream.net is not visible to on the Internet.
Host does not have a DMARC record. The service is known in technical terms as adaptive bit rate streaming,
and came in with the Azure portal. Now all the big ones bet on CloudFlare for universal SSL.

polonus (volunteer website security analyst and website error-hunter)

P.S. And here we proof that invisibility equals security is not always so, look here: http://urlquery.net/report.php?id=1495998018501
and https://www.virustotal.com/pl/url/14e782d6bbe0329b061609834d2cfe91719a710936c427d19f41dacfdb47708c/analysis/1496004652/
and for the brontok worm that avast neatly detects here: https://www.virustotal.com/pl/file/850ae10bc32a9e974652ad58ce826fd7b5c2554ff70f0d4ab071338c76929044/analysis/1467503675/

Damian

[polonus]

See the CIDR report on ads and bogons Akamai driven: 2868   2894     AS20940     AKAMAI-ASN1, US
coming on position nine in their list: http://www.cidr-report.org/as2.0/#Bogons

This is dated info: http://sitevet.com/db/asn/AS20940

polonus