2014 Все новости про сертификаты

28/11/2014 Thawte

New and Improved Authentication Document Upload and Management
Phase 1 High-Level Overview:

• Authentication emails will include an order-specific document upload link which points to a brand-specific document upload user interface (portal) if a document is required.
• Documents will be uploaded directly into the correct order in the order vetting tool, as opposed to a separate fax or email queue.
• Uploaded documents will be automatically retrieved for subsequent orders for the same organization and/or domain, making authentication easier.

26/11/2014 Thawte

Certificate Transparency; the Next Change for SSL Certificates
Starting in February 2015, Certificate Authorities must log Extended Validation certificates in publically auditable logs. Lean more...

Increase Online Sales
Are you an online retailer looking to boost your online sales this holiday season?

24/11/2014 Symantec

Latest Website Security Solution Updates

Market Leaders in terms of OCSP and Seal services response time
We have recently made significant enhancements to our OCSP and Seal infrastructure. We are the market leaders in terms of the fastest OCSP and Seal response times in almost every market globally. As a result, customers will experience improved page load performance on sites.

True Business ID EV Certificates signed by a different intermediate
Per our recent communication the GeoTrust intermediates are changing. Please note that when a True Business ID EV certificate is replaced, with or without a change in the certificate order, the intermediate will need to installed. The intermediate that will sign the certificate will be GeoTrust EV SSL CA – G4.

Certificate Transparency
On December 9, 2014, we will be rolling the Certificate Transparency (CT) feature for all EV certificates whereby all EV certificate enrollment (starting December 9th) will be publicly logged with CT proof in the Google CT logs. This will ensure that the green bar appears in Chrome when Google rolls out the Certificate Transparency feature in Chrome in February 2015.

Sha-256: Default Hashing Algorithm
On December 9 2014, Sha-256 will the default hashing algorithm for certificate enrollments, renewals and replacements. Furthermore, in accordance to the upcoming web security policy, the term validity of any new Sha-1 SSL certificate enrollment will be restricted to December 31, 2016, or sooner.

The Poodlebleed Bug

Poodlebleed is a vulnerability in the design of SSL version 3.0. Poodle is actually an acronym for Padding Oracle On Downgraded Legacy Encryption. The vulnerability allows the decryption to plaintext of secure connections. The bug was discovered by Google Security Team researcher Bodo Möller in collaboration with Thai Duong and Krzysztof Kotowicz.

Although SSL 3.0 is almost 15 years old, many servers and web browsers still use it today. When web browsers fail at connecting on a newer SSL version (i.e. TLS 1.0, 1.1, or 1.2), they may fall back to a SSL 3.0 connection. This is where the trouble begins. Because a network attacker can cause connection failures, including the failure of TLS 1.0/1.1/1.2 connections, they can force the use of SSL 3.0 and then exploit the poodle bug in order to decrypt secure content transmitted between a server and a browser. For nitty-gritty details on what exactly the poodlebleed bug is, please see the pdf announcement under resources. more...

Certificate	Expiration	Chrome 39 (November)	Chrome 40 (After holidays)	Chrome 41 (Q1 2015)
abc.adgrafics.net	2017-03-18
abc2.adgrafics.net	2016-08-17
abc3.adgrafics.net	2016-05-20

SHA-1 Sunsetting, Google, and Your Next Steps.

What is happening, and what was happening?

The SSL Industry and the CA/B Forum have planned for the "sunsetting" (depreciation) of the SHA-1 signing algorithm for quite some time. However, their plan was mainly formed around Microsoft's desires to phase it out in 2017, alongside the end-of-life for Windows XP. This was widely understood to be the approved plan for CAs to follow, and the preparation for moving from SHA-1 to its successor, SHA-2, wouldn't be necessary for many months from now.

However, Google recently made an announcement, in stark contrast to Microsoft's plan, that they are implementing their own SHA-1 sunsetting timeline, which will begin on September 26^th 2014.

This timeline has three distinct stages, which will result in degraded visual indicators in Google Chrome (padlock, green-bar) for SHA-1 signed certificates meeting specific criteria (this is discussed in the section "What certificates are affected?" below).

This means it is now necessary to educate and assist our partners and customers on how to make the transition away from SHA-1.

Why?

First, let's understand what SHA-1 does. Both SHA-1 and its successor, SHA-2, are specific types of signing algorithms. Signing algorithms are used as part of the identity validation role that SSL certificates perform. They are mathematical functions (referred to as a "hash") which, when performed, should calculate a persistent and unique value for each file. So, for instance, the Word doc this text is stored in has a unique SHA-1 hash value. If I change a single part of this file – add an extra period somewhere, change a letter, etc. – it will produce a different SHA-1 hash value.

When a certificate is downloaded from a server to the client's browser, a hash is taken of it. The type of hash taken (SHA-1, SHA-2, MD5, etc.) depends on how the certificate is signed. The hash calculated by the browser is compared to the hash value provided by the server, which has been verified by the Certificate Authority (CA) at the time of issuance. If they match, the identity of the certificate and server are verified.

Accurate identification is very important for the CA Trust Model, and SHA-1 can no longer perform this. This is because SHA-1 is vulnerable to "collisions." This is when two different files produce the same hash value. This would allow someone to "forge" a certificate, and have a client's browser falsely verify a server's identity. This compromises a user's trust of the internet and browsers, and is precisely the reason that Google wants to get rid of SHA-1 quickly.

