Avast WEBforum
Other => Non-Avast security products => Topic started by: polonus on July 29, 2017, 02:17:28 PM
-
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
-
More information on the dispute is available here:
Google is fighting with Symantec over encrypting the internet (https://techcrunch.com/2017/03/27/google-is-fighting-with-symantec-over-encrypting-the-internet/)
(http://screencast-o-matic.com/screenshots/u/Lh/1501334938265-30853.png)
-
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)
-
July 29, 2017
https://www.bleepingcomputer.com/news/security/google-outlines-ssl-apocalypse-for-symantec-certificates/
-
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
-
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
-
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/ (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.
-
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
-
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)
-
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
-
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
-
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)
-
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
-
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)
-
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.... :o
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
-
More CA trouble now concerning lack of Comodo CAA checking, reported here: https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08028.html
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)
-
Polonus would not be polunus, when he did not come up with some CAA checking links:
https://www.ssllabs.com/ssltest/analyze.html?d=
CAA record helper: https://sslmate.com/caa/
DNS CAA Tester https://caatest.co.uk/
For monitoring (free for up to 5 domains) https://sslmate.com/signup?for=certspotter
enjoy, my good friends, emjoy,
polonus
-
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)
-
Chrome’s Plan to Distrust Symantec Certificates
https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
-
On the backgrounds of trust, we should read this paper: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
polonus
-
Now Google wants to remove public key pinning in Chrome in favour of Certificate Transparency.
Re: https://www.certificate-transparency.org/
More and more Google decides where certification and security is to go.
Https everywhere, certification, Google Safebrowsing. Google to set standards.
Good background read: https://www.globalsign.com/en/blog/what-is-certificate-transparency/
The logs: https://sites.google.com/site/certificatetransparency/known-logs
Also check on: https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp
polonus
-
Due to the Symantec and DigiCert uncertainty seen from how Google handles it,
also while Comodo, one of the big players here,
has sold it's Certification Division to Fransisco Partners,
that will later come up with another name for that Cert. Division to be known under.
Re: http://www.businesswire.com/news/home/20171031005584/en/Francisco-Partners-Announces-Acquisition-Comodo%E2%80%99s-Certificate-Authority
Also on DigiCert and Mozilla's vision: https://blog.mozilla.org/security/2017/10/31/statement-digicerts-proposed-purchase-symantec/
What's all going on, why are some abandoning ship?
What does this all mean for the security and surveillance landscape.
Lots of questions arising...see what answers the future will bring.
polonus
-
Trust in Certs, does it really still exist?
Advanced hackers abuse digital certificates to smuggle malware past security scanners:
Read: https://www.theregister.co.uk/2017/11/01/digital_cert_abuse/
Simply copying an authenticode signature from a legitimate file to a known malware sample in some cases could do the trick
with 34 av solutions affected. :o (The affected AVs are listed in Table 3 in the paper referenced in the article (at http://www.umiacs.umd.edu/~tdumitra/papers/CCS-2017.pdf ).).
See: -https://github.com/HackerFantastic/Public/blob/master/tools/bypassavp.sh >:( :-[
Where's transparency check there for ye? An abuse list coming: http://signedmalware.org/
NotPetya was a recent example of such malware.
polonus
-
More HTTPS certs misery now, 23,000 HTTPS certs will be invoked!
: https://www.theregister.co.uk/2018/03/01/trustico_digicert_symantec_spat/
https://www.trustico.com/news/2018/symantec-revocation/certificate-replacement.php
polonus
-
Test version Firefox 60 gonna block Symantec certificates:
https://blog.nightly.mozilla.org/2018/03/05/these-weeks-in-firefox-issue-33/
Various incidents with Symantec produces tls-certificates lead to such decisions by both Google and Mozilla.
Also read: https://www.theregister.co.uk/2018/03/01/trustico_digicert_symantec_spat/
polonus
-
Distrust of the Symantec PKI: Immediate action needed by site operators
https://webmasters.googleblog.com/2018/04/distrust-of-symantec-pki-immediate.html
-
Update on the Distrust of Symantec TLS Certificates
https://blog.mozilla.org/security/2018/07/30/update-on-the-distrust-of-symantec-tls-certificates/
https://support.apple.com/en-us/HT208860
-
Hi Asyn,
Mozilla is not playing ball here immediately and decided to delaying further SymantecTLS Certificate Distrust,
read: https://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-certificate-distrust/
Google may think they rule the world online, alas not completely and utterly yet. :D ;D
polonus
-
Hi Pol, good to know, thanks for the update. :)
Groetjes,
Asyn