https://www.thesslstore.com/blog Fri, 19 Jun 2015 09:40:17 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.2 New PCI Standards Require Abandoning SSL 3.0 and TLS 1.0 https://www.thesslstore.com/blog/new-pci-standards-require-abandoning-ssl-3-0-and-tls-1-0/ https://www.thesslstore.com/blog/new-pci-standards-require-abandoning-ssl-3-0-and-tls-1-0/#comments Fri, 12 Jun 2015 04:41:29 +0000 https://www.thesslstore.com/blog/?p=1811 New guidelines dictating the requirements for PCI Compliance, version 3.1 of PCI Data Security Standards (PCI DSS), were released in April. These guidelines must be followed for all companies who take payments over the Internet. A key part of the … Continue reading

The post New PCI Standards Require Abandoning SSL 3.0 and TLS 1.0 appeared first on .

]]>
PCI Standards Require Abandoning SSL 3.0 and TLS 1.0

New guidelines dictating the requirements for PCI Compliance, version 3.1 of PCI Data Security Standards (PCI DSS), were released in April. These guidelines must be followed for all companies who take payments over the Internet. A key part of the new PCI DSS are stricter requirements around the use of TLS (SSL).

PCI DSS v3.1 states that SSL 3.0 and TLS 1.0 “can no longer be used as a security control after June 30th, 2016.” This means that disabling these protocol versions is required in order to be compliant with handling sensitive cardholder data.

Any time we discuss protocols, we like to remind our readers that the true name of the modern protocol is Transport Layer Security (TLS), not SSL. The most recent version of the protocol is TLS 1.2, and the last version to be released under the name “SSL”, was SSL 3.0 way back in 1996.

After the POODLE attack discovered late last year, SSL 3.0 was effectively retired. The newest versions of most modern browsers no longer support SSL 3.0, and everyone should check their servers to make sure they have disabled support for that insecure protocol.

Disabling protocol versions is easy – once you locate where your server stores the configuration settings for SSL, it takes less than a few minutes to update. The hard part of meeting these requirements will be to make a risk assessment of your user base to determine if removing TLS 1.0 support will be problematic.

Remember that PCI DSS dictates technical requirements and procedures for servers that are directly handling user payment information, personal records, and administrative access. So if you do not take payments directly – but instead use a provider such as Paypal, Authorize.net, or Square, you may not have to be PCI Compliant. For companies who do handle payments directly, it’s not necessarily required to make these changes network wide. For many networks and companies this will ease compliance.

So, if you are affected by these changes, how much time do you have?

The deadline for ending support for SSL 3.0 and TLS 1.0 is June 30th, 2016, just about a year from now. However this comes with some caveats. “Effective immediately, new implementations must not use SSL or [TLS 1.1],” and existing implementations must have a “formal Risk Mitigation and Migration Plan in place.”

So while the hard deadline on abandoning these old SSL protocols is about 12 months away, the easiest option will be to migrate from these protocol versions now.

The PCI Security Standards Council suggests you only support TLS 1.2 for optimal configuration. This is because all protocol versions except for TLS 1.2 are vulnerable, though you may find users’ devices do not support this version so for practical versions this may not be possible. If you do keep TLS 1.1 enabled, make sure you optimize your configuration to avoid potential security flaws.

If you or your clients handle user data which requires PCI compliance, you will want to consult directly with their new PCI DSS v3.1 Standards, available here:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

A summary of the changes specifically affecting SSL are available here:
https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf

The post New PCI Standards Require Abandoning SSL 3.0 and TLS 1.0 appeared first on .

]]>
https://www.thesslstore.com/blog/new-pci-standards-require-abandoning-ssl-3-0-and-tls-1-0/feed/ 0
Symantec Increases Pricing for SSL Certificates in Japan https://www.thesslstore.com/blog/symantec-increases-pricing-for-ssl-certificates-in-japan/ https://www.thesslstore.com/blog/symantec-increases-pricing-for-ssl-certificates-in-japan/#comments Tue, 14 Apr 2015 05:17:01 +0000 https://www.thesslstore.com/blog/?p=1819 On April 14th, 2015, Symantec officially announced increased prices for their brands of SSL Certificates. As The SSL Store™ is a top web security partner of Symantec, we informed our Japan-based customers and partners that we also have to comply … Continue reading

The post Symantec Increases Pricing for SSL Certificates in Japan appeared first on .

]]>
On April 14th, 2015, Symantec officially announced increased prices for their brands of SSL Certificates. As The SSL Store™ is a top web security partner of Symantec, we informed our Japan-based customers and partners that we also have to comply with this new regulation and adjust our pricing for SSL certificates with .JP domain names.

Symantec Japan

When you purchase an SSL Certificate, our system will now require an extra surcharge when you go to create a CSR and your domain name contains a .JP or administrative, billing or organizational address located in Japan. This is mandatory for all Symantec partners around the world.

There’s No Surcharge If Your Website Is Hosted In Japan

International domain names that are hosted in Japan are not affected and won’t incur any additional surcharge. You may continue to place an SSL Certificate order for your international domain name hosted in Japan, without any surcharge being applied to your order.

Customer FAQs for New Symantec Japan Pricing:

  1. Why is Symantec Increasing their Japan Pricing for SSL Products?
  2. Symantec advised their partners that the pricing would be aligned and adjusted to encourage and reward in-market focus, investment, and support for all Symantec SSL Certificates sold to Japan.

  3. Which SSL Brands are affected by this new Japan pricing announcement?
  4. All RapidSSL, GeoTrust, Thawte and Symantec products have new Japan pricing.

  5. What happens if I order an SSL Certificate for Japan but do not select the Japan Region?
  6. When you begin to configure your SSL Certificate, we check the above criteria. If you have not selected the Japan Region when ordering, our system will prevent you from completing the configuration of your certificate. You will then need to contact us to arrange either a refund or to adjust your order to the new pricing.

  7. Is The SSL Store™ will offer Price Match Guarantee to Japan Customers?
  8. As one of the largest SSL Certificate providers globally, The SSL Store™ sets the standard in offering a high quality SSL Certificate service and has adjusted its retail pricing structure to reflect fair and reasonable pricing. If you have found another supplier offering Japan pricing cheaper, we’ll match it.

  9. Does this New Pricing Also Affect Additional SAN (Subject Alternative Domain Names) and Code Signing Certificates?