Google is amongst many parties who believe that "forging" a certificate signed by a SHA-1 hash is becoming easy. They also feel that in previous instances when CAs needed to transition to a new technology (in the switch from MD5 to SHA-1, and from 1024- to 2048-bit certificates) they did so slowly and poorly. For this reason, they are forcing the sunsetting of SHA-1 (and therefore, an upgrade to SHA-2) early.

When is this happening?

Google's policy involves three distinct steps, the first beginning on September 26^th. On this date, only customers with SHA-1 signed certificates expiring in 2017 are affected. However, the amount of affected certificates will expand in November, and again in Q1 2015. The full details on what certificates are affected is in the below section, "The Nitty Gritty."

What certificates are affected?

Certificates are affected if they meet the any of the following criteria:

• All certificates from the RapidSSL or QuickSSL family issued before September 15th, 2014 and expiring after January 31^st, 2016 (They are signed by a SHA-1 Intermediate).
• If they are signed with SHA-1 and expire after January 1^st, 2016.
• They have an Intermediate Certificate Chain that are SHA-1 signed certificates.

To understand the exact certificates affected, please see the below section which gives explicit detail.

The Nitty Gritty

On September 26^th, 2014:

SHA-1 signed certificates expiring on or after January 1^st, 2017 will be treated as "secure, but with minor errors" and will receive the yellow triangle padlock.

On November 7^th, 2014:

SHA-1 signed certificates expiring on or after June 1^st, 2016 to December 31^st, 2016 are treated as above. Certificates expiring after January 1^st, 2017 are treated as "neutral, lacking security." These certificates will receive a blank page icon, as seen with HTTP sessions.

In Q1 2015:

SHA-1 signed certificates expiring on or after January 1^st, 2016 to December 31^st, 2016 will continue to be treated as "secure, but with minor errors."

SHA-1 signed certificates that expire on or after January 1^st, 2017 are treated as "affirmatively insecure." This will be identified by the red "X".

1 The majority of this section comes from Google's official announcement:
http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html

How is the problem solved?

Affected certificates can be fixed by reissuing. (There are no situations where anything other than a reissue is needed.) Our vendors have sped up their implementation of SHA-2 compatible infrastructure due to Google's new policy.

Symantec has officially confirmed that their full product line will have a fully SHA-2 compatible chain "September 12, 2014, and generally available on September 15, 2014." ² Comodo's full product line is already ready for the SHA-2 transition and by default are now being issued as SHA-2. Certum has announced they will make SHA-2 Certificates available "this year", specifically they are targeting October. This deployment date for Certum may be delayed, so we know they will not be ready for Phase 1 of Google's rollout, but perhaps by Phase 2.

The biggest market at risk is probably China³ or Russia, due to their more extensive use of Windows XP. For the same reason, Enterprise and Government use is also of more concern than Consumer use.

2 Symantec's full statement: "Google has announced that it plans to phase out SHA-1 support via degraded visual indicators. The plan is for that to happen in the upcoming Chrome 39 release on September 26, 2014. Google's plan is still subject to change. To help partners respond to this change, Symantec has accelerated its plan to offer SHA-2 end-entity certs chaining to SHA-2 intermediates. We expect these to be available for testing (by API-integrated partners) in our pre-production environment on September 12, 2014, and generally available on September 15, 2014."

What does The SSLmagazin.com need to do?

We need to identify affected customers and inform them via email that it is necessary to perform: a) reissue your certificate to SHA-2. Some customers may also need to perform: b) install SHA-2 intermediate certificates.

It will be necessary for you to perform a) if you have a SHA-1 certificate, if this is what you selected during the enrollment process. This can affect certificates from any of our providers, and is more likely to affect older certificates.

If you have a certificate from the RapidSSL or Quick SSL product families then your certificate was signed by a SHA-1 Intermediate. This means that it must be reissued so it can be signed by their SHA-2 Intermediate and you must install the new SHA-2 Intermediate to your server. So, everyone who has these products needs to perform a) and b), regardless of if they already have SHA-2 subscriber certificate.

Customers with SHA-1 Comodo certificates also need to reinstall their intermediates once they receive their reissued SHA-2 subscriber certificates (though this has not been confirmed in a live environment – the intermediates may not need to be changed in all cases).

A guide should describe exactly how to do this. Because of the non-critical error presented by remaining on SHA-1, I do not think individual phone calls need to be made to customers for this issue. Mailing materials should also be prepared for resellers to provide a more technical understanding of the technology so they can properly inform and assist their customers.

Customers have to meet a few criteria to be affected: their subscriber certificate must be SHA-1 and their expiration date must fall within with Google's timeline. Alternatively, if their certificate is from the QuickSSL or RapidSSL family, they will need to reinstall their intermediate certificates (regardless of other criteria).

Ideally, we can identify customers who are using SHA-1 in order to avoid mass emailing people solely based on the above date criteria. GeoCenter provides this information, but it is unclear if the same is available from Comodo's Portal. There would be a method of analyzing each live certificate to determine this information, though I am unsure on the feasibility of developing such a tool.

Taking proactive action

I propose our generation process UI be changed to select SHA-2 by default. This will reduce legwork in transitioning customers again in the future. Customers who specifically want/need a SHA-1 certificate can still choose one via the process and a pop-up confirmation box.

The case for people who "need" a SHA-1 certificate is quite small. As previously mentioned, Windows XP is the largest platform with SHA-2 incompatibilities. However, the incompatibility is only with server identification (encryption still works), therefore resulting in the same degraded/absent padlock as Chrome will be presenting if they choose SHA-1. So, unless the customer thinks their user base contains more XP users than Chrome users, they have no reason to prefer SHA-1. The exception to this is specific cases where there is incompatibility amongst specialty networking/enterprise hardware and software.

