The coming Google Symantec Certification battle has been started...

[polonus]

Read: https://groups.google.com/a/chromium.org/forum/?_escaped_fragment_=msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ#!msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ
and https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ

Google will no longer trust certain Symantec certificates and you will miss the green padlock there in the Google chrome browser.
Owners of such certificates have to reckon with shorter and shorter validity of such certificates,
they should already do a bro-SSL-check.

I thought Symantec was great in certificate security with their crypto-reports:  https://cryptoreport.websecurity.symantec.com/checker/

But now Google seems to differ this opinion. What are the positions behind this?

Anyone?

polonus

[bob3160]

More information on the dispute is available here:
Google is fighting with Symantec over encrypting the internet

[polonus]

Symantec's reply: https://www.symantec.com/connect/blogs/symantec-ca-proposal
and what Google is going to maintain Certificate Transparency
(what Symantec plans to have implemented towards the end of the year):
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html

How to check: https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=SO28983
Test for CT (Certificate Transparency) yourself here.
You can check your domain (sub-domain(s)) here: https://www.entrust.com/ct-search/

And of course we have old Netcraft's: https://www.netcraft.com/internet-data-mining/netcraft-br-ev-and-ct-compliance-checking-for-certificate-authorities/

More on Certificate Transparency: https://www.certificate-transparency.org

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

[Pondus]

July 29, 2017 

https://www.bleepingcomputer.com/news/security/google-outlines-ssl-apocalypse-for-symantec-certificates/

[polonus]

Hi Pondus,

Humiliating for Symantec, but they have to comply in order to stay in business during their SubCA phase: https://knowledge.symantec.com/au/support/ssl-certificates-support/index?page=content&id=ALERT2259&actp=LIST&viewlocale=en_US

polonus

P.S.  Cyber criminals who want certificates faster can easily get them from other CAs who do minimal fraud checks, have weak security controls, or fewer and less-equipped staff

[polonus]

Update: Symantec certification etc.  sold out to DigiCert now solves their predicament with browser-developers:
https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-business/

pol

[bob3160]

Update: Symantec certification etc.  sold out to DigiCert now solves their predicament with browser-developers:
https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-business/

pol

The question still remains as to whether this fixes the problem or simply passes the buck.

[polonus]

Hi bob3160

DigiCert, a good reseller, superiour support, nice portal to order and manage your certs,
and also a support unit that functions also outside the normal 9 tot 5 scheme,
and you certainly cannot say that for all of these services. So let's hope for the best.

Google and firefox will feel their pulse, where SSL-CT is concerned...let's wait and see...

Damian

[polonus]

Certification manipulation will be a more and more important issue to identify malcreants,
to pinpoint server misuse and abuse, and use of illegit keys and authenticode.

Read about such an issue here: https://forum.avast.com/index.php?topic=206955.0

Maybe we can classify such certification abuse as SMU::EE malcode,
often abused by spamvertisers and trackback malcreants.

Examples to be checked here: https://certificate.revocationcheck.com/
See: htxps://www.hybrid-analysis.com/sample/76282e7506de8f2d97eaa0957873ac55741768783b6062e07de952eeeddfbb73?environmentId=100.

Files not properly signed should be come under scrutiny.
AV should use such methods to stamp those that scheme to go under the detection radar.

polonus (website security analyst and website error-hunter)

[polonus]

After requests on Wednesday morning last (info credits and action taken by Bitwiper) Thawte revoked the certificate of "Media Lid" with SHA1 hash ?08159399879e46d464ed090ec1059c7c30219a3a (08:15:93:99:87:9e:46:d4:64:ed:09:0e:c1:05:9c:7c:30:21:9a:3a)
and serial number  ?200b8eadff8610c8a288e874ea157f9f (aka "?20 0b 8e ad ff 86 10 c8 a2 88 e8 74 ea 15 7f 9f").

Revocation is just from that date and earlier versions of the malware with digital signatures
may therefore be considered as being valid and slip through.

Therefore the whole revocation scheme can be considered to be a disaster as the update frequency at http://tl.symcb.com/tl.crl
takes a fortnight, so when you computer has downloaded this yesterday, it will be another thirteen days.
Until that day the computer will trust the CRL to be valid. A complete FAIL, also for AV vendors and end-users.
Some things have to change...

polonus

[polonus]

This could not all be that problematic, when we did not have stolen code-signing certicates.
to sign for example malware java applets etc.

This happened in the past to Opera and Adobe and verious others.

Certficates sold to non-existing entities to certify malicious executables. Or trusted certificates are being used (abused),
but not for those institutions they were meant for, like Nokia and GMail. Furthermore there are MiM attacks on CA.

BHO's to install a fake Verisign certificate as Trusted Root Certificate Authority.

The PKI system is not functioning as it should and should be strengthened and also used to assist AV pointing at misused servers and abuse. When Authentication Servers have not the right update engines to sufficiountly update, we are in trouble.
Then there are attacks on CA, think of the Dutch DigiNotar tragedy.

polonus

[polonus]

One vicitim of these sloppy revocation procedures and the way in which Windows does this or fails to do so,
also helped by AV vendors with insecure https scanning procedures (Bitdefender etc.)  not taking this into the bargain,
reported by me here in "the virus and worms", and ironically for his revocation testing website:

Google Safebrowsing alerts: not secure! Privacy error.
D+ grade: https://observatory.mozilla.org/analyze.html?host=revoked.grc.com
Re: Certificate status:
 Revoked
Revocation check method:
 OCSP
Revocation reason:
 Unspecified
