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 9 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. 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
  • Create New...