29/10/2014

Certificate Transparency Impacts on Extended Validation SSL
Certificate Transparency (CT), a Google initiative, requires all Extended Validation (EV) SSL certificates, along with certificate details, to be registered in public CT logs before the end of January 2015 in order to continue having the green address bar displayed in Chrome.

Here are the steps that Symantec, Thawte and GeoTrust are taking to support CT:

Obtain Customer’s Approval for the Publication of “Internal” EV SSL Certificates
Existing EV SSL certificates that are not reachable (by Common Name or SAN) via the Internet will not be whitelisted (i.e. published on public CT logs) without the customers’ permission. This is in deference to the privacy policies of the organization. Published information cannot be removed from the public CT logs.

Automatic Whitelisting of Public-Facing EV SSL Certificates
EV SSL certificates on public-facing sites or servers will be automatically included in public CT logs (i.e. whitelisted) by Google prior to February 2015. This is to ensure that the display of the green address bar remains on for these sites.

Certificate Transparency (CT) Feature in Certificate Profile
A CT feature will be available with EV SSL certificate profile before February 2015 during certificate enrollments, replacements and renewals. This feature will allow you to enable or disable the publication of the EV SSL certificate in the public CT logs for your customers.

Symantec recommends that partners communicate these changes to their customers as soon as possible.

Google объявила, что наличие SSL сертификата будет учитываться при ранжировании сайтов в поисковой системе.

Этот шаг с их точки зрения должен побудить разработчиков уделять больше внимания безопасности данных, и, как следствие, привести к большему комфорту для пользователей. Таким образом, использование SSL-сертификатов — теперь вопрос не просто престижа и выбор клиентоориентированных компаний, но и тенденция, охватывающая Интернет в целом. Это, безусловно, важный шаг, ведущий к повышению безопасности и увеличению числа транзакций в сети.

На данный момент фактор шифрования данных с помощью SSL имеет не самый высокий вес среди остальных, но в дальнейшем будет непременно расти. Таким образом Google планируют дать вебмастерам время на постепенный переход всех своих проектов на стандарт HTTPS.

В компании считают, что вопросы веб-безопасности с каждым днем становятся актуальней и работа с ними приобретает все большее значение. Поэтому планируется запуск серии статей по TLS (HTTPS, также известен как HTTP над TLS, или Transport Layer Security), где разработчики смогут прояснить все необходимые для себя вопросы.

Идея о важности SSL-сертификатов не нова, а компания Symantec уже давно предлагает использование знака seal-in-search. Но теперь, помимо улучшенной поисковой выдачи за счет наличия https соединения, приобретение Symantec сертификата и использование иконки в поиске дает не только дополнительную степень доверия для пользователей, но и повышение позиций проекта в выдаче.

In the Wake of Unauthorized Certificate Issuance by the Indian CA NIC, can Government CAs Still be Considered “Trusted Third Parties”?

Short answer: Government CAs can still be considered “trusted third parties,” provided that they follow the rules applicable to commercial CAs.

Introduction

On July 8 Google announced that it had discovered several unauthorized Google certificates issued by the National Informatics Centre of India. It noted that the Indian government CA’s certificates were in the Microsoft Root Store and used by programs on the Windows platform. The Firefox browser on Windows uses its own root store and didn’t have these CA certificates. Other platforms, such as Chrome OS, Android, iOS, and OS X, were not affected. See http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html

In response to this news, Microsoft updated its Certificate Trust List and removed the ability of three Indian CA certificates (NIC CA certificates issued in 2007, 2011, and 2014 by the Indian CCA) to issue any certificates, and it issued a Security Advisory https://technet.microsoft.com/en-us/library/security/2982792

This blog post discusses the following issues that have been raised as a result of this incident:

• What Happened?
• What security and operational practices did the Indian CA follow, and were such practices consistent with current industry practice?
• What kind of oversight or audit was in place with the Indian CA? How was this sufficient?
• What other actions have been taken by browsers in response to this breach?
• What should have been done, what should be done in the future, and what can we learn from this incident?
• What are CASC members doing to improve certificate trust?

What Happened?

There are things that we know happened, and there are things that we do not yet know, but on June 25 the first of several unauthorized SSL/TLS certificates were issued by India’s National Informatics Centre (NIC), which operates under the supervision of India’s Controller of Certifying Authorities (CCA). Both NIC and CCA are part of India’s Ministry of Communications and Information Technology.

On July 2, Google became aware of some of the unauthorized digital certificates because they had been issued for several Google domains because Google codes its own certificates inside of its Chrome browser. Google notified the NIC, the CCA, and Microsoft about the certificates, and it included those bad certificates in its CRLSet (Google’s way of blacklisting certificates). On July 3, the CCA advised Google that the three NIC CA certificates had been revoked, and Google updated its CRLSet to include them. (See http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html Google Blog Post)

According to Microsoft’s Security Advisory, apparently 45 domain names were identified to be at risk, but the overall scope of misuse of the NIC’s subordinate CA certificates is unclear. We cannot tell from this Security Advisory whether someone other than NIC obtained a sub CA that was used to issue the SSL certificates; neither can we discern the degree of knowledge or intent by those responsible.

What security and operational practices did the Indian CA follow, and were such practices consistent with current industry practice?