Yes, you will need to pay an extra surcharge for additional SAN purchases if your domain name contains a .JP extension. And yes, Symantec Code Signing and Thawte Code Signing certificates are also affected by the new Japan pricing.

The post Symantec Increases Pricing for SSL Certificates in Japan appeared first on .

]]>
https://www.thesslstore.com/blog/symantec-increases-pricing-for-ssl-certificates-in-japan/feed/ 0
Symantec SSL Certificates Now offer a FREE SAN for Base Domain Names. https://www.thesslstore.com/blog/symantec-ssl-certificates-now-offer-a-free-san-for-base-domain-names/ https://www.thesslstore.com/blog/symantec-ssl-certificates-now-offer-a-free-san-for-base-domain-names/#comments Fri, 20 Mar 2015 09:40:42 +0000 https://www.thesslstore.com/blog/?p=1759 The world’s most trusted online security brand Symantec has just announced that they will now secure www & non-www domain names with single SSL certificate & it will be considered the same FQDN! This is big news for us and … Continue reading

The post Symantec SSL Certificates Now offer a FREE SAN for Base Domain Names. appeared first on .

]]>
The world’s most trusted online security brand Symantec has just announced that they will now secure www & non-www domain names with single SSL certificate & it will be considered the same FQDN! This is big news for us and all of our partners and customers.

Symantec-Free-San

Finally, all Symantec SSL certificates will now consider the base domain as a free SAN or Subject Alternative Name, which simply means you can secure both versions of your website, www.name-of-site.com and name-of-site.com with single Symantec SSL Certificate. This is any easy thing that will reduce your cost and time to manage multiple certificates for one website.

As the world’s leading brand, Symantec is always thinking about their partners and customers’ well-being and implementing new features like this to provide the best web security solutions on the planet. Symantec SSL certificates secure the majority of websites in the world and boasts the strongest encryption, unparalleled brand recognition, free Norton secured seal, which is just icing on the cake if you ask me.

Here are the 3 use case for Symantec SSL certificates:

  • When you enroll with Common Name as www.name-of-site.com , Symantec SSL now automatically secures and adds the non-www version of the same domain (name-of-site.com) as a SAN for free.
  • When you enroll the Common Name as name-of-site.com, Symantec will automatically add www.name-of-site.com as a free SAN.
  • For a wildcard certificate: When the enrolled Common Name is *.name-of-site.com, Symantec will automatically add name-of-site.com as a free SAN.

Details/Examples:
1) When the Common Name is www.name-of-site.com

Symantec SSL will add the common name’s base domain as a SAN value for all certificates where the common name begins with “www” and does not contain sub-domains.

–  It’s free and it does not count as part of the max # of allowed SAN
–  Of course, it will only be added if TLD is valid.

TLD Domain Types Example of Domain Names Add base domain as a SAN value?
1-­‐level TLD (such as a gTLD) www.domain.com Yes –add domain.com
1-­‐level TLD (such as a gTLD) www.subdomain.domain.com No
2-­‐level TLD(such as a ccTLD) www.domain.co.uk Yes – add domain.co.uk
2-­‐level TLD(such as a ccTLD) www.subdomain.domain.co.uk No
Internal host/IP server.local No

2) When Common Name is domain.com

Symantec SSL certificates automatically add “www” to the common name’s domain as a SAN value for all certificates where the common name is a simple domain name without any sub-domains.

–  It’s free and it does not count as part of the max # of allowed SAN
–  Of course, it will only be added if TLD is valid.

TLD Domain Types Example of Domain Names Add base domain as a SAN value?
1-­‐level TLD (such as a gTLD) domain.com Yes –add www.domain.com
1-­‐level TLD (such as a gTLD) www.subdomain.domain.com No
2-­‐level TLD(such as a ccTLD) domain.co.uk Yes – add www.domain.co.uk
2-­‐level TLD(such as a ccTLD) www.subdomain.domain.co.uk No
Internal host/IP server.local No

3) When Common Name is *.domain.com (Wildcard SSL)

Symantec SSL Certificate automatically add the common name’s base domain as a SAN value for all certificates where the common name is wildcard and does not contain sub-domains.

–  It’s free and it does not count as part of the max # of allowed SAN
–  Of course, it will only be added if TLD is valid.

TLD Domain Types Example of Domain Names Add base domain as a SAN value?
1-­‐level TLD (such as a gTLD) *.domain.com Yes –add domain.com
1-­‐level TLD (such as a gTLD) *.subdomain.domain.com No
2-­‐level TLD(such as a ccTLD) *.domain.co.uk Yes – add domain.co.uk
2-­‐level TLD(such as a ccTLD) *.subdomain.domain.co.uk No
Internal host/IP *.server.local No

The following SSL products of Symantec are enhanced from this change:

Symantec Thawte GeoTrust
Secure Site Pro with EV SSL Web Server with EV True BusinessID with EV
Secure Site with EV SGC Supercerts True BusinessID
Secure Site Pro SSL Web Server ———-
Secure Site Wildcard SSL Web Server Wildcard True BusinessID Wildcard
Secure Site SSL SSL123 (DV But Allow) ———-

*GeoTrust already offers domain.com as a free SAN when the common name is www.domain.com, but will now also add www.domain.com as a free SAN when the common name is domain.com.

The post Symantec SSL Certificates Now offer a FREE SAN for Base Domain Names. appeared first on .

]]>
https://www.thesslstore.com/blog/symantec-ssl-certificates-now-offer-a-free-san-for-base-domain-names/feed/ 0
Airline Wi-Fi Provider Gogo Has Been Intercepting User Traffic https://www.thesslstore.com/blog/airline-wi-fi-provider-gogo-intercepting-user-traffic/ https://www.thesslstore.com/blog/airline-wi-fi-provider-gogo-intercepting-user-traffic/#comments Tue, 20 Jan 2015 04:00:29 +0000 https://www.thesslstore.com/blog/?p=1753 If you have ever flown on a US airline, chances are you have seen an advertisement for an in-flight Wi-Fi service provided by Gogo. While Gogo is certainly appealing to most travelers in this day and age, a revelation has … Continue reading

