Posted Raising the Bar for Security and Trust on the Web on Blog
Recently, Symantec updated its certificate issuance controls to pay special attention to domains flagged for excessive abuse, malware, spam, and other suspicious activity. We recently received intelligence that .PW domains had a history of suspicious and abusive behavior. After further analysis, we decided to place a hold on issuing minimally-authenticated Domain Validated SSL/TLS certificates and are instituting a policy of only offering the stronger authenticated Organization and Extended Validation SSL/TLS certificates to .PW domains. Part of this change included the revocation of a small number of domain validated SSL/TLS certificates previously issued for these domains. Additionally, we have engaged with the registry that controls .PW to identify ways that can improve the safety of this top level domain for consumers. Several other country-code and generic top level domains are also special targets for attackers, which we will continue to evaluate on an on-going basis as well.
In contrast, forward looking, security minded registries, such as fTLD Registry Services, the owner of the .bank and .insurance top level domains are raising the bar for security for all of its customers. Considered a best practice, before authorizing a domain sale, these registries ensure that only valid, qualified entities operate on these domains and thereby protect the reputation of these spaces. As the original Certification Authority and the market leader for website security solutions, Symantec believes that verifying identity is critical for establishing trust and for ensuring the security of both consumers and the organizations they connect with online.
Symantec works with the general public to help identify fraudulent websites. If you would like to report SSL/TLS misuse, please log it here.
Mar 07 2018, 9:10 AM
Posted Symantec CryptoExec for cPanel & WHMCS Makes SSL Administration Easy for Hosting Providers on Blog
Symantec would like to introduce the new CryptoExec for cPanel and WHMCS for hosting providers. CryptoExec cPanel & WHMCS allows automating the SSL issuance process to mitigate errors and remove the manual steps in ordering and administration of SSL certificates for customers. The intuitive and easy to use GUI helps customers buy and install SSL certificates. Here is how it works:
The solution enables partners to utilize the popular WHMCS for billing/procurement of Symantec, GeoTrust, RapidSSL, and Thawte SSL and code-signing certificates and to provide a shopping cart experience. The partner can also offer Trust Seals through WHMCS.
One other advantage of the solution is the flexibility offered for purchase through the support for either a voucher-based path or a classic SSL-based path. The voucher-based path is recommended for partners who have both cPanel and WHMCS so a customer can buy vouchers in WHMCS and redeem them in cPanel. The classic SSL path is recommended for partners who use WHMCS but not cPanel.
CryptoExec also enables cPanel, the popular control panel solution for hosting providers. Partners can utilize this solution to redeem vouchers purchased through WHMCS and automatically install all SSL certificate types without any manual intervention.
Through cPanel, the Certificate Signing Request (CSR) generation is completely automated for partners who support both WHMCS and cPanel. Additionally, the end customer will see live status messages on the progress of the certificate’s validation and installation. cPanel will also provide a list of existing Symantec SSL certificates and the details related to each certificate. Through CryptoExec the complete lifecycle of an SSL certificate is covered; users can reissue, revoke and renew all SSL certificates through this solution.
CryptoExec cPanel and WHMCS modules also provide troubleshooting capability to hosting provider for the orders placed through WHMCS and cPanel.
For WHMCS and cPanel
Mar 07 2018, 9:10 AM
Posted The New 39-Month SSL Certificate Maximum Validity on Blog
The past few years within the SSL certificate industry have been busy with changes. 1024-bit RSA certificates are long gone, using public SSL certificates on servers with internal domain names is starting to disappear, and the SHA-1 hash algorithm is starting to see its final days. So what is next?
Starting 1 April 2015, Certification Authorities (CAs) are not permitted to issue SSL certificates (issued from a public root) with a validity period greater than 39 months. SSL certificates have limited validity periods so that the certificate’s holder identity information is re-authenticated more frequently. Plus it’s a best practice to limit the amount of time that any key is used, to allow less time to attack it.
In line with the latest Certification Authority/Browser Forum Baseline Requirements, CAs will stop issuing 4 and 5-year SSL certificates in the near future. Symantec plans on eliminating these options in late February 2015 on all SSL management consoles. Extended Validation (EV) SSL certificates still have a max validity period of 27 months but Organizational Validated (OV) and Domain Validated (DV) certificates (DV not offered by Symantec) will have this new 39-month lifespan.
So how will this affect those who install SSL certificates? The average person installing certificates in a large enterprise will have to go through the enrollment process a little more often. If the organization on that level and scale finds this detracts from employee productivity they may want to look at leveraging Symantec Certificate Intelligence Center Automation. To someone in a small organization who only issues SSL certificates on a very infrequent basis, they may find themselves looking for SSL installation instructions a little more often. To help you, Symantec has always offered a wealth of information online via our Knowledge Base (the preceding site will be migrating to this location in the near future) and offers amazing support by phone.
Please let us know what you think below in the comment section.
Mar 07 2018, 9:10 AM
Posted Symantec to Pre-Verify Applicants on .bank and .insurance gTLDs on Blog
As recently announced, fTLD Registry Services has partnered with Symantec to verify applicants before domain names are approved in the new .bank and .insurance generic Top-Level Domains (gTLDs). So what does this truly mean? Ultimately, it offers a form of brand protection for .bank and .insurance in this new era of the Internet.
July 2013 through February 2014 marked the second major landrush for addresses on the Internet. Companies from around the world applied to ICANN to operate nearly any gTLD they could think of (namely common search terms). For example we have applied to operate .symantec and .norton. With the new gTLDs as options for website developers, there are increasing risks to end-users who may confuse spoofed destinations with their real counterparts. For instance, let’s say ChelmoBank.com was a real address with millions of customers visiting daily.
Without pre-verification there would be little stopping a hacker from creating a spoofed ChelmoBank.bank or Chelmo.bank website in order to confuse my customers and funnel them into a phishing scam as they do with subdomains (e.g., ChelmoBank.example.com). fTLD Registry Services recognizes this and is acting as the responsible operator of this new portion of the Internet. Fundamentally, this is a best practice among gTLD operators. It not only provides better brand protection, but it also enables website owners to go through a majority of the processing for an SSL certificate, which will allow the owners to easily apply for and rapidly install an SSL certificate from Symantec. At the end of the day this drives value for gTLD operators and allows their new virtual tenants to be seated among other websites which have all been vetted. Personally, I see this as the equivalent of setting up shop in a shopping mall in an affluent neighborhood.
If other registry service organizations would be interested in doing something similar to what fTLD Registry Services has done.
Mar 07 2018, 9:10 AM
Posted SSL; More than Encryption on Blog
While doing an online search for “SSL Certificates” and one of the ads said “$4.99, Why Pay More?” Without clicking on the ad I know what they are going to offer me; a simple domain validated (DV) SSL certificate. This certificate will encrypt my site’s traffic at a basic level but this isn’t 1997; the business climate and threat landscape have changed and so have our requirements for security. SSL is more than encryption. We have to consider trust, security, service, certificate management & reliability. While many Certification Authorities are cutting corners to compete with each other on price, Symantec is working around the clock to continually deliver best-in-class solutions. At Symantec we believe in these core factors as does 91% of the fortune 500 and 94 of the top 100 financial institutions in the world. Here’s why:
1. Increased End-Consumer Trust
2. Stronger Business Authentication and Website Security
3. Simplified Certificate Management and Live Worldwide Support
4. Powerful Technical Capabilities and Advanced Options
5. Reliable Security and Business Assurances
Modern Security for Modern Needs
Companies that know security understand they need to use modern-day security solutions in today’s environment and that SSL is more than just simple encryption.Please keep all of these factors in mind as you are building out your webserver security plans.For more information on Symantec SSL, please visit our website.
Mar 07 2018, 9:10 AM
Posted Who's Watching You Sleep? on Blog
Thanks to George Orwell’s classic book 1984, I graduated High School thinking I would eventually live in a world monitored and suppressed by world governments. In the wake of the PRISM scandal in 2013 I started to get the feeling that Orwell’s dystopian novel was looking like an ill-timed prophesy. In light of comedian Pete Holms’ rant on how Privacy is Uncool, it is little brother (us) leaking our secrets; no one has to steal them from us. If you thought unmanaged Social Media privacy settings were bad, how much would you cringe if you knew you were letting people watch you sleep? Welcome to the perils of the Internet of Things (IoT).
Up until very recently a number of security camera manufactures were shipping internet connected cameras (AKA IP cameras) with default passwords. Many of these passwords were never changed by the purchaser after setting them up. It was only a matter of time that someone would set up a website displaying many of these feeds (Up to 73K at its peak).
Let me introduce Insecam, the website dedicating to not only showing you the unrestricted feeds of home and commercial security cameras but also to where they are located with all of the admin and password information. In addition to this they have social plugins that let you share your favorite feeds with your community. Ultimately taken from the pages of the improving-through-shaming security book, this site claims to seek the end of default passwords yet places advertisements conveniently next to navigation icons.
On my review of the site, I saw mundane shots of doors and walkways and more mild scenes of people working the front counters of gas stations and dry-cleaners. With a chill down my spine I saw a bartender drinking the profits and an overhead shot of a girl scrolling through a fashion site. What startled me was the shear amount of cameras in bedrooms, a no-no in my world. Granted that a majority of these were aimed at cribs but the alarming part was the number of unsecured cameras pointed at hospital patients, adult beds, living rooms, and private hot tubs. Sadly, various online forum contributors claim to have found dead bodies and adults in very private or intimate situations. Situations like this define the need for better security in the internet of things landscape.
No matter what colored bucket of hacker you place the Insecam’s creator into, they have exposed a gaping hole in the IoT landscape. In 2011 there were over 9 Billion devices connected to the internet and by the year 2020 it is expected that number will be close to 24 billion. This is a cause for concern for manufactures and companies like Symantec and a potential bonanza for hackers. As more and more things come online, we are discovering new vulnerabilities and how some security practices are becoming out of date. There are obstacles with current security practices but there are ways to overcome them.
Better Password Management
I’m not a fan of passwords. Since we have to live with them we have to learn how to use them. I wrote a fun mocku-blog on password best practices for you to loathe and share. Passwords are a very weak form of security and Insecam proved that. Two Factor authentication can be used to install and access IP camera feeds via a computer or mobile device. If you have the time, take a peek at this white paper from Symantec on digital certificates used for authentication.
When it is all said in done, Insecam victims used default ports and passwords and were most likely discovered by an IP address surfing tool. A simple change of the password would eliminate them from the site but it could still be guessed by a serious stalker. Keep in mind that passwords are the number one thing sought after by hackers since we often use the same ones on multiple sites. Here is how they do it.
Encryption; an IoT solution
As a best PKI practice, all data SHOULD be encrypted in transit and at rest between a Host and Client. If the device manufactures enabled encryption of the data, only the end user could review the video stream with client authentication. This would slow the feed a bit but it would secure the connection. If marketers want to instill trust in their internet connected devices they need to consider implementing a security promise with their messaging. So how can they encrypt a live feed?
My engineering buddy and counterpart Frank Agurto-Machado recommends the use of embedding a private SSL ROOT CA within each device. The connection between the manufacture’s infrastructure and the camera would be secured and encrypted via client authentication to this private SSL root. Ultimately, this may increase the cost of a device but it would help better ensure security. While this DOES NOT remedy the Password hijacking, it secures the model from point-to-point between the “client” and the host. Symantec offers Private CAs to enterprises that need customized encryption for server to server communication or for applications such as this.
The Security Trade-Off
Throughout the course of world history humans have always had to juggle between access and fortification when it comes to security. Our ancestors had to find a way to secure a food hoard that would not take hours to hide or cover. Castles had to ensure soldiers and citizens could pass freely yet survive a siege. Anti-virus software on your PC has to allow you to quickly surf the internet but check and possibly restrict all incoming traffic. Manufactures within the IoT space have to learn how to balance these two and improve customer messaging to assist them in setting up a trustworthy and secure devices.
Edit: Since the writing of this blog insecam has been shut down. From appearances it appears to be taken down by a third-party hacker.
Mar 07 2018, 9:10 AM
Posted The SSL 3.0 Vulnerability – POODLE Bug (AKA POODLEbleed) on Blog
A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).
(Updated Dec. 9, 2014) Recently, a new variant of the POODLE vulnerability (CVE-2014-8730) was found to affect even versions of TLS, the successor to the SSL protocol. This new vulnerability works against sites that use load balancers that have incorrectly implemented encryption padding checks, and may affect around 10% of servers. Certain models of F5 and A10 load balancers are susceptible, and as part of best practices we recommend that users apply vendor-supplied patches as they become available.
It is important to note that this is NOT a flaw in SSL certificates, their private keys, or their design but in the old SSLv3 protocol. SSL Certificates are not affected and customers with certificates on servers supporting SSL 3.0 do not need to replace them.
It’s believed to not be as serious as the Heartbleed bug in OpenSSL, since the attacker needs to have a privileged position in the network to exploit the latest. The usage of Hotspots, public Wi-Fi, makes this attack a real problem. This type of attack falls into the “Man-in-the-middle” category.
While SSL 3.0 was introduced in 1996, it is currently supported by nearly 95% of Web browsers according to Netcraft’s latest report. Many Transport Layer Socket (TLS) clients downgrade their cryptography protocol to SSL 3.0 when working with legacy servers. According to Google, an attacker that controls the network between the computer and server could interfere with the handshake process used to verify which cryptography protocol the server can accept using a “protocol downgrade dance”. This will force computers to use the older SSL 3.0 protocol to protect data that is being sent. Attackers can then exploit the bug by carrying out a man-in-the-middle (MITM) attack to decrypt secure HTTP cookies, which could let them steal information or take control of the victim’s online accounts. Although, at the time to writing, webmasters have been disabling SSL 3.0 and moving to TLSv1 and above at a rapid pace, there still remains a lot of work to be done. If Heartbleed taught us anything, it’s that the largest companies act fast while many small companies drag their heels in patching critical vulnerabilities.
What Businesses Need to Do
In order to mitigate the bug there are a few courses of action:
My fellow colleague Christoffer Olausson gives a few tips on how to fix this on Apache:
> SSLProtocol All -SSLv2 -SSLv3 <- Removes SSLv2 and SSLv3
> apachectl configtest <- Test your configuration
> sudo service apache restart <- Restart server
At the time of writing Google and Mozilla have either removed SSL 3.0 support from their browsers or are in the process of doing so.
What End-Users Need to Do
For end-users accessing websites Symantec recommends:
Symantec has published knowledge base articles on the subject for your reference. See below:
Symantec Managed PKI for SSL Users
Symantec Trust Center/Trust Center Enterprise Users
Mar 07 2018, 9:10 AM
Posted Google’s SHA-1 Deprecation Plan for Chrome on Blog
The latest news in the SSL and web browser industries is Google’s plans to deprecate SHA-1 in a unique way on upcoming releases of Chrome starting with version 39. Considerably different from Microsoft’s plans that were announced in November 2013, Google plans on placing visual marks or placing a block within the browser; all based on the version of the browser, date of use and certificate’s expiration date.
Here is what you need to know first:
What we expect to see with future Chrome releases:
Chrome 39 (Beta release: 26 September 2014, tentative production release: November 2014):
Chrome 40 (Beta release: 7 November 2014, tentative production release: post-holiday season):
Chrome 41 (Q1-Q2 2015):
Here is a matrix to help you understand the dates:
Moral of the story: Move to SHA-2, especially if your SSL certificate expires after December 2015.
What you need to do.
For more in-depth information, instructions, and assistance please refer to our knowledge center article on this subject. For a list of SHA-2 supported and unsupported applications review this list from the CA Security Council.
Read our SHA-2 webpage for the tools, steps to take, and a list of FAQs that can be generally applicable across all browsers.
Mar 07 2018, 9:10 AM