It is interesting to note that the CCA’s Guidelines for the Issuance of SSL Certificates is only two pages long, which pales in comparison to the appropriate SSL certificate issuance practices published by Mozilla, the CA/Browser Forum, the WebTrust Task Force, and ETSI’s ESI Committee. NIC’s sparse assertion in its CPS that it queries domain registries before issuing SSL certificates seems inadequate as well. http://cca.gov.in/cca/sites/default/files/files/nicca%20cps%204.4.pdf .

At this early date, we do not have all of the information about the security measures that would have prevented this incident. Section 6.5.1 of the NIC’s CPS states that only authorized NICCA trusted personnel have access to the operating system and CA software, and other broad statements in sections 6.6 and 6.7 attempt to provide further assurance that file system integrity and logs are regularly checked, but these assertions are equivocal. It is also unclear which network security measures were in place. In January 2013 the CA/Browser Forum augmented then-current network security requirements with its Network and Certificate System Security Requirements. https://cabforum.org/network-security . Many of the likely causes of this incident have been addressed already in the CA/Browser Forum’s network security document, including network authentication and access, system configuration controls, and logging, monitoring, and patching.

As noted by Microsoft, Google, and others, these certificates enable man-in-the-middle spying on end users. Of the 45 domain names listed by Microsoft, 18 belong to Google and 27 to Yahoo. The CASC believes this reveals an intent by the party controlling issuance of certificates to disrupt the security of public users. Whether the cause of the NIC certificate misissuance was internal or external is not as important as the fact that it happened — the end result speaks for itself. In other words, whatever happened, it certainly was not consistent with current industry practice.

What kind of oversight or audit was in place with the Indian CA? How was this sufficient?

According to documents attached to NIC’s request to be included in Mozilla’s trust store Mozilla Bug #511380, NIC was independently audited by M/s CyberQ Consulting Pvt. Ltd. CyberQ’s 2010 audit statement asserts the audit met the CCA’s Guidelines and that those requirements are “equivalent to WebTrust 1.0”, but without more detailed information, it is difficult for the CASC to make that same conclusion. The NIC and the CCA are part of the same government department and the CCA approves the auditor. Section 31 of the “Information Technology Act 2000, Rules, Regulation & Guidelines” states the audit is supposed to include: “(i) security policy and planning; (ii) physical security; (iii) technology evaluation; (iv) Certifying Authority’s services administration; (v) relevant Certification Practice Statement; (vi) compliance to relevant Certification Practice Statement; (vii) contracts/agreements; (viii) regulations prescribed by the Controller; (ix) policy requirements of Certifying Authorities Rules, 2000” and at least twice per year, the CA is supposed to receive an “audit of the Security Policy, physical security and planning of its operation.”

Some browser root programs allow government CAs to submit government audits that are deemed “equivalent” to those used by private industry. This allowance is usually based on an understanding that a government CA is often required to use a government-mandated internal assessment scheme — something like http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf NIST SP 800-53A or HMG Information Assurance Maturity Model and Assessment Framework. It is assumed that the audit criteria used by government auditors are at least comparable to WebTrust for CAs or ETSI TS 102 042. Second, they must have experience and skill in conducting IT security audits, using a variety of information security tools and techniques, an ability to evaluate the criteria of the applicable audit scheme, and a proficiency in examining PKI systems. Most importantly, these auditors need to be separately accountable for the exercise of their independent professional assessment — they must be sufficiently independent from the subject of the audit to perform the third-party attestation function. In the wake of this incident and others in the last few years, the CASC questions whether this “internal audit equivalency” advocated by government CAs is still a viable approach. It is CASC’s understanding that some root stores are re-visiting policies that have allowed “internal audit equivalency.”

What other actions have been taken by browsers in response to this recent breach?

As mentioned above, Microsoft moved the three NIC intermediate CA certificates onto its list of Untrusted Certificates — essentially revoking the embedded system trust for these certificates. These three NIC CAs were responsible for issuing the sub CA(s) that, in turn, issued the unauthorized SSL certificates.

Because the CCA had informed Google that “only 4 certificates” had been misissued (even though Google was aware of others), Google subsequently responded “[we] can only conclude that the scope of the breach is unknown,” and in light of that, it was limiting the India CCA root certificate to the following domains and subdomains: gov.in, nic.in, ac.in, rbi.org.in, bankofindia.co.in, ncode.in, and tcs.co.in. Google Blog Post

We commend Microsoft and Google for taking these actions.

What should have been done, what should be done in the future, and what can we learn from this incident?

It is difficult for CASC to recommend additional changes to the oversight and regulation of government CAs when it is not clear which existing industry standards were implicated by this incident, and would have prevented it, had they been followed. It appears that unlike members of the CASC, the NIC did not follow any of the new industry guidelines adopted as a result of the Diginotar incident, such as the CA / Browser Forum’s Network and Certificate System Security Requirements, which includes audits and system testing that commercial CAs are required to have.

While there is no evidence that the misissued certificates were actually used in man-in-the-middle attacks, this incident further highlights why government CAs should be restricted and also why solutions like DANE (e.g. misissued certificates coupled with control over DNS) create a heightened risk that some government will attempt to spy on SSL/TLS communications. Regardless of whether governments should be trusted, the CASC believes that government CAs should meet the same standards as commercial CAs and that any future application for root inclusion by a government CA under an “equivalency scheme” should be examined with much greater scrutiny. And if government CAs cannot meet all current commercial standards, then those government CAs should be technically constrained to act only within the scope of their own countries’ domain names and issue certificates only for their own government domains.

What are CASC members doing to improve certificate trust?

Additional steps that CASC members are taking to improve certificate trust, in connection with the activities of other organizations, include:

• promoting OCSP stapling and must-staple – CAs already provide certificate revocation checking (CRLs) and certificate status information (OCSP), and OCSP stapling with must-staple is a newer and better method of quickly delivering certificate status information to end users and stopping man-in-the-middle attacks;
• implementing Certificate Transparency (CT) – CT is a Google initiative that requires early disclosure and logging of publicly trusted SSL/TLS certificates, which Google believes will provide an early warning of misissued certificates, similar to the way Google identifies misissued Google certificates;
• considering the Certificate Authority Authorization (CAA) record in DNS – because CAA allows a domain owner to advertise which CAs it trusts (thereby enabling additional detection of certificate misissuance); and
• publishing network and certificate system security requirements – which all public CAs are now being audited against.

Критическая уязвимость CVE-2014-0160 в OpenSSL

ЧТО РЕКОМЕНДУЕТСЯ ПРЕДПРИНЯТЬ

1. Установить версию — 1.0.1g
2. В случае невозможности обновления - перекомпилировать OpenSSL с флагом -DOPENSSL_NO_HEARTBEATS
3. Перевыпустить сертификат по новому запросу CSR *
4. Проверить корректность работы нового сертификата на ProverkaSSL.com *
5. Отозвать старый сертификат **
6. Предупредить своих пользователей о возможной утечке их паролей. Рекомендовать им сменить пароли.

Сотрудники The OpenSSL Project выпустили бюллетень безопасности, в котором сообщается о критической уязвимости CVE-2014-0160 в криптографической библиотеке OpenSSL.

18/09/2014

Important Service Announcement on SHA-1

Google has announced that it plans to phase out SHA-1 support via degraded visual indicators. These changes are expected to take effect in the production version of Chrome version 39 planned for November 2014. To help partners respond to this change, Symantec has accelerated its plan to offer SHA-2 end-entity certs chaining to SHA-2 intermediates.

Testing (for UI and API) in our pre-production is available today! Please advise partners that with the launch of the newly available SHA-2 end-entity certificates we will also introduce new SHA-2 intermediate certificates. These new intermediate certificates need to be installed when the end-entity certificates are replaced. Replace ALL certificates that expire beyond December 31, 2015 with SHA-2 cert at no additional cost via the existing reissue workflows. 

The SHA-2 intermediate certificates are available today

The SHA-2 pre-production Intermediate Certificate Authorities are available at the following locations:

• http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7203871%2CbnKHklk - Symantec SHA-1 information page
• Symantec
  • http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475540%2CbnKHklk Root CA
  • Intermediate CAs - 1. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475541%2CbnKHklk OV SSL 2. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475542%2CbnKHklk EV SSL
• Thawte
  • http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475543%2CbnKHklk Root CA
  • Intermediate CAs - 1. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475544%2CbnKHklk OV SSL 2. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475545%2CbnKHklk EV SSL   3. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475546%2CbnKHklk DV SSL
• GeoTrust
  • Root CA - 1.  http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475547%2CbnKHklk OV SSL  2. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475548%2CbnKHklk EV SSL
  • Intermediate CAs - 1. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475549%2CbnKHklk OV SSL   2. http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475550%2CbnKHklk EV SSL
• RapidSSL
  • http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475551%2CbnKHklk Root CA
  • http://www.imakenews.com/eletra/go.cfm?z=symantec_channel%2C710684%2CbmvdPPsQ%2C7475552%2CbnKHklk Intermediate CAs

12/09/2014

We would like to inform you of Google’s intent to phase out support for certificates using a SHA-1 hashing algorithm via degraded visual indicators and warnings in the Chrome™ browser. This plan affects all SHA-1 and SHA-2 certificates as they are issued off a SHA-1 intermediate, in all the brands. It is expected to take effect by the production version of Chrome 39 in November 2014, and impacts certificates that expire after December 31, 2015. You can find more information regarding the proposed plan on Google's blog.

As a proactive measure, in order to help ensure that Chrome 39 users who visit your customers’ websites do not encounter any UI degraded indicators, Symantec recommends the following actions:

1. Provide customers the ability to replace their affected SHA-1 certificates with SHA-2 certificates issued off a new SHA-2 intermediate via existing reissue workflows. Symantec will provide an updated SHA-2 test environment hierarchy on Sept 12, 2014 and SHA-2 production hierarchy on September 15, 2014.
2. Communicate the following to your customers:

Replace ALL certificates that expire beyond December 31, 2015 with SHA-2 cert at no additional cost via the existing reissue workflows.  Here are some additional resources for you and your customers:

• adgrafics SHA-1 information page

Атака на финансовые учреждения России

Following on from yesterday’s theme of  European banks suffering distributed denial-of-service (DDoS) attacks similar to that of their US counterparts , recent news reports reiterate that it’s not only DDoS attacks that the banks need to worry about.

One particular threat  is using a stolen digital signature in order to falsely authenticate its actions: spoofing Russian banking transactions to send funds from a user’s bank account to an account of the attacker’s choosing. A Java program developed by the attackers is being used to inject instructions into an online banking software developed by a Russian company called BIFIT (Banking and Financial the Internet—Technics of Open Company). Symantec confirms that this malware is currently being detected as Backdoor.Jabeefit —we are continuing to investigate the samples and will update this blog soon.