The post Airline Wi-Fi Provider Gogo Has Been Intercepting User Traffic appeared first on .

]]>
If you have ever flown on a US airline, chances are you have seen an advertisement for an in-flight Wi-Fi service provided by Gogo. While Gogo is certainly appealing to most travelers in this day and age, a revelation has come to light recently about this service that you should probably be aware of.

gogo_inflight_internet

This past week, Adrienne Porter Felt, a security engineer at Google, discovered that Gogo was using a fraudulent certificate in place of Youtube.com’s real SSL certificate. The certificate was a self-signed certificate issued by Gogo, being used in combination with a proxy server. This was easy to spot because of SSL security measures in place that prevents connections from being established with a certificate issued by an untrusted provider.

The purpose of this behavior is to insert their own proxy server between the user and Youtube.com, known as a “man in the middle attack” (MITM). By performing a MITM attack, Gogo was able to view user’s data unencrypted, for the purpose of throttling or blocking connections to the bandwidth-intensive video streaming site.

Making sure users are not violating policy is fairly standard for Internet service providers. Because SSL encrypts internet traffic, it makes it harder for providers to monitor and restrict access on their networks. However by MITMing traffic to Youtube, Gogo has stepped far over the boundaries of acceptable behavior, especially given available alternatives which protect user privacy.

This is especially troubling given Gogo’s history. Neowin.com reports that “earlier this year, it was revealed through the FCC that Gogo partnered with government officials to produce ‘capabilities to accommodate law enforcement interests’ that go beyond those outlined under federal law.”3

We hope it goes without saying, but just to be clear, The SSL Store™ does not support this action, or any other action(s) which undermine SSL security and user perception of security.

For more on this story, please see this excellent write up by Rick Andrews of Symantec at CASecutiy.org.

 

 


3 http://www.neowin.net/news/gogo-inflight-internet-is-intentionally-issuing-fake-ssl-certificates

The post Airline Wi-Fi Provider Gogo Has Been Intercepting User Traffic appeared first on .

]]>
https://www.thesslstore.com/blog/airline-wi-fi-provider-gogo-intercepting-user-traffic/feed/ 0
4 & 5 Year SSL Certificates Being Discontinued in 2015 https://www.thesslstore.com/blog/4-5-year-ssl-certificates-being-discontinued-in-2015/ https://www.thesslstore.com/blog/4-5-year-ssl-certificates-being-discontinued-in-2015/#comments Wed, 17 Dec 2014 05:36:45 +0000 https://www.thesslstore.com/blog/?p=1720 On March 1st, 2015, The SSL Store™ will discontinue offering SSL certificates with validity periods of 4 and 5 years. This is in accordance with new guidelines set forth by the Certificate Authority/Browser (CA/B) Forum, the governing body of the … Continue reading

The post 4 & 5 Year SSL Certificates Being Discontinued in 2015 appeared first on .

]]>
On March 1st, 2015, The SSL Store™ will discontinue offering SSL certificates with validity periods of 4 and 5 years.

This is in accordance with new guidelines set forth by the Certificate Authority/Browser (CA/B) Forum, the governing body of the SSL industry. This update will affect all SSL certificates in the industry, including the entire product catalogs of Symantec, Comodo, Thawte, GeoTrust, and RapidSSL. (EV certificates are already limited to a maximum of two years so they are not affected by this change).

Please note that any active 4 or 5 year certificate that are reissued after the March 1st, 2015 deadline will automatically be truncated to the new maximum duration permissible, which is 39 months. Any active 4 or 5 year certificate that is reissued before this deadline will be unaffected. Therefore, The SSL Store™ strongly recommends that any new SSL purchase be for no more than a maximum of 3 years, in order to avoid any lost time and money due to a reissue.

To help further prepare for this change, we have amended all of our product pages to include a new yellow drop down box that appears anytime a 4 or 5 year certificate is selected for purchase. The new drop down box briefly explains this new update and emphasizes that all 4 or 5 year certificates reissued after the March 1st deadline will be truncated to the new maximum industry standard of 39 months.

4To5 Yr option closed for SSLCertificates

Ultimately, this is good news for the SSL industry, as certificates with shorter lifespans make security updates much easier and more streamlined. So, recent updates like the SHA-2 upgrade, internal domain issuance, and more industry-wide enhancements that have become quite commonplace with SSL will be much less of a hassle.

Also, certificates with shorter lifespans will offer more in the way of security, as companies will have to reaffirm their identities in a more timely fashion. It goes without saying that trust and security are of paramount importance to the SSL market, so any effort to enhance either of these components is good for the overall health of the market.

We would advise all of our partners to begin informing their customers of this impending industry change. If you have any questions about deprecation of 4 and 5 year SSL certificates, please feel free to contact our Customer Experience department via support@theSSLstore.com, Live Chat on our website, or directly at +1 727-388-4240.

The post 4 & 5 Year SSL Certificates Being Discontinued in 2015 appeared first on .

]]>
https://www.thesslstore.com/blog/4-5-year-ssl-certificates-being-discontinued-in-2015/feed/ 0
10 Important Factors That Make Symantec™ SSL Certificates #1 https://www.thesslstore.com/blog/10-secrets-that-make-symantec-ssl-certificates-number1/ https://www.thesslstore.com/blog/10-secrets-that-make-symantec-ssl-certificates-number1/#comments Tue, 16 Dec 2014 04:00:23 +0000 https://www.thesslstore.com/blog/?p=1691 Symantec™ Corporation is a US-based internet security & technology company, founded by Gary Hendrix in 1982. It’s a global and publically traded company (NASDAQ: SYMC) dealing with many different sectors of the security industry, such as; anti-virus applications, data storage … Continue reading

The post 10 Important Factors That Make Symantec™ SSL Certificates #1 appeared first on .

]]>
Symantec™ Corporation is a US-based internet security & technology company, founded by Gary Hendrix in 1982. It’s a global and publically traded company (NASDAQ: SYMC) dealing with many different sectors of the security industry, such as; anti-virus applications, data storage & backup solutions, SSL certificates and other website security solutions.

