Jump to content

Search the Community

Showing results for tags 'certificates'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...

Found 19 results

  1. Let's Encrypt – a SSL/TLS certificate authority run by the non-profit Internet Security Research Group (ISRG) to programmatically provide websites with free certs for their HTTPS websites – on Thursday said it is discontinuing TLS-SNI validation because it's insecure in the context of many shared hosting providers. TLS-SNI is one of three ways Let's Encrypt's Automatic Certificate Management Environment protocol validates requests for TLS certificates, which enable secure connections when browsing the web, along with the confidence-inspiring display of a lock icon. The other two validation methods, HTTP-01 and DNS-01, are not implicated in this issue. The problem is that TLS-SNI-01 and its planned successor TLS-SNI-02 can be abused under specific circumstances to allow an attacker to obtain HTTPS certificates for websites that he or she does not own. Such a person could, for example, find an orphaned domain name pointed at a hosting service, and use the domain – with an unauthorized certificate to make fake pages appear more credible – without actually owning the domain. For example, a company might have investors.techcorp.com set up and pointed at a cloud-based web host to serve content, but not investor.techcorp.com. An attacker could potentially create an account on said cloud provider, and add a HTTPS server for investor.techcorp.com to that account, allowing the miscreant to masquerade as that business – and with a Let's Encrypt HTTPS cert, too, via TLS-SNI-01, to make it look totally legit. It sounds bonkers but we're told some cloud providers allow this to happen. And that's why Let's Encrypt ditched its TLS-SNI-01 validation processor. Ownership It turns out that many hosting providers do not validate domain ownership. When such providers also host multiple users on the same IP address, as happens on AWS CloudFront and on Heroku, it becomes possible to obtain a Let's Encrypt certificate for someone else's website via the TLS-SNI-01 mechanism. On Tuesday, Frans Rosén, a security researcher for Detectify, identified and reported the issue to Let's Encrypt, and the organization suspended certificate issuance using TLS-SNI-01 validation, pending resolution of the problem. In his account of his proof-of-concept exploit, Rosén recommended three mitigations: disabling TLS-SNI-01; blacklisting .acme.invalid in certificate challenges, which is required to get a cert via TLS-SNI-01; and looking to other forms of validation because TLS-SNI-01 and 02 are broken given current cloud infrastructure practices. AWS CloudFront and Heroku have since tweaked their operations based on Rosén's recommendation, but the problem extends to other hosting providers that serve multiple users from a single IP address without domain ownership validation. Late Thursday, after temporarily reenabling the validation method for certain large hosting providers that aren't vulnerable, Let's Encrypt decided it would permanently disable TLS-SNI-01 and TLS-SNI-02 for new accounts. Those who previously validated using TLS-SNI-01 will be allowed to renew using the same mechanism for a limited time. "We have arrived at the conclusion that we cannot generally re-enable TLS-SNI validation," said ISRG executive director Josh Aas in a forum post. "There are simply too many vulnerable shared hosting and infrastructure services that violate the assumptions behind TLS-SNI validation." Aas stressed that Let's Encrypt will discontinue using the TLS-SNI-01 and TLS-SNI-02 validation methods Article
  2. A new trend in adware and unwanted program purveyors is to install protection software that makes it more difficult for Windows users to run their security programs and clean infections. This was seen with the SmartService rootkit that blocked AV software from running and now with a protection program being called CertLock. Since the end of May, security forum helpers have noticed reports that people are not able to install and run security programs on their infected computers. When they try to run the programs, they are greeted with an alert that states that the publisher has been blocked from running on the computer. It turns out that this is being caused by CertLock disallowing a security vendor's certificate on the affected computer so that Windows does not allow the program to run. CertLock disallows security vendor certificates Being commonly detected as Ceram or Wdfload by anti-virus vendors, CertLock is distributed by unwanted programs bundles, such as miners. Once installed, CertLock will block a security vendor's certificate by adding them to a special Windows registry key. This causes Windows to not execute any programs that are signed with that certificate. CertLock blocks a certificate by creating a subkey named using the thumbprint of the certificate it wants to block to the following key: HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\ As an example, one of ESET's certificates has a thumbprint of F83099622B4A9F72CB5081F742164AD1B8D048C9. To block this certificate, CertLock will create a Registry key called: HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\F83099622B4A9F72CB5081F742164AD1B8D048C9 Under this key will be a single BLOB value that contains the certificate information. You can see an example of the registry key used to block the ESET certificate below. If a certificate is added to the Disallowed list, when a user tries to run a program that is signed by this certificate they will be greeted with an error that states "The publisher has been blocked from running software on your machine". You can see an example of the ESET installer being blocked using this method below. Blocked ESET Installer While blocking certificate prevents signed installers from running, it also prevents already installed programs that use the blocked cert from executing as well. For example, when Malwarebytes' code-signing certificates are blocked, users are greeted with errors when they try to run the program. These errors state: Unable to start Unable to connect the Service. or Error Runtime Error (at 49:120): Could not call proc. You can see examples of these errors below: Unable to connect the Service Error Malwarebytes 49:120 Error This trojan really does not like Avast While CertLock already disallows the use of the AVAST certificate, it also goes a step further to make sure Avast is unable to run. It does this by pointing many Avast.com hostnames to using the Windows HOSTs file so that the computer cannot connect to them. CertLock generates the list of Avast hosts to block by downloading the files.avast.com/iavs9x/servers.def file. This file contains a list of hostnames associated with Avast security program. It then parses this file and adds them to the Windows HOSTS file as shown below. Modified HOSTS File By adding the hostnames to the HOSTS file and pointing them to, it effectively blocks the computer from reaching these servers. How to remove Certificates Disallowed by CertLock ToolsLib.com co-administrator and Malwarebytes AdwCleaner developer Jérôme.B has created a tool called AVCertClean that will scan the Disallowed registry key for legitimate blocked keys and remove them. To use the tool, simply download and execute it. The program will then automatically remove blocked certificates AVCertClean When the program has finished, it will display a log that lists the certificates that were cleaned by AVCertClean. AVCertClean Log Now that the certificates are no longer being blocked, users can install and run their security programs in order to clean their computer. In some situations, user's may need to restart the application in order to get them to run. For example, for Malwarebytes to run after cleaning the certs, users should go into the Windows Service Manager (services.msc) and restart the Malwarebytes Service. IOCs Hashes: b1cbe0ee129bc96cc3e3d2aa4bc2ce3f6b7403045bd0ffc8956b7b7af4d070f5 - Installer (Password Protected) b529ca4dd148fdfcee0c1f267bc6821cc5168c121363fa690536a72e0f447c19 - CertLock (Thx Aura) Registry Entiries Associated with CertLock: HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\03D22C9C66915D58C88912B64C1F984B8344EF09 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\0F684EC1163281085C6AF20528878103ACEFCAAB HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\1667908C9E22EFBD0590E088715CC74BE4C60884 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\18DEA4EFA93B06AE997D234411F3FD72A677EECE HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\2026D13756EB0DB753DF26CB3B7EEBE3E70BB2CF HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\249BDA38A611CD746A132FA2AF995A2D3C941264 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\31AC96A6C17C425222C46D55C3CCA6BA12E54DAF HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\331E2046A1CCA7BFEF766724394BE6112B4CA3F7 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\3353EA609334A9F23A701B9159E30CB6C22D4C59 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\373C33726722D3A5D1EDD1F1585D5D25B39BEA1A HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\3850EDD77CC74EC9F4829AE406BBF9C21E0DA87F HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\3D496FA682E65FC122351EC29B55AB94F3BB03FC HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\4243A03DB4C3C15149CEA8B38EEA1DA4F26BD159 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\42727E052C0C2E1B35AB53E1005FD9EDC9DE8F01 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\4420C99742DF11DD0795BC15B7B0ABF090DC84DF HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\4C0AF5719009B7C9D85C5EAEDFA3B7F090FE5FFF HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\5240AB5B05D11B37900AC7712A3C6AE42F377C8C HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\5DD3D41810F28B2A13E9A004E6412061E28FA48D HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\7457A3793086DBB58B3858D6476889E3311E550E HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\76A9295EF4343E12DFC5FE05DC57227C1AB00D29 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\775B373B33B9D15B58BC02B184704332B97C3CAF HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\872CD334B7E7B3C3D1C6114CD6B221026D505EAB HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\88AD5DFE24126872B33175D1778687B642323ACF HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\9132E8B079D080E01D52631690BE18EBC2347C1E HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\982D98951CF3C0CA2A02814D474A976CBFF6BDB1 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\9A08641F7C5F2CCA0888388BE3E5DBDDAAA3B361 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\9C43F665E690AB4D486D4717B456C5554D4BCEB5 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\9E3F95577B37C74CA2F70C1E1859E798B7FC6B13 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\A1F8DCB086E461E2ABB4B46ADCFA0B48C58B6E99 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\A5341949ABE1407DD7BF7DFE75460D9608FBC309 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\A59CC32724DD07A6FC33F7806945481A2D13CA2F HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\AB7E760DA2485EA9EF5A6EEE7647748D4BA6B947 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\AD4C5429E10F4FF6C01840C20ABA344D7401209F HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\AD96BB64BA36379D2E354660780C2067B81DA2E0 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\B8EBF0E696AF77F51C96DB4D044586E2F4F8FD84 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\CDC37C22FE9272D8F2610206AD397A45040326B8 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\D3F78D747E7C5D6D3AE8ABFDDA7522BFB4CBD598 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\DB303C9B61282DE525DC754A535CA2D6A9BD3D87 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\DB77E5CFEC34459146748B667C97B185619251BA HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\E22240E837B52E691C71DF248F12D27F96441C00 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\E513EAB8610CFFD7C87E00BCA15C23AAB407FCEF HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\ED841A61C0F76025598421BC1B00E24189E68D54 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\F83099622B4A9F72CB5081F742164AD1B8D048C9 HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\FBB42F089AF2D570F2BF6F493D107A3255A9BB1A HKLM\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates\FFFA650F2CB2ABC0D80527B524DD3F9FC172C138 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\[computer_name] %temp%\[temp_name].tmp.exe Files Associated with CertLock: %temp%\[temp_name].tmp.exe Disallowed Certificates (Thumbprints): Security Vendor Thumbprint AVAST AD4C5429E10F4FF6C01840C20ABA344D7401209F AVAST DB77E5CFEC34459146748B667C97B185619251BA AVG 3D496FA682E65FC122351EC29B55AB94F3BB03FC AVG AB7E760DA2485EA9EF5A6EEE7647748D4BA6B947 AVG Technologies E513EAB8610CFFD7C87E00BCA15C23AAB407FCEF Adaware 9132E8B079D080E01D52631690BE18EBC2347C1E Avira A1F8DCB086E461E2ABB4B46ADCFA0B48C58B6E99 BitDefender 18DEA4EFA93B06AE997D234411F3FD72A677EECE BitDefender ED841A61C0F76025598421BC1B00E24189E68D54 BullGuard A5341949ABE1407DD7BF7DFE75460D9608FBC309 Bullguard 76A9295EF4343E12DFC5FE05DC57227C1AB00D29 Checkpoint Software 5240AB5B05D11B37900AC7712A3C6AE42F377C8C Comodo 03D22C9C66915D58C88912B64C1F984B8344EF09 Comodo 872CD334B7E7B3C3D1C6114CD6B221026D505EAB CurioLab 9E3F95577B37C74CA2F70C1E1859E798B7FC6B13 Doctor Web 4420C99742DF11DD0795BC15B7B0ABF090DC84DF Doctor Web FFFA650F2CB2ABC0D80527B524DD3F9FC172C138 ESET A59CC32724DD07A6FC33F7806945481A2D13CA2F ESET F83099622B4A9F72CB5081F742164AD1B8D048C9 Emsisoft 4C0AF5719009B7C9D85C5EAEDFA3B7F090FE5FFF Emsisoft 5DD3D41810F28B2A13E9A004E6412061E28FA48D F-Secure 0F684EC1163281085C6AF20528878103ACEFCAAB FRISK 1667908C9E22EFBD0590E088715CC74BE4C60884 GData 2026D13756EB0DB753DF26CB3B7EEBE3E70BB2CF K7 Computing 42727E052C0C2E1B35AB53E1005FD9EDC9DE8F01 K7 Computing 7457A3793086DBB58B3858D6476889E3311E550E Kaspersky 3850EDD77CC74EC9F4829AE406BBF9C21E0DA87F Kaspersky D3F78D747E7C5D6D3AE8ABFDDA7522BFB4CBD598 Malwarebytes 249BDA38A611CD746A132FA2AF995A2D3C941264 Malwarebytes B8EBF0E696AF77F51C96DB4D044586E2F4F8FD84 McAfee 775B373B33B9D15B58BC02B184704332B97C3CAF McAfee 88AD5DFE24126872B33175D1778687B642323ACF PC Tools 4243A03DB4C3C15149CEA8B38EEA1DA4F26BD159 Panda FBB42F089AF2D570F2BF6F493D107A3255A9BB1A SUPERAntiSpyware 373C33726722D3A5D1EDD1F1585D5D25B39BEA1A Safer Networking 982D98951CF3C0CA2A02814D474A976CBFF6BDB1 Symantec 31AC96A6C17C425222C46D55C3CCA6BA12E54DAF Symantec AD96BB64BA36379D2E354660780C2067B81DA2E0 ThreatTrack Security 9C43F665E690AB4D486D4717B456C5554D4BCEB5 ThreatTrack Security DB303C9B61282DE525DC754A535CA2D6A9BD3D87 Total Defense E22240E837B52E691C71DF248F12D27F96441C00 Trend Micro 331E2046A1CCA7BFEF766724394BE6112B4CA3F7 Trend Micro CDC37C22FE9272D8F2610206AD397A45040326B8 Webroot 3353EA609334A9F23A701B9159E30CB6C22D4C59 Webroot 9A08641F7C5F2CCA0888388BE3E5DBDDAAA3B361 Article source
  3. Sentinel Labs, SpyChatter, and Vir2us have settled with the US Federal Trade Commission (FTC) after being accused of lying to their customers about security certificates and compliance. Earlier this week, the FTC said the three companies -- an endpoint protection provider, private message app provider and cybersecurity software distributor -- have all agreed to settlement terms to keep the complaint out of the courtroom. In a statement, the US watchdog said the firms were formally charged in separate but similar complaints for deceiving consumers about their participation in the Asia-Pacific Economic Cooperation (APEC) Cross-Border Privacy Rules (CBPR) system. According to the FTC, Sentinel Labs, SpyChatter, and Vir2us all "falsely represented in their online privacy policies that they participated in the APEC CBPR system." The APEC CBPR is based on nine data privacy principles; preventing harm, notice, collection limitation, use choice, integrity, security safeguards, access and correction, and accountability, and to earn membership, companies must undergo a review by a third-party "accountability" agent. The APEC rules (.PDF) state that members must implement "appropriate" privacy measures for handling personal, sensitive data; protecting individual privacy, and promoting the free flow of information in a secure manner across borders. Holding APEC certifications gives customers reassurance that their information is managed securely to a set standard. However, the FTC alleges the charged companies were not, and never have been, certified -- despite claiming that they were. In addition, SentinelOne allegedly claimed to be a participant in a TRUSTe privacy program, but such claims were false. "Cross-border commerce is an important driver of economic growth, and our cross-border privacy commitments help enable US companies to compete around the world," said Acting Chairman Maureen Ohlhausen. "Companies, however, must live up to the promises they make to protect consumer data." While no fines have been attached to the settlement, the US agency did reveal that each of the three companies is now "prohibited from misrepresenting their participation, membership or certification in any privacy or security program sponsored by a government or self-regulatory or standard-setting organization." In a statement to ZDNet, Kylie Heintz, corporate communications at SentinelOne said, "SentinelOne respects the privacy of its customers and is glad to have amicably resolved this matter with the FTC." If Sentinel Labs, SpyChatter, or Vir2us break this agreement in the future, the consequences are likely to be severe, as they could face thousands of dollars in fines -- or worse. Source
  4. You had one job ... and it wasn't letting test certs escape into the wild and then revoking them Symantec has confirmed that it's revoked another bunch of wrongly-issued certificates. Andrew Ayer of certificate vendor and wrangler SSLMate went public with his discovery last week. The mis-issued certs were issued for example.com, and a bunch of variations of test.com (test1.com, test2.com and so on). On Saturday, Symantec's Steve Medin replied: “The listed Symantec certificates were issued by one of our WebTrust audited partners. We have reduced this partner's privileges to restrict further issuance while we review this matter. We revoked all reported certificates which were still valid that had not previously been revoked within the 24 hour CA/B Forum guideline - these certificates each had "O=test". Our investigation is continuing.” Medin said the mistake happened at partner WebTrust, and that the company is still investigating what went wrong, adding that Symantec “will report our resolution, cause analysis, and corrective actions once complete”. Security bods will be watching to see whether there's any other fallout from the latest blunder. In 2015, Google blockaded certificates from a Symantec root, because it was not complying with the CA/Browser Forum's requirements. At that time, Symantec hit back saying the certs were mostly used for internal testing, or were issued to a small handful of legacy customers. Last year, Google brought the long-running question of certificate trust into sharp relief when it launched its Certificate Transparency site, letting the world see the whole list of certs it doesn't trust. Chinese CA WoSign found itself in an unwelcome spotlight when it issued a cert for GitHub to university sysadmin Stephen Schrauger. WoSign found itself sent to the naughty corner by Mozilla, Apple, and Google. That company had to promise a reorganisation to get itself back in the world's good graces. Article source
  5. Mozilla has discovered that a Certificate Authority (CA) called WoSign has had a number of technical and management failures. Most seriously, we discovered they were backdating SSL certificates in order to get around the deadline that CAs stop issuing SHA-1 SSL certificates by January 1, 2016. Additionally, Mozilla discovered that WoSign had acquired full ownership of another CA called StartCom and failed to disclose this, as required by Mozilla policy. The representatives of WoSign and StartCom denied and continued to deny both of these allegations until sufficient data was collected to demonstrate that both allegations were correct. The levels of deception demonstrated by representatives of the combined company have led to Mozilla’s decision to distrust future certificates chaining up to the currently-included WoSign and StartCom root certificates. Specifically, Mozilla is taking the following actions: Distrust certificates with a notBefore date after October 21, 2016 which chain up to the following affected roots. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the affected roots. This change will go into the Firefox 51 release train. The code will use the following Subject Distinguished Names to identify the root certificates, so that the control will also apply to cross-certificates of these roots. CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL Add the previously identified backdated SHA-1 certificates chaining up to these affected roots to OneCRL. No longer accept audits carried out by Ernst & Young Hong Kong. Remove these affected root certificates from Mozilla’s root store at some point in the future. If the CA’s new root certificates are accepted for inclusion, then Mozilla may coordinate the removal date with the CA’s plans to migrate their customers to the new root certificates. Otherwise, Mozilla may choose to remove them at any point after March 2017. Mozilla reserves the right to take further or alternative action. If you receive a certificate from one of these two CAs after October 21, 2016, your certificate will not validate in Mozilla products such as Firefox 51 and later, until these CAs provide new root certificates with different Subject Distinguished Names, and you manually import the root certificate that your certificate chains up to. Consumers of your website will also have to manually import the new root certificate until it is included by default in Mozilla’s root store. Each of these CAs may re-apply for inclusion of new (replacement) root certificates as described in Bug #1311824 for WoSign, and Bug #1311832 for StartCom. We believe that this response is consistent with Mozilla policy and is one which we could apply to any other CA that demonstrated similar levels of deception to circumvent Mozilla’s CA Certificate Policy, the CA/Browser Forum’s Baseline Requirements, and direct inquiries from Mozilla representatives. Article source
  6. My monitoring scripts raised an alert a few days ago: Microsoft has just quietly updated its Root CTL (Certificate Trust List), increasing its size to 356 roots. The official channels, which normally announce and document such updates well in advance, are oddly silent about this one, and the new CTL is already being pushed to all Windows systems (including servers). A quick RCC scan (shameless plug!) highlights the following entries as new: 1e0e56190ad18b2598b20444ff668a0417995f3f LU LuxTrust Global Root 2 5463283b6793ff55277cede39098e80422f912f7 CO AC Raiz Certicamara S.A. 3143649becce27eced3a3f0b8f0de4e891ddeeca TR TUBITAK Kamu SM SSL Kok Sertifikasi Surum 1 e252fa953feddb2460bd6e28f39ccccf5eb33fde HR SZAFIR ROOT CA2 3f0feb17a7ef5804cfd90a77b7bb021ea69c6418 GR BYTE Root Certification Authority 001 a69e0336c4e59023ff653c71f928eb73f21c00f0 CA Carillon Information Security Inc. d99b104298594763f0b9a927b79269cb47dd158b TW ePKI Root Certification Authority - G2 81ac5de150d1b8de5d3e0e266a136b737862d322 TW ePKI Root Certification Authority - G2 c3197c3924e654af1bc4ab20957ae2c30e13026a US SSL.com Root Certification Authority ECC b7ab3308d1ea4477ba1480125a6fbda936490cbb US SSL.com Root Certification Authority RSA 4cdd51a3d1f5203214b0c6c532230391c746426d US SSL.com EV Root Certification Authority ECC 1cb7ede176bcdfef0c866f46fbf980e901e5ce35 US SSL.com EV Root Certification Authority RSA d3dd483e2bbf4c05e8af10f5fa7626cfd3dc3092 PL Certum Trusted Network CA 2 d496592b305707386cc5f3cdb259ae66d7661fca ES ACA ROOT Trusting new CAs is always a big deal, so advanced users and enterprise admins may use the above list to research these new roots and decide which ones they actually want to trust. And I'm currently working on a trust store hardening product, which will make it easy to drastically reduce your exposure to unnecessary CAs. Stay tuned! Article source
  7. Yahoo Is Still Vulnerable The first thing you should do after getting your home or apartment robbed is, obviously, change the lock. Yahoo doesn’t seem to think so, as the same practices that were in place when it got breached are still being used according to a new report by Venafi. What’s more, its practices have for years been known as unsecure. Venafi puts it simply: if you’re a Yahoo user, you should be worried about this. Here’s what it did (or, didn’t do): most importantly, 27 percent of certificates on external Yahoo sites haven’t been changed since January 2015. "Replacing certificates after a breach is a critical mitigation practice; unless certificates are replaced breached organizations cannot be certain that attackers do not have ongoing access to encrypted communications", Venafi says. In the last 90 days, 519 certificates have been issued, which leads Venafi to conclude that Yahoo "does not have the ability to find and replace digital certificates", something it considers a common problem. Also, Venafi says that a "surprising" number of Yahoo digital certificates use MD5, a cryptographic hashing function which is known to be vulnerable to brute force attacks. Almost half (41 percent) of external Yahoo certificates use a hashing algorithm deemed unsecure. "In our experience major breaches, such as the one suffered by Yahoo!, are often accompanied by relatively weak cryptographic controls", says Alex Kaplunov, vice president of engineering for Venafi. "To confirm this assumption we took an in-depth look at external facing Yahoo! web properties and the details of how these sites are using cryptography. We found the encryption practices on these properties to be relatively weak. This is not surprising. In our experience most enterprises, even global brands with deep cyber security investments, have weak cryptographic controls". Source
  8. Mozilla may also ban StartCom certificates as well Mozilla is pondering applying a one-year-long ban on all newly issued SSL certificates from Chinese CA (Certificate Authority) WoSign, and Israeli CA StartCom, which WoSign appears to have secretly bought last year. Mozilla's engineers announced the potential ban following an investigation into a series of suspicious SSL SHA-1 certificates issued by both companies. The full investigation report can be read below this article. Both CAs have tried to avoid the SHA-1 ban The issues revolve around a common decision that browser makers took last year, to stop accepting SSL certificates signed via the ancient SHA-1 algorithm starting with January 1, 2016. Mozilla is accusing WoSign that they've been issuing SHA-1-signed certificates and back-dating them to December 2015. While Mozilla has allowed other CAs to issue SHA-1 certificates after January 1, 2016, for example Symantec, they only allowed it if the CA went through a complex approval process, which apparently WoSign has dodged. WoSign has hidden the StartCom acquisition Furthermore, WoSign seems to negate that it bought Israeli CA StartCom. Mozilla says, backed up by a Hebrew-speaking lawyer, that WoSign has 100 percent ownership over the Israeli CA since November 1, 2015. To back up is claims, Mozilla revealed technical details that sustain its statements, showing that StartCom has started issuing certificates using WoSign's infrastructure. Mozilla also accused StartCom of engaging in back-dating 2016 SHA-1 certificates to December 2015, just like WoSign. The Foundation's security engineers detail one case where this has happened. StartCom has also back-dated SHA-1-signed certificates The Mozilla investigation uncovered how Tyro, a payments processor that has worked with the GeoTrust CA for years, has all of a sudden deployed an SHA-1-signed certificate in the middle of June using StartCom, a CA it never worked with. The certificate was dated as issued on December 20, 2015, a date on which Mozilla engineers found that StartCom has issued a large number of SHA-1-signed certificates. Mozilla discovered that companies deployed these certificates in the middle of 2016, and not right away, a clear sign that they were back-dated to avoid the SHA-1 ban. These incidents and many more are now making Mozilla engineers ponder the idea of untrusting WoSign and StartCom SSL certificates in Mozilla for a year. A permanent ban may be appplied Mozilla says this temporary ban will be applied only to newly issued certificates from both companies, and not to certificates already deployed at their customers. If the two companies don't pass a series of tests after the one-year ban, Mozilla is ready to ban all certificates from both companies for good. "Many eyes are on the Web PKI and if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots," the report says. Furthermore, a ban in Chrome and other products is also on the table. "While other browser vendors and root store operators will need to make their own decisions, we have laid out the information in this document so that they will understand the basis on which we have made our decision and can make their own decisions accordingly," Mozilla said. Article source
  9. StartSSL faces another issue that lets attackers obtains SSL certificates for domains they don't own StartEncrypt service logo Thijs Alkemade, a security researcher for Dutch security firm CompuTest, has discovered multiple design and implementation flaws in StartEncrypt, a tool created by Israeli company StartCom for issuing free SSL certificates. StartCom, the CA (Certificate Authority) behind the StartSSL service, launched the StartEncrypt project on June 4, inspired by the success of the Let's Encrypt project. Users who want to deploy free StartSSL certificates can take advantage of their StartEncrypt offering. They only need to download a Linux client they're supposed to upload to their servers. This client performs a domain validation process, informs the StartSSL service, which then issues and installs an "Extended Validation" SSL certificate for the domain it has found running on the server it has just checked. StartEncrypt contains design and implementation flaws According to CompuTest, this validation process is flawed, and through a few tricks, it allows server owners to receive SSL certificates issued for other domains, such as Facebook, Google, Dropbox, etc., which can be sold on the black market or used in man-in-the-middle attacks. The first issue Alkemade discovered in the StartEncrypt client was a design-related problem linked to the fact that users could manually configure the folder from where the client would download a signature from the server. An attacker would only have to point the tool to a folder on their server holding the signature of another domain. These domain signatures can be extracted from any sites that allow users to upload files: GitHub, Dropbox, etc.. StartEncrypt bug combined with OAuth 2.0 protocol condition The second issue is far more serious because it enabled an attacker to obtain SSL certificates for even more domains than the ones before. According to the researcher, one of the API verification calls contains a parameter dubbed "verifyRes," which takes a URL as input. This means the client was exposed to Open Redirect vulnerabilities. In other words, an attacker could forge this request and point the tool off-domain to a server not under their control. But this feature is not that easily exploitable. The domain URL to which the attacker needs to point the tool must (1) allow users to upload files and serve them back in raw format; or (2) to contain an Open Redirect issue of its own. While the first condition was quite rare, the second was not. All websites that support OAuth 2.0, a specification that powers social login features, must allow open redirects for the protocol to function properly. A crook leveraging this OAuth 2.0 condition and the StartEncrypt client could fool the StartSSL service into issuing a free SSL service in their name for any site that provides OAuth 2.0 support, such as Facebook, Twitter, Yahoo, Microsoft, and so on. Multiple other issues discovered as well Additionally, CompuTest also found that StartEncrypt doesn't check its own server's certificate for validity when connecting to the API, meaning crooks could receive verification requests and issue false SSL certificates for users trying to use StartEncrypt. The API also doesn't check the content type of the file it downloads for verification, so attackers can obtain certificates in the name of third-party websites where users can upload their avatars. At the same time, the certificate private key, which must be private, is stored with 0666 permissions in a public folder, so everyone could read it. Furthermore, just like Let's Encrypt, StartEncrypt is vulnerable to a Duplicate-Signature Key Selection attack. "In our opinion, StartCom made a mistake by publishing StartEncrypt the way it is," CompuTest's Christiaan Ottow explains. "Although they appreciated the issues for the impact they had and were swift in their response, it is apparent that too little attention was paid to security both in design (allowing the user to specify the path) and implementation (for instance in following redirects, static linking against a vulnerable library, and so on). Furthermore, they didn’t learn from the issues LetsEncrypt faced when in beta." StartCom has released a new version of the StartEncrypt Linux client, with the same version number CompuTest says they reported other issues to the service, which are still being corrected and will be fixed in future updates. Back in March, StartSSL faced a similar issue with its general service, which also allowed crooks to receive SSL certificates for domains they didn't own. Article source
  10. Symantec is extending its Encryption Everywhere program to Australia, offering domain validated TLS/SSL certificates for free to lift global website encryption rates to 100 percent by 2018. "Encryption and privacy is not the same thing," said Nick Savvides, Symantec APAC cybersecurity strategy manager. Encryption is a privacy "enhancing tool", Savvides went on to explain, while privacy is more about handling what information is collected, how the collected information is handled, and what other data can be derived from it. The two are often confused because they are related: Encryption is used to maintain privacy. Savvides said that unfortunately most websites do not use encryption, highlighting the company's most recent Internet Threat Security Report, which revealed that 97 percent of active websites do not have any basic security and 75 percent have unpatched vulnerabilities, with 16 percent of those being critical. Meanwhile, the remaining 3 percent of active websites with security are banks and corporate businesses, according to Savvides. He said the IT security community often blames "lazy" users for the lack of encryption. However, he said the real hindrance is the complexity that is involved with encryption, and it's often something that users expect to be provided with. "They don't do [encryption] because it's hard; they only do it when they absolutely have to," he said. He pointed out that iMessage, Apple's built-in instant messaging service, and more recently mobile messaging app Whatsapp, are two examples of where end-to-end encryption is provided, and not something that users have to actively go seek. In turn, the security company has extended its partnership program, Encryption Everywhere to Australia, which is already live in North America and Europe. The program falls under Symantec's goal to achieve 100 percent encryption for all websites globally by 2018. Under the Encryption Everywhere program, Symantec has initially partnered with WHMCS and cPanel to hand out domain-validated TLS/SSL certificates for free, before taking a multi-tier paid model approach. "We'd like to see broader base encryption utilised across the world, across the internet. Whether it's ours or somebody else's, we'd like to see it adopted because it will make the internet a safer place, free from prying eyes," Savvides said. Survey findings from Norton by Symantec released on Tuesday indicated that online threats will not be slowing, particularly with the proliferation of the Internet of Things. The survey showed that while almost two thirds of Australians use at least one mobile app to manage their finances or control other connected devices, 66 percent do not have security software on their smartphones, and 33 percent choose not to have a password or PIN on these devices. Despite this, 61 percent of Australians admitted that they would be upset if their financial information was compromised. According to Mark Gorrie, Norton by Symantec APAC director, as the smartphone becomes a central control hub and a "gateway" to other devices, the onus is on both the vendor and the user to ensure security is top of mind. Gorrie, however, pointed out that historically, vendors have always seen security as an afterthought, but indicated that it has improved more recently. "Vendors should be taking seriously because it is such a big issue. We see the threats just keep growing every year, and just won't give up because it's a profitable business for a lot of people. There is definitely a responsibility security should rank highly on the devices vendors are releasing, but equally people have to be proactive to help themselves," he said. Article source
  11. Malware authors are keeping pace with recent CA changes Malware sample signed with SHA1 and SHA2 certs The impending doom of all SHA1 certificates is also having an impact on the malware scene, not just legitimate website owners and software vendors. In a recent report, cyber-security vendor Symantec reveals that it discovered a malware family that came signed by not one, but two digital certificates, one with an SHA1 signature, and a second, a backup certificate, with an SHA2 signature. This specific malware was the Carberp financial trojan, detected in a recent spam campaign targeting users in Denmark, Sweden, Israel, Ethiopia, and the US. As the security researchers explain, the trojan was one of the first instances they saw where malware came signed by dual certificates to account for the recent shift in the tech sector to SHA2 after SHA1 was declared unsafe last fall. Expect more malware signed with dual SHA1 & SHA2 certificates The technical reasons for signing their malware with SHA2 are evident. Most software vendors, and especially Microsoft, whose products most malware targets, have announced plans to discontinue support for new SHA1-signed certificates starting January 1, 2016. Future plans will include removal of support for SHA1 in its entirety. Having an SHA2 backup certificate allows the malware to fall back on a safety net in case the SHA1 certificate triggers validation errors. SHA1 won't likely be removed from current-day malware since it allows attackers to target older operating systems where SHA1 is the main digital cert-signing mechanism, where SHA2 is not supported, and where most of the juicy, unpatched vulnerabilities still exist. The funny thing is that while malware operators have already implemented fallback systems, some legitimate site operators are having problems and are seriously lagging behind with SHA2 migration. Just last month, Mozilla had to issue a temporary pass to a Symantec client who needed nine new SHA1 certificates issued in his name, even if the deadline passed and the company should have already been well on its way into running SHA2. Article source
  12. Payments processor blunder revealed, company wants mercy Mozilla has decided to grant an exemption to to its SHA-1 certificate ban and allow Symantec to issue nine new certificates for one of its clients Worldpay PLC. Back in the autumn of 2015, a team of researchers managed to discover that SHA-1 certificates were not as safe as they were once considered after breaking its encryption algorithm with far less hardware and financial resources than previously estimated. This event sparked a frenzy among tech companies and certificate authorities who announced that starting with January 1, 2016, they will not "trust" SHA-1-based certificates and that any CA (certificate authority) that issues one will be banned in the products of the CA/Browser Forum (meaning all browsers). Organizations like Mozilla, Microsoft, and later Google, announced that they would reinforce the ban by not honoring any new SHA-1 certificates issued after January 1, 2016, and later stop supporting any type of SHA-1 certificates after June 30, 2016, or January 1, 2017. Symantec is asking for an exemption for one of its clients According to a discussion on the Mozilla security mailing list, Symantec is now asking for an exemption to this rule. A company representative has informed Mozilla that one of its clients, Worldpay PLC, has asked for nine new SHA-1 certificates. Symantec explains that Worlpay has forgot to ask for nine new SHA-1 certificates for some of its servers that process SSL/TLS communications for over 10,000 payment terminals across the world. Worldpay blames this situation on a communications mishap. They say that someone forgot to ask for these certificates before the January 1 deadline. The company says they are already in the midst of the process of updating their servers to SHA-2, but this blunder now puts some of its users in dangers of not having their payments go through. Only Mozilla is on board with the exemption, not Apple, Microsoft, or Google Internally, Mozilla has agreed to allow Symantec to issue these certificates under two conditions: the entire process should be transparent, and that the certificates should expire after only 90 days. Mozilla will not mark these new SHA-1 certificates as insecure in its products, but it also said it cannot guarantee the same for the other CAs. Many security experts, including Mozilla's own, have argued that giving Worldpay a pass would only encourage other companies that failed to migrate to SHA-2 a similar reason to do so as well. Taking into account that Worldpay works with very sensitive financial information, Mozilla had a chance to prove a point about the need to reinforce the highest security standards for online transactions. Unfortunately, Mozilla failed, big time. Article source
  13. Starting on January 2016, Microsoft's Trusted Root Certificate Program will no longer include twenty currently trusted CAs and will remove their root certificates removed from the Trusted Root CA Store. The list looks like this: "This past spring, we began engaging with Certificate Authorities (CA) to solicit feedback and talk about upcoming changes to our Trusted Root Certificate Program. Among other things, the changes included more stringent technical and auditing requirements," Microsoft enterprise and security group program manager Aaron Kornblum explained. The company has been working with CAs to helpt them adjust to the new program prerequisites, but the CAs on the aforementioned list either would not or could not comply with the new requirements. What does this mean for customers who got their certificates from those CAs? "If you use one of these certificates to secure connections to your server over https, when a customer attempts to navigate to your site, that customer will see a message that there is a problem with the security certificate," says Kornblum. "If you use one of these certificates to sign software, when a customer attempts to install that software on a Windows operating system, Windows will display a warning that the publisher may not be trusted. In either case, the customer may choose to continue." Microsoft advises these customers to get a replacement certificate from another CA (one that will still be trusted). Article source EDITED: Change article
  14. Symantec didn't really care in September, doesn't care now Google has made good on its promise and banned root certificates issued by Symantec. The ban applies to Google Chrome, Android, and several other Google products. The search giant had a bone to pick with Symantec since late September when Google discovered 23 certificates issued in its name by one of Symantec's subsidiaries. Symantec tried to explain itself by saying the certificates were issued for internal tests and got leaked under unknown circumstances by three employees, who the company eventually fired. The incident escalated towards the end of October when Google discovered 164 other Symantec certificates issued for 76 other domains, along with a huge batch of 2,458 certificates issued for yet unregistered domains. Google published a statement on its blog, the equivalent of a last warning. It appears that now Google has decided to act on Symantec's arrogance/indifference and has outright banned the Class 3 Public Primary CA root certificate operated by Symantec. Google bans Symantec root certificate after the company strays off official standards "Symantec has decided that this root will no longer comply with the CA/Browser Forum's Baseline Requirements," said Ryan Sleevi, Google Software Engineer, today on the company's Security blog. "As these requirements reflect industry best practice and are the foundation for publicly trusted certificates, the failure to comply with these represents an unacceptable risk to users of Google products." Symantec did not provide any public statement on its site regarding Google's latest decision. Mr. Sleevi said Symantec has privately told Google that the particular root certificate the company was banning was not scheduled to be used to issue any new certificates for publicly-trusted connections. Symantec also told Google that they don't "believe" any of their clients that use Symantec-issued certificates will be affected by this ban. This ban is the result of an audit Google did of Symantec's certificates after the previous two incidents. This is not the first time Google has banned root certificates from a CA (Certificate Authority), the company applying the same punishment for Dutch-based CA Diginotar back in 2011, and the CNNIC CA in March 2015. News source
  15. The backdoor must be installed starting with January 1, 2016 In one of the most stupid thing a country's government can ever do, Kazakhstan's elected officials passed a law that says that all Internet users shall install a "national security certificate" starting with January 1, 2016. All certificates will be distributed through local Kazakh telcos, and the country's biggest ISP has already announced the procedures on their site. Following the intense local and international backlash regarding this update, the Kazakhtelecom page has been taken down (Google Cache version here). By forcing all Internet users to install their national "security" certificates, the local government effectively has a backdoor on each device, allowing it to sniff encrypted Internet traffic. Of course, this certificate can also be abused by cyber-criminals, who can use it to perform man-in-the-middle attacks, especially for collecting financial details transmitted via online payments. Technology firms may force the government to drop its plan The national security certificates will have to be installed by each user, on all types of devices, including tablets and smartphones, not just desktops and laptops. If Kazakhstan decides to go through with this plan, users in Kazakhstan will be in the same unfortunate position as Lenovo or Dell clients, who in recent months have been exposed in similar incidents, with Lenovo and Dell shipping devices with root certificates in the famous Superfish and eDellRoot scandals. Fortunately for Kazakh Internet users, companies like Microsoft, Google, or Apple have the power to block certificates by issuing security updates to disable these certs inside their operating systems (Windows, Android, OS X, or iOS). Despite all their malicious intentions, the Kazakhstan government may find itself and its users blackballed from the Internet if these companies decide to issue security updates specifically targeting those certificates. For now, in spite of the huge international criticism, Kazakhstan has not announced if it plans to go through with its initial plan. News source
  16. LeeSmithG

    [ALISON] Free courses and diploas

    My son signed up for it earlier, I decided to check it out and on the surface seems good. They are free. https://alison.com/course/
  17. A piece of malicious adware dubbed “Vonteera” tricks the operating system into thinking that digital certificates from security companies are untrusted in an effort to prevent anti-malware products from blocking it. Anti-malware firm Malwarebytes initially detected the threat as a piece of adware that installs potentially unwanted programs (PUPs), but it has now decided to classify it as a Trojan (Trojan.Vonteera) due to the modifications it makes on an infected system. Other security companies have also classified Vonteera as a piece of malware. When it infects a system, Vonteera creates several tasks in the Windows Task Scheduler. These tasks are used to display ads at regular intervals by opening new tabs in the web browser. The threat also creates a new service called “appinf.exe” and modifies desktop, taskbar and start menu shortcuts for Internet Explorer, Firefox, Chrome, Opera and Safari. By modifying the shortcuts, Vonteera ensures that whenever one of these applications is launched, they load a script designed to randomize where users get redirected when they open the browser. In the case of Internet Explorer, the threat adds a new Browser Helper Object (BHO). If Chrome is present, it abuses the ExtensionInstallForcelist key, which specifies a list of apps and extensions that are installed silently and granted all the permissions they request. These apps and extensions cannot be uninstalled by the user. Malwarebytes started classifying Vonteera as a Trojan after researchers noticed that the adware adds a total of 13 certificates to “Untrusted Certificates” in the Windows certificate store. The certificates are for ESS Distribution, Avast, AVG Technologies, Avira, Baidu, Bitdefender, ESET, Lavasoft, Malwarebytes, McAfee, Panda Security, ThreatTrack Security and Trend Micro. By adding them to “Untrusted Certificates,” the malware ensures that applications signed with these certificates cannot be executed. It also prevents files from being downloaded from websites that use these certificates. The appinf.exe service created by Vonteera is designed to check for the presence of these certificates and puts them back if they are removed by the user. Since execution of the antivirus programs is blocked by the User Account Control (UAC) feature in Windows, users can get security products to run again by disabling UAC, although experts advise against doing this. Another option is to bypass UAC by using a Task Scheduler trick described by Malwarebytes earlier this year. Alternatively, users can remove the certificates from Untrusted Certificates via the certificate management console in Windows (certmgr.msc). News source
  18. Symantec employees mistakenly leak test SSL certificates Symantec was forced to fire 3 employees after Google's engineers found rogue SSL certificates issued in its name used in the wild. SSL certificates are a technology through which browsers and Web service providers create a secure and authorized channel of communication. They are used billions of times each day and have become a common practice in securing communications between users and banks, online shops, social networks, and about any website that wants to protect its users and their private data from hackers and privacy-intruding government agencies. Responsible for issuing these certificates is a Certificate Authority (CA). There are numerous CAs around the world, all of which are recognized and trusted by browsers makers to issue certificates to authorized and trustworthy clients only. One of those CAs is Symantec, a cyber-security vendor known primarily for its Norton antivirus engine. Google's Certificate Transparency project was first to note the rouge SSL certs This Friday, September 18, Google's engineers working for Certificate Transparency, a project that double checks for rogue SSL certificates used in the wild, has found a series of fake Google.com SSL certificates that were issued by Symantec. These rogue certificates were also observed by DigiCert's technicians in their logs as well. What's worse is that these certificates were issued with an "extended validation" label, which means that Symantec had supposedly carried out extra checks on the client that requested the certificates to validate its real identity, as Boing Boing reports. This information was not officially confirmed by either Google or Symantec in their press releases. Google has blacklisted the certificates in question. Since they were leaked only for a day, Google and Symantec don't believe they might have been used in real-world attacks. If hackers had had more time, these rogue SSL certificates could have been used in MitM (man-in-the-middle) attacks, allowing malicious actors to intercept secure communications between users and Google-operated services, like Gmail, Google+, YouTube, and such. Not the first time rogue SSL certificates are detected in the wild This is not the first time that this has happened. In 2011, Dutch-based CA Diginotar was breached and hackers issued hundreds of fake certificates. Some of these SSL certificates (also issued in Google's name) were used by the Iranian government to spy on political dissidents. The Diginotar incident was what convinced browser makers and certificate authorities around the world to create the Certificate Transparency project. The same thing happened in December 2013, when ANSSI also mistakenly issued fake Google certificates, and at the end of March this year, when the CNNIC CA issued some unauthorized digital certificates for several Google domains. After the last incident, Mozilla and Google banned all CNNIC existing root and extended validation SSL certs. Symantec has addressed the issue by firing the employees at fault Investigating its recent incident, Symantec was quick to follow suite with Google's inquiries in this matter, fearing the ax above its head. According to their official statement, the company says that these rogue certificates were issued for tests inside the company, and they were immediately revoked when Google notified them of the leak. "We discovered that a few outstanding employees [...] failed to follow our policies," said Quentin Kiu of Symantec. "Despite their best intentions, this failure to follow policies has led to their termination after a thoughtful review process. [...] As much as we hate to lose valuable colleagues, we are the industry leader in online safety and security." Source
  19. Google has identified and blocked unauthorized digital certificates for a number of its domains issued by the National Informatics Centre (NIC) of India, a unit of India’s Ministry of Communications and Information Technology. National Informatics Center (NIC) holds several intermediate Certification Authority (CA) certs trusted by the Indian government’s top CA, Indian Controller of Certifying Authorities (India CCA), which are included in the Microsoft Root Store and so are trusted by a large number of applications running on Windows, including Internet Explorer and Chrome. The use of rogue digital certificates could result in a potentially serious security and privacy threat that could allow an attacker to spy on an encrypted communication between a user’s device and a secure HTTPS website, which is thought to be secure. Google became aware of the fake certificates last Wednesday on July 2 and within 24 hours, the Indian Controller of Certifying Authorities (India CCA) revoked all the NIC intermediate certificates and also issued a CRLSet to block the fraudulent certificates in Chrome. CRLSets enable Chrome to block certificates in an emergency. The search engine giant believes that no other root stores include the Indian CCA certificates, which means that Chrome on any other operating systems, Chrome OS, Android, iOS and OS X were not affected. “Additionally, Chrome on Windows would not have accepted the certificates for Google sites because of public-key pinning, although misused certificates for other sites may exist,” saidGoogle security engineer Adam Langley. Langley added that “Chrome users do not need to take any action to be protected by the CRLSet updates. We have no indication of widespread abuse and we are not suggesting that people change passwords.” It’s the second high-profile incident of a government agency caught issuing fake SSL certificates since December, when Google revoked trust for a digital certificate for several of its domains, mistakenly signed by a French government intermediate certificate authority. Google has taken many measures to advance the security of its certificates, as SSL certificates are still one of the core elements of online security and still, since hundreds of entities issue certificates, it makes the company difficult to identify fake certs that aren’t following proper procedures. One such measure is Google’s recently launched Certificate Transparency project, which provides an open framework for monitoring and auditing SSL certificates in nearly real time. Specifically, Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. DigiCert was one of the first Certificate Authority’s to implement Certificate Transparency after working with Google for a year to pilot the project. Google also upgraded its SSL certificates from 1024-bit to 2048-bit RSA to make them more secure and unbreakable. Because longer key length would make it even more difficult for a cyber criminal to break the SSL connections that secure your emails, banking transactions and many more. Source