Furthermore,  MICEX , one of the leading Russian stock exchanges and the biggest trading venue in Eastern Europe, has also http://www.group-ib.com/index.php/7-novosti/722-group-ib-online-trading-and-stock-broking-is-in-the-hackers-interest come under attack . Two trading software programs ( http://arqa.ru/eng/quik/ QUIK  and  http://www.egartech.com/product_focus.asp FOCUS ) that are used by many large banks in Russia have been infected on a number of computers and are allowing attackers to monitor a user’s financial transactions by http://www.fiercecio.com/techwatch/story/malware-targets-online-trading-software/2013-04-19 taking screenshots and stealing banking credentials which are then sent to a command-and-control (C&C) server.

Symantec customer? No. None of the companies mentioned, QUIK, FOCUS, nor the MICEX exchange, are Symantec customers

Symantec™ SSL Certificates Now Include DSA Algorithm Option

Now Symantec™ SSL certificates also include a DSA algorithm certificate—at no additional cost—to give your clients more security options and help them make it easier to keep up with evolving government requirements.

DSA (Digital Signature Algorithm) is a government-approved, DSS- and FIPS-certified encryption algorithm that was developed by the National Security Agency in 1991 as an alternative to the RSA algorithm. It offers the same level of security and performance as RSA, but uses a different mathematical algorithm for signing and encryption.

With both RSA and DSA algorithm options for Symantec-branded SSL certificates, you and your customers have greater flexibility for protecting their websites and internal network communications, plus partners and customers now have additional features not offered by other SSL providers. You can choose to run just RSA, just DSA, or both to enhance website security. Running multiple algorithms together helps protect your clients' data with a broader array of encryption options. For example, Apache can support both RSA and DSA certificates in tandem on a single web server. The result: You maximize the ecosystem reach to everyone your customers company does business with. And they get it all—more choice, greater flexibility, and an additional security option—at no additional cost. Due to the new NIST Suite B security requirements for hashes and algorithms, and in accordance with CA/B Forum guidelines Symantec will only be issuing 2048-bit RSA certificates, with an option of SHA-1 or SHA-256. All DSA 2048-bit compliant certificates will include SHA-256.

Symantec takes the security and proper functionality of its solutions very seriously. The Trust Services (SSL) and User Authentication (VIP, PKI, FDS) and other production systems acquired by Symantec were not compromised by the corporate network security breach mentioned in the VeriSign, Inc. quarterly filing.

Production systems that are now a part of Symantec, were inaccessible from the corporate network breached at VeriSign, Inc. Symantec's production systems remain completely secure.

• Symantec blocked a total of over 5.5 billion malware attacks in 2011, an 81% increase over 2010.
• Web based attacks increased by 36% with over 4,500 new attacks each day.
• 403 million new variants of malware were created in 2011, a 41% increase of 2010.
• SPAM volumes dropped by 34% in 2011 over rates in 2010.
• 39% of malware attacks via email used a link to a web page.
• Mobile vulnerabilities continued to rise, with 315 discovered in 2011.
• Only 8 zero-day vulnerabilities were discovered in 2011 compared with 14 in 2010.
• 50% of targeted attacks were aimed at companies with less than 2500 employees.
• Overall the number of vulnerabilities discovered in 2011 dropped 20%.
• Only 42% of targeted attacks are aimed at CEOs, Senior Managers and Knowledge Workers.
• In 2011 232 million identities were exposed.
• An average of 82 targeted attacks take place each day.
• Mobile threats are collecting data, tracking users and sending premium text messages.
• You are more likely to be infected by malware placed on a legitimate web site than one created by a hacker.

Symantec Corp. (NASDAQ: SYMC) announced it has adopted the Certification Authority Browser (CA/B) Forum Baseline Requirements. As the largest issuer of SSL certificates worldwide and an active member of the CA/B Forum, Symantec has driven and adopted the Baseline Requirements to further strengthen the security around SSL operations and authentication processes for greater protection and trust in online transactions.

The requirements include enforcing more stringent verification of identity and guidelines on certificate content and profiles, CA security, revocation mechanisms, use of algorithms and key sizes, audit requirements, liability, privacy and confidentiality, and delegation (including external sub-CAs and registration authorities). Released by the CA/B Forum in December 2011, the Baseline Requirements represent the first time Organizational Validation (OV) and Domain Validated (DV) certificates have a defined standard.

The CA/B Forum Baseline Requirements which help minimize risk, increase user confidence and trust, raise all CAs to a higher level of standards and authentication security. Through its adoption of the Forum’s Baseline Requirements, Symantec is demonstrating its commitment and dedication to the CA community while providing customers and partners with enhanced protection of their operations, reputation and customer relationships.

Symantec Quote: 

“Planning for and adopting these new global standards have been a top priority for Symantec since their release,” said Fran Rosch, vice president, Identity and Authentication Services, Symantec. “With the recent breaches of CAs, it has become imperative that an industry-wide standard be set and enforced to provide the highest level of protection for businesses and websites. We fully support this initiative, and will be helping to move it forward.”

As the world’s largest information security provider, Symantec continues to innovate around security best practices. The CA/B Forum Baseline Requirements are a move in the right direction towards improved industry standards and increased security for Internet users worldwide.

Уязвимость связана с отсутствием необходимой проверки границ в одной из процедур расширения Heartbeat RFC6520 для протокола TLS/DTLS. Из-за этой ошибки открывается прямой доступ к оперативной памяти компьютера, к приватным ключам, контенту, именам и паролям пользователей. При этом не остается никаких следов проникновения в систему.

Уязвимая версия OpenSSL используется в популярных веб-серверах Nginx и Apache, на почтовых серверах, IM-серверах, VPN, а также во множестве других программ. Ущерб от этого бага исключительно велик.