As per W3Techs’s (Web Technology Surveys) report, Symantec™ Corporation is the top Certificate Authority (CA) with the largest market share of almost 37.3%.

Web-Technology-Surveys-Symantec-SSL1

Top 10 Reasons that Easily Make Symantec™ the #1 Choice:

Here are the few important factors to consider about Symantec™ before choosing an SSL certificate provider.

  1. SSL Industry Leader: *****
    Symantec

    • Back in 2010, Symantec™ acquired the identity and authentication business from VeriSign™ which was the leader in SSL & Code Signing Certificate services at the time.
    • With a market share of more than 37.3%, Symantec™ was able to leverage the power of Symantec™ and Norton brands to become the SSL security giant they are today with highest number of satisfied certificate customers spread all over the world.

  2. #1 Encryption and Cryptography Technology: *****

    Symantec™ offers industry-standard SSL certificates all with a 2048-bit length and a strong encryption key length of up to 256-bit, as well as the latest and greatest encryption technology called ECC or Elliptic Curve Cryptography, which is stronger, lighter and faster. There also premium features included with all of the Symantec™ branded certificates, such as a daily vulnerability assessment and malware scanner that ensures high-level website security on multiple fronts. It not only offers trusted & safe communication, it highly improves a users’ trust and confidence to further enable sharing sensitive information or engagement on a website.

    All Symantec™ SSL certificates are powered with the SHA-2 hash algorithm. It consists of a set of 6 hash function and carries hash values of 224, 256, 384 or 512-bits, which makes it very difficult for any hacker to even come close to breaking.

  3. Offers a Multi-Purpose Solution: *****

    Whether it is a question to secure small/medium/large scale website, a software/file/application, an e-commerce website or a website with multiple domains and sub-domains, Symantec™ has a perfect security solutions for all of the scenarios.

    Symantec™ offers:

    • Strong SSL encryption to protect any small/medium/large website, including the one-and-only ECC signed certs.
    • Code Signing certificates to protect code on any software, files and applications.
    • EV SSL certificates to secure & display security for e-commerce websites and online business transactions
    • Wildcard certificates to cost-effectively protect websites with multiple sub-domains and SAN SSL certificates to secure the multiple domain websites.
    • Vulnerability scanning & malware detection to take website security even further.

  4. Unprecedented Brand Power & Recognition: ****

    Symantec™ happens to own one of the most globally recognized internet security brands known to the world, Norton™. They were able to leverage this brand power and awareness established from the leading anti-virus software, Norton™ Anti-Virus, right into the SSL industry to help people actually know that they are on a safe & secure site protected by an established & trusted brand.

  5. A Fast Verification Process: ****

    Symantec™ offers one of the fastest and stream-lined verification processes.

    Once you’re done placing the order and sending the necessary documents to Symantec™, their highly experienced team will quickly be able to navigate through all of your documentation, to quickly issue your SSL certificate and have it ready for you to install it on your server.

  6. 24/7 Live Support form Experts: *****

    Compared to other Certificate Authorities (CAs), Symantec™ is leaps and bounds ahead of them when it comes to providing quick and responsive customer care & support if the need arises.

    Symantec™ provides:

    • Phone Support
    • Live Chat Support
    • E-mail Support
    • Quick SSL Installation Guides.
    • Social Media Support






    Symantec™ has a team of expert support representatives, who promptly assist their customers 24/7 via phone call, e-mail and live chat.

    Symantec™ also provides access to quick SSL installation guides to help users troubleshoot any SSL errors instantly.

    Customers can also directly reach out to Symantec™ by using various Social Media platforms. Their social media support team is active at all hours of the day.

  7. Eliminates Browser Security Alerts and Pop-up Messages: *****

    Symantec™ SSL certificates are designed to not only effectively secure websites, but to also to eliminate browser errors. This way, when a user logs on to a website protected by Symantec™ SSL certificates, the browser runs the website without displaying any browser errors or warnings.

    If a software/application/file is protected with a Symantec™ Code Signing certificate, end-users won’t see pop-up error messages on any web-based or mobile based platforms during the installation process.

  8. Compatible with Modern Browsers: *****

    Symantec™ is committed to giving complete digital security for website/server/software. Whether it’s an older version browser or modern web browser, Symantec™ SSL certificates are highly compatible with all browsers including mobile browsers. Symantec has the best browser and mobile public root ubiquity of all CAs, which will enable an organization to better implement Always On SSL.

  9. Industry-Best Extended Warranty: *****

    Symantec™ is so confident about their encryption strength and infrastructure of its entire business and SSL product-line, it offers an unmatched and extremely high warranty amount to further enhance user-confidence and trust. If your website is protected with Symantec™ SSL certificate and somehow fails as a result of their mishandling or wrongdoings, Symantec™ and as per their company policy, will cover transactions affected up to the specified warranty amount. Their warranties are as high as $1,750,000, which is by far the largest in the industry.

  10. Advanced SSL Tools: *****

    Symantec™ offers advanced SSL tools for all of their customers, which helps install SSL certificates and check a detailed status of their SSL certificates.

    Symantec™ SSL Tools

    1. CSR Checker

      When you start installing your SSL certificate on the server, you first need to generate a CSR (Certificate Signing Request) for your server. After generating a CSR, you must check whether it will work for you. This ‘CSR Checker’ helps you to check the CSR that you have generated.

    2. SSL Checker – To check the installation of SSL certificate.

      After installing an SSL certificate on your server, you must check if it was installed properly. This SSL Checker tool helps the users check the installation and status of your SSL certificate.

Conclusion:

In the wake of daily cyber-crimes, website security is a major concern for all web users. And after reading all the above factors, we can surely say that Symantec™ is the ultimate solution for securing websites, online business transactions, customers’ sensitive information and also for securing code for software/applications/files.

The post 10 Important Factors That Make Symantec™ SSL Certificates #1 appeared first on .

]]> https://www.thesslstore.com/blog/10-secrets-that-make-symantec-ssl-certificates-number1/feed/ 0 Limited POODLE Attack Resurfaces in TLS https://www.thesslstore.com/blog/limited-poodle-attack-resurfaces-tls/ https://www.thesslstore.com/blog/limited-poodle-attack-resurfaces-tls/#comments Thu, 11 Dec 2014 08:34:18 +0000 https://www.thesslstore.com/blog/?p=1710 Back in October, we published an extensive article about an attack called POODLE that affected old versions of the SSL protocol (specifically, SSL 3.0). This attack had the potential to affect nearly 98% of the Internet, as many servers still … Continue reading

