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.
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
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…
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.
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)
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…
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.
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:
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:
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 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)
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.... :o
See also https://imgur.com/a/rMHPE for a Thawte CRL fail...
All is also platform dependant → xs4all does not has aCAA ïnstalled!!!
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…
Somehow the general infrastructure stays ‘borked’, Microsoft for instance not acting against audio-eavesdropping by microphone and certain surveillance parties blaming Kaspersky’s for doin’g so. Double standards rule and political bias is taken as the red herring.
The provided 0-day holes are so-called “features”, those that wanna protect you against it are portrayed as ‘evildoers’.
Those that matter do not listen, those in the know do not matter, so everything stays “borked” as pre-designed. :o
polonus (volunteer website security analyst and website error-hunter)
The whole thing with certificates should be about “trust”, but it is all only about the money, and trust here is a secondary issue.
Moreover 90% of users do not have an idea why they should trust a green padlock inside their browser or not.
With such an action both Google and Symantec protect themselves against loss of money, as certificates do not loose their value immediately, so expensive certificates are not turned into worthless ones. Taking months for all of this to happen, Google can put the blame at certification not being renewed within time, and prevents both Google and Symantec against loosing money.
The old infrastructure is not failing because of a newer infrastructure being introduced. Otherwise we would have had a real “trust” crisis, and users would not trust certification like in the past. Browsers, CA vendors, accountants all profit from/depend on the financial position of this CA system, so when you can no longer visit a particular website iside the browser, vendors loose money and new buyers stay away. Whit a multi-billion system no one wants to loose money when a CA or an accountant is not performing as it should.
As polonus sees it, the Internet infrastructure as such is experiencing the greatest trust crisis of all times. Only most are not aware of ehat is happening, and some even do not care.
It is all about the status-quo between those that want to keep the infrastructure secure and those that wanna keep it zero-holed to quite an extent. It is a very, very difficult balancing act all the way,
polonus (volunteer website security analyst and website error-hunter)