Некоторые дистрибутивы операционных систем с уязвимой версией OpenSSL:

• Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
• CentOS 6.5, OpenSSL 1.0.1e-15)
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
• FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)
• Debian Squeeze (oldstable)
• OpenSSL 0.9.8o-4squeeze14
• SUSE Linux Enterprise Server

P.S. Уязвимость обнаружена специалистами по информационной безопасности компании Codenomicon и Нил Мехта (Neel Mehta) из подразделения Google Security. Подробное описание бага находится на Heartbleed.com

Все SSL сертификаты SYMANTEC БЕЗ ПРЕДОПЛАТЫ !!! Рекомендация Symantec по выбору класса сертификата в зависимости от сферы деятельности Вашей компании Смысловой перевод.
Бренд	Описание продукта	Кому нужен	Для чего используется	Мотивация	Цена
Symantec	Премиум продукт с расширенными дополнительными функциями и сервисом	Крупным Банковским, Финансовым, Страховым организациям, Известным интернет магазинам, Крупным компаниям,	Установление полного доверия посетителей к сайту. Укрепление имиджа. Подтверждение статуса и финансового благосостояния	Хочу лучший бренд и лучший продукт	Высокая \$US 0.8-5.3/day
Thawte	Высокое качество, престиж	Банковским, Финансовым, Страховым организациям, интернет магазинам. Средним компаниям	Важные и логин страницы. e-commerce Сайты с секретной информацией	Готов и могу платить больше за лучшее качество продукта, но не нужны все функции сертификатов премиум класса	Доступная \$US 0.1-1.4
GeoTrust	Базовый сертификат	Производство, Гос.сектор, Образование, Небольшим компаниям	Важные и логин страницы. e-commerce	Хочу надежного поставщика - недорого, быстро и удобно	Дешево \$US 0.2-1.1
RapidSSL	Базовый доменный сертификат	Разработчикам сайтов, тестовых систем	Внутренние сайты. интранет, тестирование сайтов	Необходимо только шифрование	Очень дешево \$US 0.03-0.4

Firefox 23 Blocks Mixed Content

The latest version of the Firefox Web browser from Mozilla was released on August 6th with a great new security feature called a “mixed content blocker”. In a nutshell, this feature ensures that all of the parts of a secure Website are indeed encrypted via SSL certificates. All of the data on the website is prevented from being intercepted, and it becomes more difficult to add malware into the site’s content.

Google published statistics a few years ago showing that the average number of external scripts and stylesheets on a page is roughly 10, and that number has likely increased since then. This means that you are typically trusting a number of other websites in addition to the one displayed in the navigation bar, even if you’re visiting a website with an Extended Validation SSL certificate showing the organization’s name in green. A simple example of this is the script for gathering statistics on the CA Security Council website – this script is loaded from stats.wordpress.com.

In the past, Firefox warned a user the first time they visited a site containing any kind of mixed content, then allowed the user to disable any further warnings. From then on, Firefox allowed external resources such as scripts to be loaded over HTTP without encryption, even if the main page was using HTTPS and displaying a lock icon denoting that the connection is encrypted. This is called “mixed content”, and with the new version of Firefox, it is broken into two categories. “Active mixed content” consists of scripts, stylesheets, and frames, and is blocked by default on every site because it has more potential to be a risk. Images and video are considered “passive content” and not blocked unless the user changes a setting.

This change brings Firefox in line with Google’s Chrome browser which has a similar type of warning. Internet Explorer has warned users every time they visit a site with mixed content for many years.

The CA Security Council congratulates Mozilla on the release of Firefox 23 and the contribution it makes to a safer Internet. If you run a website using SSL, this is a good opportunity to test the site to ensure that all external content loads properly as described in SSL Optimization

С 1 июня GlobalSign прекратила выпуск Code Signing сертификатов для физических лиц

from 1st June 2013 GlobalSign will no longer be offering Code Signing Certificates for Individuals. This change of offering is due to GlobalSign’s aim to ensure the highest level of security best practices.

Атака на финансовые учреждения России

Following on from yesterday’s theme of  http://www.bankinfosecurity.com/ddos-strikes-take-eu-banks-offline-a-5701/op-1 European banks suffering distributed denial-of-service (DDoS) attacks similar to that of http://www.bankinfosecurity.com/top-banks-offer-new-ddos-details-a-5667 their US counterparts , recent news reports reiterate that it’s not only DDoS attacks that the banks need to worry about.

http://www.securelist.com/en/blog/861/Lock_stock_and_two_smoking_Trojans_2 One particular threat  is using a stolen digital signature in order to falsely authenticate its actions: spoofing Russian banking transactions to send funds from a user’s bank account to an account of the attacker’s choosing. A Java program developed by the attackers is being used to inject instructions into an online banking software developed by a Russian company called BIFIT (Banking and Financial the Internet—Technics of Open Company). Symantec confirms that this malware is currently being detected as http://www.symantec.com/security_response/writeup.jsp?docid=2013-042411-5848-99 Backdoor.Jabeefit —we are continuing to investigate the samples and will update this blog soon.

Furthermore,  http://rts.micex.ru/en MICEX , one of the leading Russian stock exchanges and the biggest trading venue in Eastern Europe, has also http://www.group-ib.com/index.php/7-novosti/722-group-ib-online-trading-and-stock-broking-is-in-the-hackers-interest come under attack . Two trading software programs ( http://arqa.ru/eng/quik/ QUIK  and  http://www.egartech.com/product_focus.asp FOCUS ) that are used by many large banks in Russia have been infected on a number of computers and are allowing attackers to monitor a user’s financial transactions by http://www.fiercecio.com/techwatch/story/malware-targets-online-trading-software/2013-04-19 taking screenshots and stealing banking credentials which are then sent to a command-and-control (C&C) server.