The post Limited POODLE Attack Resurfaces in TLS appeared first on .

]]>
Back in October, we published an extensive article about an attack called POODLE that affected old versions of the SSL protocol (specifically, SSL 3.0). This attack had the potential to affect nearly 98% of the Internet, as many servers still supported this older version of the protocol.

poodle-vulnerability

But now it has been revealed that POODLE is back, this time with the ability to affect even the newest version of the protocol1.

Any time we visit the topic of SSL protocol attacks, we should remember this brief history lesson about SSL naming nomenclature: The earliest versions of the protocol were named SSL 2.0 and SSL 3.0. Then, in 1999, the next version of the protocol was renamed to TLS 1.0. Since then, all new versions have been named TLS, for Transport Layer Security, rather than Secure Socket Layer. Today, the newest version is TLS 1.2.

The POODLE attack was previously thought to only work on SSL v3.0 because it took advantage of a flaw where a section of the message (specifically, the message padding) could be changed by an attacker; this was due to under-specification of the early protocol. Successors to SSL 3.0 have since corrected this. However, some implementations of these new protocols may be vulnerable. This is because while the specifications of TLS 1.1 and 1.2 require that the message padding be verified, it’s impossible to ensure all implementations follow this rule, and clients (web browsers) cannot effectively check for this2.

Security researchers Brian Smith and Adam Langley have been quietly working since October3 , confirming the suspicion that the POODLE attack could be used on other versions of the SSL protocol. They found a few notable vulnerabilities on enterprise-level hardware, specifically devices made by two network equipment companies, F5 and A10.

The good news is that this new vulnerability is estimated to affect under 10% of servers.4 Unlike the first round of POODLE, this vulnerability is not due to a flaw in the protocol specification, but in specific implementations of it.

This attack can be executed with similar efficiency as POODLE with SSL 3.0, however with a much smaller number of potentially affected targets. Remember that both POODLE attacks require an active network attacker, the ability to inject JavaScript into a client’s browser, and only require around 4096 requests on average to succeed (this may sound like a lot, but it is quite practical to achieve).

This time around, a much smaller group of servers are affected and we believe these will be quickly patched by the server administrators who attend to them. F5 and A10 have released patches today for their devices which solve this issue. If you are affected by this please visit this page for F5 devices and this page for A10 to get the relevant patches and information.

 


  1. https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
  2. https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
  3. https://www.imperialviolet.org/2014/12/08/poodleagain.html
  4. See the final paragraph in this article, where Ivan Ristic says the latest SSL Pulse statistics reveal 10% of servers were vulnerable.

The post Limited POODLE Attack Resurfaces in TLS appeared first on .

]]>
https://www.thesslstore.com/blog/limited-poodle-attack-resurfaces-tls/feed/ 0
SAN/UCC SSL Certificates Will Not Work for Internal Domain Names after November 1, 2015 https://www.thesslstore.com/blog/san-ucc-ssl-certificates-no-longer-work-for-internal-domain-names/ https://www.thesslstore.com/blog/san-ucc-ssl-certificates-no-longer-work-for-internal-domain-names/#comments Thu, 27 Nov 2014 06:54:15 +0000 https://www.thesslstore.com/blog/?p=1655 Are you shocked after reading the headline? Yes, it is true that ALL (SAN/UCC) SSL Certificates will not work for internal server domain names from 1st November, 2015. As per the CA/Browser Forum (CA/B), the regulatory body that governs the … Continue reading

The post SAN/UCC SSL Certificates Will Not Work for Internal Domain Names after November 1, 2015 appeared first on .

]]>
Are you shocked after reading the headline? Yes, it is true that ALL (SAN/UCC) SSL Certificates will not work for internal server domain names from 1st November, 2015.

CA/B Forum

As per the CA/Browser Forum (CA/B), the regulatory body that governs the SSL industry, one of the new changes is the elimination of certificates for internal names. This change makes it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as owned by the organization that is requesting the certificate after 2015.

This does not mean you can no longer use SSL certificates for internal use. Internal websites and networks simply need to transition to using delegated domain names or registered IP addresses. For instance, “mynetwork.internal” cannot be reliable verified to be owned by only one company or party. Therefore it is a security risk to have multiple certificates issued out to that same domain. If your internal network is on a similar internal name, it just needs to be transitioned to a registered domain name, such as “mynetwork.com”. That domain does not need to resolve in the public DNS, or go to a publically available page.

The CA/B forums new requirements also disallow internal domain names in the Subject Alternative Name (SAN) extension. If Certificate applications do include a disallowed domain, often times the CA can automatically reject the order or notify the applicant that the use of internal name has been depreciated.

So to summarize, Certificate Authorities shall not issue a certificate with an expiry date later than 1 November 2015. Certificates with validity periods past that date may also be forced to lose their internal names they next time they reissue.

Here is some quick FAQ Answers for Your Basic Questions:

What is SAN/UCC SSL Certificate?

How Multi Domain SSL Work

SSL Certificates that you can and can’t use to secure your internal domain names or Internal Server Names likes:

No longer allowed:

  • mycompany.internal
  • mycompany.priv
  • mail.mynetwork.server
  • 192.168.1.1





Use these instead:

  • www.mycompany.com
  • mycompany.com
  • www.mycompany.net
  • mail.mycompany.com





What Is Internal Server Name?
An internal name is a domain or IP address that not actually registered. Common examples of internal names are:

  • Any server name with a non-public domain name suffix. For example, www.company.local or server1.company.internal.
  • NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo.
  • Any IPv4 address in the RFC 1918 range.
  • Any IPv6 address in the RFC 4193 range.





What You Need to Do?

If you have multi server names and want to secure them with trusted SSL Certificates then you need to reconfigure all those servers to use a public name. Some exceptions can be made if you need more time to transition, for these cases please contact us directly. All internal connections that require a publicly-trusted certificate must be done through names that are publically delegated and verifiable (it does not matter if those services are publicly accessible).