See: http://toolbar.netcraft.com/site_report?url=https://revoked.grc.com

Issuing organisation   DigiCert Inc   Issuer common name   DigiCert SHA2 Secure Server CA
Issuer unit   Not Present   Issuer location   Not Present
Issuer country   US   Issuer state   Not Present
Certificate Revocation Lists   http://crl3.digicert.com/ssca-sha2-g5.crl (revoked on 2017-04-09 21:21:34)
http://crl4.digicert.com/ssca-sha2-g5.crl (revoked on 2017-04-09 21:21:34)
Certificate Hash   wnGopcA4eFiXOGQYFEY9BWUOXXE
Public Key Hash   9ff197c0a0cca32ef19e39f72a8cc0236d20900ddaea6fe52638834318f127c3
OCSP servers   http://ocsp.digicert.com - 100% uptime in the past 24 hours 
OCSP stapling response   Certificate revoked   OCSP revocation date   Apr 9 21:21:34 2017 GMT
OCSP data generated   Aug 6 17:48:54 2017 GMT   OCSP data expires   Aug 13 17:03:54 2017 GMT
Current certificate revocation   
The current certificate for this site has been revoked by a CRL:

CRL   Revocation date
Google Chrome CRLSet   not revoked
http://crl3.digicert.com/ssca-sha2-g5.crl   2017-04-09 21:21:34
http://crl4.digicert.com/ssca-sha2-g5.crl   2017-04-09 21:21:34
Revocation information last updated 2017-08-10 18:00 GMT.

Certificate transparency   
Signed Certificate Timestamps (SCTs)

Source   Log   Timestamp   Signature Verification
No SCTs received or issuer unknown
SSL Certificate Chain
Not given here: https://www.virustotal.com/en/url/37e0df4fe50246d0409277f29cda0368b05680c63b6a0105b73cdf7eb9617ae2/analysis/1502456622/

Seems for instance some NSA spooks may grin in their beards, while spoofing authentication that way gets real easy. 

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

[polonus]

Certification revoking does not work: https://news.ycombinator.com/item?id=7583553

Here it already went wrong: https://www.imperialviolet.org/2012/02/05/crlsets.html

polonus

[polonus]

A response from micosoft. com: They do not consider certificate-revovation, that is not functioning, a security issue,
but see it as a normal Windows bug or a Thawte issue. Dutch Security Technician Bitwiper, who got this response then wrote in reply:

This is about code signing certificate revocation not working in Windows, either because of issues in Thawte's CRL file, or because of a bug in Windows.

In any case, how can this not be a _security_ bug?

What if the cybercriminals involved started signing and distributing backdoored UEFI drivers? Or seemingly legitimate Windows updates (for example on public WiFi by _replacing_ .cab files downloaded from Windows update servers via http) using this compromised Thawte certificate?

What when one is having a situation like this? Re: https://www.fireeye.com/blog/threat-research/2017/08/apt28-targets-hospitality-sector.html

What would be the point of authenticode or digital signatures in general if errors (private key compromises or certificates sold to malicious parties) cannot be undone?

When "trusted" does no longer really means "Trusted"? We all are food for the birds....

So we need an independent Foundation delivering  Identity Services, but this is not only the technical side, it is also seeing to it cybercriminals and spooks cannot manipulate (DNS, make you download compromised downloads etc.).
Not an easy thing to do.

Certification Industry and Microsoft certainly created a predicament for users here or caused this situation to arise...

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

[polonus]

Cert revocation check misery:

Secure Connection Failed

An error occurred during a connection to isc.sans.edu. The OCSP server suggests trying again later. Error code: SEC_ERROR_OCSP_TRY_SERVER_LATER

We see the site using OCSP stapling. In Wireshark we see a TLSv1.2 network parcel with states "Certificate, Certificate Status, Server Key Exchange, Server Hello Done". info Bitwiper.

OCSP Response responseStatus: tryLater (3)

When your CA has not solved several issues, site cannot be reached...
Download  http://tl.symcb.com/tl.crl and install whever you are a malware researcher of sorts or dealing with potentially insecure files...
install with a right click on the file...
When a file has be downloaded automattically revocation will not be due for another fortnight....
See also https://imgur.com/a/rMHPE  for a Thawte CRL fail...

All is also platform dependant -> xs4all does not has aCAA ïnstalled!!!

C-grade and recommendations: . https://observatory.mozilla.org/analyze.html?host=www.xs4all.nl
Site already went from grade D via  C to C+.

A+ https://www.ssllabs.com/ssltest/analyze?d=www.xs4all.nl

E-status site has issues: https://securityheaders.io/?followRedirects=on&hide=on&q=www.xs4all.nl

No pre-loading: Domain is a subdomain, and can't be preloaded.
HSTS header missing the "includeSubDomains" attribute.
HSTS header missing the "preload" attribute.
Complete Results:   https://hstspreload.org/?domain=www.xs4all.nl
There should not be a kake timestamp from before the revocation date...

For a *hotjar CAA link on a newspaper website Gandi Standard SSL CA2
Certificate installed by -> cps.usertrust.com via cloudfront.net...

Re: https://certificatedetails.com/5379bf5aaa2b4acf5480e1d89bc09df2b20366cb/5e4dc3b9438ab3b8597cba6a19850e3/gandistandardsslca2
and
https://certificate.revocationcheck.com/hotjar.com

Read on StackExchange Serverfault on this subject:
https://serverfault.com/questions/656558/the-certificate-is-not-trusted-because-the-issuer-certificate-is-unknown-error

polonus