Symantec customer? No. None of the companies mentioned, QUIK, FOCUS, nor the MICEX exchange, are Symantec customers

The 2013 Trustwave Global Security Report gives you needed perspective by analyzing the latest threats and vulnerabilities facing organizations just like yours.

Антикризисная акция от СП Адграфикс

SGC Symantec Competitive Replacement Program

Вы можете обменять любой Ваш текущий GlobalSign сертификат на Symantec SecureSite Pro по цене $200 (розничная цена $1195) или Thawte SGC SuperCer по цене $140 (розничная цена $699) + при этом получить бесплатно до 12 месяцев дополнительно

CodeSigning и SSL сертификаты для государственных учреждений и учебных заведений Украины

Акция WebTrust Ukraine по поставке SSL сертификатов для государственных учреждений и учебных заведений Украины со скидкой до 75%

Symantec Competitive Replacement Program

Вы можете обменять любой Ваш текущий сертификат на любой более престижный сертификат Symantec Group VeriSign Thawte или GeoTrust и при этом получить бесплатно до 12 месяцев дополнительно по программе Symantec Competitive Replacement Program
* Программа действительна в рамках требований CABF

Цель: Улучшением безопасности веб-сайтов за счет Symantec Competitive Replacement Program.

Если Вы имеете текущий активный сертификат, выданный Baltimore, Comodo, Entrust, Microsoft, GlobalSign, GoDaddy, SECOM, Polish CA Certum, USER Trust - Comodo’s White Label Root, DigiNotar - Вы имеете право принять участие в Symantec Competitive Replacement Program.

Ниже приведены примеры замены вашего текущего сертификата для расчета конкурентной замены ( Symantec Competitive Replacement Program )

CABForum News

We welcome the CA/Browser forum's call for input into its future evolution. The administration of the Web's certificate system is important for the overall security and trustworthiness of the Internet and the Web, and complementary to the current activities of existing organizations in the Internet ecosystem. That security and trust assurance must come from public and transparent process with open participation of those affected, including users and relying parties along with providers of certificate infrastructure. The Internet and Web thrive on open, transparent, and multi-stakeholder governance and standards processes and coordination among these processes, as exemplified by organizations such as the IETF, ICANN, and W3C.

Adgrafics would like to make you aware of a number of important changes that will be taking place to meet the upcoming CABForum Baseline Requirements for the issuance and management of SSL Certificates. This change is due to new policy requirements enforced by the CABForum .

1. SSL Issuance to Hostnames, Internal IPs and Non-FQDNs ( Section 9.2.1 - page 9 )
   All Certification Center will no longer accept requests to include shortnames within the Subject Alternative Name extension of Domain Validated SSL Certificates with validity periods exceeding 15th November 2015.
   * NOTE: that if you have already been issued a certificate with a SAN containing a shortname, you do not need to take any action and this will continue working as normal.
2. Unverified Information in SSL Organization Unit Field ( Section 9.2.6 - page 10 )
   All Certification Center will no longer accept un-verifiable information in the certificate’s subject: organizationlUnitName (OU) field. All Certification Center will update vetting practices to include validation of the OU field. the OU field will be hard coded into certificate profiles. Customers wishing to create different OU fields will be able to use the multiple profile feature within a Managed SSL Account.
3. Certificate Validity Periods ( Section 9.4 - page11 )
   All Certification Center will only allow certificate issuance with validity periods up to a maximum of 60 months.
   * NOTE: This does not affect existing SSL Certificate customers.
4. Verification of Country for Domain Validated SSL Certificates ( Section 9.2.5 - page 10 )
   All Certification Center will no longer place unverifiable country codes in the subject:countryName field for Domain Validated SSL Certificates
   New policy requirements enforced by the CABForum include an update regarding the accuracy of information for certificate fields.
   * NOTE: This does not affect existing SSL Certificate customers.

Chrome to channel all searches over SSL, Google confirms Including users not signed into Google

Chrome users will soon be able to encrypt search traffic sent via the address bar even when not signed into Google, the company has announced.

From version 25, currently still in the beta and developer channel, that same facility will be extended to searches made using the ‘Omnibox’ (or address bar), as Google calls it, including those via other supported search engines.

Google has gradually enabled SSL searching across its search, browser and Gmail services in the last couple of years, and it remains a work in progress.

Many users are probably now confused by which parts of their interactions with Google are currently encrypted and which are not.

Gmail and Google search started using SSL encryption experimentally in 2010 and 2011, rolling this out across its .com and country domains thereafter. Confusingly, for a while, that meant visiting a secure (https) versions of its sites but all searches and email are now encrypted by default.

Firefox implemented SSL searching for Google address bar searching last summer so Google is really playing catch-up when it comes to Chrome’s address bar.

'Users shouldn’t notice any changes. If anything, their searches will be slightly faster due to Chrome’s implementation of the SPDY protocol, but there should be no other user-visible effect,' said Google engineer, Adam Langley.

Services such as Twitter and Facebook have also started to implement SSL encryption across their services in the same pragmatic manner.

The day when all traffic between browser users and major Internet services is encrypted by default now looks near, and not before time. Hitherto, SSL has been limited to the ecommerce systems used by retailers.

There are a number of scenarios where it us a useful layer of security, mostly when using unencrypted Wi-Fi hotspots.