How to Redirect Internal Names to use a Registered Domain Names?

If you are using a single SSL Certificate to secure your internal domain names for your Exchanges Server for your internal communication then you will need to make all the internal domain names to public domain names to use SSL Certificates.

To reconfigure your domain to use only the external domain name you have a couple of options. If you are using Active Directory you can migrate an internal Active Directory domain to a registered External name. This will change the internal FQDN of your Exchange Servers so they will reroute to a valid subdomain of your registered external domain(e.g. change from Server01.yourcompany.internal to Server01.yourcompany.com) allowing you to use a SAN certificate or UCC Certificate to secure these names.

Alternatively, you can redirect the internal names to use the external mail URL, but this method will not allow access to mail using the Outlook Anywhere service so users connecting over a VPN would have connection problems.

Redirecting your Exchange Server to use the External DNS Name

To update your Exchange 2007 or Exchange 2010 server you will need to run the following commands from the Exchange Management Shell and replace the Server running the Client Access Role with your external domain name. These commands update the URL for the Auto discover service, Exchange Web Services (EWS) and the OWA Web-based Offline Address book respectively.

Before running these commands you will just need to check make sure a DNS record exists mapping the IP Address to the Exchange Client Access (CAS) server.

Note: Each of these commands below should be run on a single line in the Exchange Management Shell (EMS):

  1. Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri
  2. Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri https://mail.yourdomain.com/autodiscover/autodiscover.xml
  3. Set-WebServicesVirtualDirectory -Identity “HostName\EWS (Default Web Site)” -InternalUrl https://mail.yourdomain.com/ews/exchange.asmx
  4. Set-OABVirtualDirectory -Identity “HostName\oab (Default Web Site)” -InternalUrl https://mail.yourdomain.com/oab



Recycle the IIS Application Pools

Next to make these commands take effect you have to tell IIS to push these changes by recycling the application pools.

  1. Open IIS Manager by clicking Start, then enter inetmgr.
  2. Expand the server and expand Application Pools, then right-click on MSExchangeAutodiscoverAppPool, and select Recycle



The Last Word:

Please Contact Our SSL Experts to “Resolve” your SAN/ UCC SSL Certificate issue

The post SAN/UCC SSL Certificates Will Not Work for Internal Domain Names after November 1, 2015 appeared first on .

]]>
https://www.thesslstore.com/blog/san-ucc-ssl-certificates-no-longer-work-for-internal-domain-names/feed/ 0
SSL 3.0 POODLE Vulnerability Has Wide Ranging Effects https://www.thesslstore.com/blog/ssl3-poodle-vulnerability/ https://www.thesslstore.com/blog/ssl3-poodle-vulnerability/#comments Wed, 22 Oct 2014 09:34:51 +0000 https://www.thesslstore.com/blog/?p=1611 What is “POODLE”? POODLE is an acronym for a newly discovered vulnerability in a specific version of the SSL protocol. POODLE requires an “active” attacker, meaning there must be another ‘bad’ computer intercepting messages between the client and server. Ultimately, … Continue reading

The post SSL 3.0 POODLE Vulnerability Has Wide Ranging Effects appeared first on .

]]>
What is “POODLE”?

POODLE is an acronym for a newly discovered vulnerability in a specific version of the SSL protocol. POODLE requires an “active” attacker, meaning there must be another ‘bad’ computer intercepting messages between the client and server. Ultimately, the vulnerability allows the attacker to decode messages encrypted with SSL v3.0 (the specific, and only, version of the protocol affected).

SSL v3.0 is an old version of the SSL protocol, a very old version – from the late 90s. However, almost all servers on the Internet still accept connections using it. Luckily, there is a straightforward way to protect yourself from this attack (see “As An SSL Provider, What Should I Do?” section below). The attack also is fairly complex to perform, because of its reliance on being an “active” attack which affects the client. There are also no known attacks using the POODLE vulnerability (yet). For this reason, it is much less serious than the Heartbleed vulnerability from earlier this year. Security expert Robert Graham said, “If Hearbleed/Shellshock merited a 10, then this attack is only around a 5.”1

However, this does not mean that POODLE should be ignored, because all servers or clients running SSL v3.0 are vulnerable. (See section, “Who is Affected?” for specific details on this and threat analysis).

The vulnerability is serious enough that Mozilla has declared POODLE “the end of SSL 3.0,”2 and Google said “to achieve secure encryption, SSL 3.0 must be avoided entirely.”3

Please note that (luckily) this is a flaw in an outdated version of the SSL protocol itself, so no changes to any existing certificates themselves are needed. This vulnerability is the result of some bad math back when this version of the protocol was created back in the late 90s.

Solutions to this vulnerability are most effectively implemented at the server level (even though the attack is on the client, its reliant on the server allowing a connection using SSL v3.0 to occur), so education and awareness of the issue is the best way to mitigate the effects of the POODLE vulnerability.

How does the Attack Work?

The POODLE vulnerability can be implemented by an attacker who has control or influence over the network connection between the client and the server – often called a “Man in the Middle Attack” (MITM).4

An attack using POODLE begins with a “downgrade attack” to repeatedly cause the client’s connection to the server to fail. This causes the server to allow an encrypted connection with older versions of the protocol, because it believes a lack of modern protocol support is the cause. This downgrading continues to occur until the connection is downgraded all the way to SSL v3.0, at which point the POODLE attack can be used.5

This downgrade attack works because, while almost every server supports a newer version of the SSL protocol which are not affected, they ALSO support SSL v3.0 in order to avoid any incompatibility issues with older (“legacy”) clients. After forcing stronger clients to downgrade to SSL v3.0, they can use a flaw in the protocol to figure out the encryption key for an SSL connection, and read the contents as if they were unencrypted.

If you would like to know more about how the attack works, Google provides some excellent information in their paper which announced the discovery: “This POODLE Bites: Exploiting The SSL 3.0 Fallback.”6

Who is Affected?

Any browser or server which supports SSL 3.0 can be victim to POODLE. Critically, “any website that supports SSLv3 is vulnerable to POODLE, even if it also supports more recent versions of TLS.”7 This means that sites trying to provide backwards compatibility for older clients are at risk. For this reason, supporting SSL v3.0 at all can make a server or client vulnerable.

SSL Pulse is a website that collects monthly demographic statistics of SSL support of the 150,000 most popular websites.8 SSL Pulse’s most recent scan, conducted before the disclosure of the POODLE vulnerability, found that 98% of these sites still have SSL v3.0 support, potentially putting them at risk of a POODLE attack. Extrapolating from this, it can be assumed most servers on the Internet still include support for the decrepit SSL v3.0.

However, there is very little client traffic still using SSL v3.0 to justify support of this deprecated and flawed protocol version. The most notable software affected by this attack is Internet Explorer 6 on Windows XP versions WITHOUT Service Pack 3.

Support for this flawed protocol version should not be kept for users still on IE6. On Cloudflare, a major provider of DDoS protection, only 0.65% of their received SSL traffic uses (not relies on) SSL v3.0, and 98% of their Windows XP traffic is properly patched to Service Pack 3 which enables TLS 1.0 (the next version of the SSL protocol after SSL v3.0).9 Mozilla similarly estimates only 0.3% of traffic actually uses SSL v3.0, yet around 98% of servers allow it! The number of clients still needing SSL v3.0 simply does not justify keeping it on.

As an SSL provider, what should I do?

The SSL Store’s recommendation is to totally disable support for SSL v3.0. This should be disabled on your servers and communicated to your customers. There are solutions to the POODLE attack, mainly the new protocol mechanism “TLS_FALLBACK_SCSV.”10 However, this mechanism relies on server and browser compatibility, which introduces too much uncertainty to its effectiveness. TLS FALLBACK also does not fix the issue for devices that ONLY have SSL v3.0 support, leaving the biggest vulnerable software – IE6, still exposed.

So, to be totally safe from POODLE, and other discovered and undiscovered flaws in SSL v3.0, its best to disable support for it altogether at the server side. This falls in line with what is recommended by Google, Mozilla, Cloudflare11, and other major technology companies.

On the client side, Firefox will be disabling SSL v3.0 by default in Firefox 34, which is to be released on Nov 25th. Google will also be removing SSL v3.0 support in client devices, including Chrome, “in [the] coming months.”12 With this pressure on the client-side removing SSL v3.0 support, the tiny number of client’s using SSL v3.0 should tumble even further.

(Also note, if you recently switched to SHA2 certificates, as the SSL industry is encouraging and requiring, you have downgraded the user experience for sluggish clients still on IE6 with Windows XP pre-Service Pack 3. So disabling SSL v3.0 will be the nail in the coffin for them – thats a good thing.)

Does this mean SSL is insecure?

No. SSL, or more accurately, TLS, is fine. While most people use the word “SSL” still, the proper technical term for the encryption protocol we use today is TLS. This stands for Transport Layer Security and has been the official name of the SSL protocol since 1999. The newest version of the TLS protocol, Version 1.2, was released in 2008 and is four versions senior of SSL 3.0. All ‘modern’ browsers and computers, and smartphones should have support for some version of TLS, and the majority of SSL connections are using TLS. TLS 1.0 and 1.1 are not perfect, but they are much improved over SSL v3.0 and are considered suitable by security experts.

SSL v3.0 is over 15 years old! So it’s only reasonable for it to be abandoned at this point.

How Do I Disable SSL v3.0 on my Server?

This depends on the type of server you are operating.

For Apache Tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=54691

For Apache, Nginx, and IIS: https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/

For Lighttpd: https://cipherli.st/

If you do not want to drop SSL v3.0 support, you can implement TLS_FALLBACK_SCSV on OpenSSL. However this should just be a stopgap solution and replacements for devices requiring SSL v3.0 should be actively pursued. https://www.openssl.org/news/secadv_20141015.txt

Quayls’ well-known SSL configuration checker tool has been updated to test for POODLE. You can input your websites URL to have it test for POODLE vulnerability: https://www.ssllabs.com/ssltest/

Further Resources:

In addition to the citations on this resource, please see:

The University of Michigan’s data on server support and presence of SSL v3.0: https://zmap.io/sslv3/

For technical details on how the vulnerability works, see Google’s original paper: https://www.openssl.org/~bodo/ssl-poodle.pdf

For the single best understanding of POODLE and what it means as a Internet user concerned with security, or a server operator, see Robert Graham’s notes on POODLE at his personal website: http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEUcTvnF-MJ

Microsoft’s Security Advisory on POODLE: https://technet.microsoft.com/en-us/library/security/3009008.aspx

 


The post SSL 3.0 POODLE Vulnerability Has Wide Ranging Effects appeared first on .

]]>
https://www.thesslstore.com/blog/ssl3-poodle-vulnerability/feed/ 0
SSL 3.0 POODLE Vulnerability Has Wide Ranging Effects https://www.thesslstore.com/blog/ssl3-poodle-vulnerability-affects-oodles/ https://www.thesslstore.com/blog/ssl3-poodle-vulnerability-affects-oodles/#comments Mon, 20 Oct 2014 08:24:02 +0000 https://www.thesslstore.com/blog/?p=1560 Thai Duong, Bodo Moller and Krzysztof Kotowiczis, three of Google’s security researchers, recently found a vulnerability in SSL 3.0, which has been referred to as POODLE (Padding Oracle on Downgrade Legacy Encryption). Per the latest Net Craft survey, nearly 97% … Continue reading

The post SSL 3.0 POODLE Vulnerability Has Wide Ranging Effects appeared first on .

]]>
Thai Duong, Bodo Moller and Krzysztof Kotowiczis, three of Google’s security researchers, recently found a vulnerability in SSL 3.0, which has been referred to as POODLE (Padding Oracle on Downgrade Legacy Encryption).

Per the latest Net Craft survey, nearly 97% of web servers in the world are likely to be vulnerable to POODLE attacks. The POODLE vulnerability affects the SSL certificate version 3.0 (SSLv3). It allows a man-in-the-middle attacker to access confidential information from the SSL session tokens after forcing the users’ browsers by sending thousands of similar requests. Due to this loophole, all major web browsers supporting SSL 3.0 versions are at risk.

SSL certificates are used by millions of websites to protect their users’ data and sensitive information. As an Internet user, you tend to encounter SSL-enabled security sessions frequently. For example, when you visit websites of highly reputed banks, such as CitiBank, Bank of America, etc. or some popular social networking websites like Facebook or Twitter, you typically access these websites with an https://, which is an SSL induced feature. As per a recent Net Craft report, the majority websites out of the top 1000 are supported by SSL 3.0. This makes major websites like citibank.com or bankofamerica.com vulnerable towards POODLE.

However, the good news is that most popular websites like Twitter, LinkedIn, and CloudFlare have already reacted to this vulnerability and disabled the support for SSLv3 on their servers. Most of the websites now rely on the support provided by TLS 1.2. By now, almost two-thirds of popular websites are taking this step to prevent the vulnerability from affecting their websites. However, TLS 1.0 is now the minimum version for 11% of websites, as you can see illustrated in the image below:

TLSv1 moving

This attack is essentially an oracle padding attack in CBC (cipher block chaining, where the output of previous blocks is used as an input to the next block processing for preventing the duplicate blocks of data from producing identical cipher text blocks) mode ciphers in SSLv3.

For a successful attack, a hacker must be on the same wireless network (or at least in the path of your communications) and your client must be running JavaScript (such as in a web browser) which makes the attack less serious than vulnerabilities compared like Heartbleed. This attack is effective against clients (as opposed to servers affected by Heartbleed or Shellshock) and so it is of the greatest concern to all users browsing on wireless hotspots where others may be listening, but serious enough that Twitter has announced they have entirely disabled SSLv3.

The following SCSV indicator can inform the compatible servers about the fallback connection and reject the connection unless the fallback was expected. It is already supported by Google Chrome and Google’s websites.

SSL3-Fallbak-browserssupport

What You Need To Do To Prevent a POODLE Attack on Your Web Browser(s):

There are a few ways to stop this vulnerability from compromising websites. They are:

  • Fallback SCSV.
  • Disabling SSLv3 on the client side.
  • Disabling SSLv3 on the server side.
  • Disabling CBC cipher suites in SSLv3.





However, ‘Disabling SSLv3 entirely’ seems to be the current trend being practiced by most websites. Users need to follow the instructions below disable SSLv3 from the major browsers.

1.Firfox
how to disable SSL3.0 in firefox

Here is a simple procedure to disable SSLv3 in Firefox:

Step 1 – Open the browser and link it to the SSL Version Control add-on.

Step 2 – Next, click on ‘Add to Firefox’, which will automatically disable SSL 3.0.

Step 3 – Now, open the Firefox Add-on manager by using the key combination Ctrl + Shift + Alt or write about: addons, find the add on ‘SSL Version Control’ and click on ‘Option’.

Step 4 – The initial automatic updated property is Default, you need to turn it ‘On’. Please note, the Minimum SSL Version property needs to be TLS 1.0.

With this step, Firefox will stop accepting SSLv3 certificates.

  • 2.Google Chrome
  • Unfortunately, Google Chrome is not providing any direct option to users for disabling SSLv3. However, users can disable it through their operating system.

    Windows

    1. Right click on the Google Chrome shortcut on the desktop
    2. Click on ‘Properties’ from the drop-down menu.
    3. You will see the following properties’ menu for the shortcut to Google Chrome.
    4. how-to-disable-SSL3-in-Googlechrome

    5. Click on the ‘Target’ box and scroll all the way to the right (past the quote (“)).
    6. Then, enter –ssl-version-min=tls1 as shown in the image given below.
    7. how-to-disable-SSL3-in-Googlechrome-step2

    8. Now Click “OK”.
    9. When asked for administrator permissions, click ‘Continue’.

    how-to-disable-SSL3-in-Googlechrome-step3

    Ubuntu

    1. Open /usr/share/applications/google-chrome.desktop in a text editor.
    2. For any line that begins with “Exec”, add the argument ‘–ssl-version-min=tls1′
      For example the line Exec=/usr/bin/google-chrome-stable %U should become Exec=/usr/bin/google-chrome-stable –ssl-version-min=tls1
    3. Reboot

    Other Operating Systems

    For any other operating system, launching Chrome from the command-line with the extra flag –ssl-version-min=tls1 will disable SSLv3. However, users need to consult their documentation for more details.

    3.Internet Explorer

    To disable SSLv3 in Internet Explorer on Windows Vista and newer versions, uncheck the ‘Use SSL 3.0′ box on the ‘Advanced’ tab in the Internet Options program.

    1. Launch the ‘Internet Options’ from the Start Menu
    2. Click on the ‘Advanced’ tab
    3. Uncheck ‘Use SSL 3.0′ as shown in the image below
    4. how-to-disable-SSL3-in-InternetExplorer

    5. And click ‘OK’

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    What You Need To Do To Prevent a POODLE Attack on Your Server(s):

    1. Apache
    To disable SSLv3 on your Apache server you can configure it as follows.
    SSLProtocol All -SSLv2 -SSLv3
    This will give you support for TLSv1.0, TLSv1.1 and TLSv1.2, and expressly remove support for SSLv2 and SSLv3. Check the config and then restart Apache.
    apachectl configtest
    sudo service apache2 restart

    2. NginX
    Disabling SSLv3 support on NginX is also very easy.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    Similar to the Apache config above, you will get TLSv1.0+ support and no SSL. You can check the config and restart.
    sudo nginx -t
    sudo service nginx restart

    3. IIS Server

    This one requires some registry tweaks and a server reboot, still the procedure is not that complicated. Microsoft have a support article with the required information, but all you need to do is modify/create a registry DWORD value.

    HKey_Local_MachineSystemCurrentControlSetControlSecurityProviders SCHANNELProtocols

    Inside protocols you will most likely have an SSL 2.0 key already, so create SSL 3.0 alongside it, if needed. Under that create a Server key and inside there a DWORD value called Enabled with value 0. Once that’s done reboot the server for the changes to take effect.

    Windowsserver-2012

    Users can check which SSL sites are still using SSLv3 using the Netcraft Tool.

    The post SSL 3.0 POODLE Vulnerability Has Wide Ranging Effects appeared first on .

    ]]>
    https://www.thesslstore.com/blog/ssl3-poodle-vulnerability-affects-oodles/feed/ 0