Category Archives: Website Security

Website Security Threat Report is Here

The first part of the WSTR 2015 is finally available, and dedicates a chapter to 2014 vulnerabilities and how they have changed our vision of threat response.

Twitter Card Style: 

summary

The first part of the WSTR 2015 is finally available, and dedicates a chapter to 2014 vulnerabilities and how they have changed our vision of threat response. You can read the first part of the WSTR here.

The good news is that we have discovered fewer vulnerabilities in 2014 than in 2013 (we have observed a 3.6% decrease). However, the bad news is that it doesn’t mean the discovered vulnerabilities were less dangerous. Three words are enough to make any IT manager shiver to the thought of what they have had to endure in 2014: Heartbleed, Shellshock, and Poodle.

Heartbleed is by far the vulnerability we have heard the most about. Discovered in April 2014, this bug received quite a lot of media attention as it impacted both users and servers, and didn’t require a man-in-the-middle position to exploit the vulnerability. It has been a year since the discovery of Heartbleed, and this bug is still raising concerns as it seems that many organizations didn’t remediate properly to the situation.             
 

Shellshock and POODLE were discovered later in 2014 – POODLE got a second round of attention in December when we discovered the vulnerability could affect TLS connections as well. Although less dangerous than Heartbleed, these vulnerabilities remained critical for website security and required immediate attention.

The 3 vulnerabilities shared a key similarity: they were related to technologies and software which have been widely accepted and used around the world, leading to serious and potentially dramatic data breaches if no action was taken to fix them.

This should, however, not be a reason to start panicking and foreseeing the end of website security as we know it today. Although its implementation has revealed critical flaws last year, the SSL/TLS protocol itself remains trusted and secure.

Furthermore, what the first part of the WSTR highlights here is:

  1. No matter what, we remain in a very fast-paced, rapidly-evolving sector with numerous third-parties – including hackers – and constant changes in norms and standards. To be realistic, these vulnerabilities discovered in 2014 are not the first and not the last we will hear about.
  2. We have learned from these vulnerabilities, and we are moving forward to a new type of management of our infrastructures. We can notably mention the faster response time of Microsoft and other major actors of the sector during such critical times, as well as the rise in awareness about the lack of funding for some Open-source projects and the dangers of re-using code as a general practice. What Tim Gallo jokingly refers as the “dirty secrets of application development” in pages 19-20 of the WSTR, part 1.  

Reusing code is indeed a well-known but deliberately concealed risk of Open-source projects. It is a convenient habit that no one really wanted to bring out from the shadow until Heartbleed put it under the spotlight. Yet instead of blaming each other for not having detected such a fatal flaw in OpenSSL, the website security industry didn’t stay inactive, and tried its best to learn and evolve. As Tim Galo underlined in the report, it had made everyone realize how we need a better organization of our network infrastructures. “Better enforcement of configuration, policy, and patching across entire infrastructures will help. The moving of infrastructure to the cloud also helps an overworked IT professional manage these issues as well”. The Core Infrastructure Initiative is, for example, a very positive result of the industry leaders’ reaction to Heartbleed.

Symantec strongly encourages such initiatives. We believe it is vital to react quickly, develop threat intelligence, document previous vulnerabilities and share as much data as possible in order to fight against the ever-evolving threat landscape. The WSTR we publish every year belongs to such initiatives and we would like not only every IT manager and application developer to read it, but also employees and individuals. Because we’re all concerned by the security of our data at some point – even if at different levels.

Could The Empire Have Been Saved by Better Encryption?

Twitter Card Style: 

summary

I jumped at the opportunity to write this blog – as my son’s name is Luke and therefore, “Luke, I am your father”.

Let’s remember that tense moment in Garbage Compactor 3263827:  after narrowly escaping Death-By-Dianoga, imminent demise again confronts Leia, Luke, Chewbacca and Han as the garbage compactor starts doing what garbage compactors do best.  The young rebels frantically call C3PO and R2D2 to shut down all the compactors on the detention level – and in those gripping minutes leading to their narrow escape, even the most hyperaware geeks all totally missed evidence that the Imperial IT/IS department made some pretty bad decisions about SSL certificates. 

Garbage.jpg

For two decades, SSL has been the guardian of encryption and validation on a very public internet, but also within enterprises – even evil enterprises like the Death Star.  And while the chronology means that SSL couldn’t have been in use a long time ago, in a galaxy far, far away, luckily the timing is fiction while SSL best practice is fact. 

This little lesson’s worth the effort.  Come, let me get you some SSL context: 

To save his colleagues in the compactor, R2D2 got access to a Death Star control system.  The Death Star’s systems believed that R2D2 was a legitimate agent of the Empire, and allowed him access.  Now, let’s presume that the data exchange which ensued between system access and compactor shutdown was over an encrypted channel (a classic implementation of encryption of data in motion in a server-to-server model).  Encryption wouldn’t have prevented R2D2 from doing anything – since he already had access to the network.

Had the Death Star’s systems required a digital certificate – what we now call SSL or TLS – for validation, not just encryption, the result might have been very different for not just our rebel friends, but ultimately for the Rebel Alliance and the Empire too – and for millions of Star Wars fans, in any galaxy for that matter. 

After all, losing track of Death Star plans isn’t Imperial IT’s only problem.  They also failed to observe best practices for usage of specific certificate types within their space station, as encryption couldn’t have prevented R2D2’s access.  Only the validation function of SSL could have resolved that. 

Stick with me here.  Use the Force.  Trust your feelings.  Let go.

Effectively, R2D2 was a man-in-the-middle.  Er, droid-in-the-middle.  But don’t let “MITM or DITM” distract.  If the Death Star’s server-to-server authentication demanded domain-validated certificates, the clever R2D2 could have easily obtained one of those since he literally was a man-in-the-middle.  (Think about all the various DV authentication methods – R2 could’ve faked any of them).  And upon system access, R2 just presented his DV certificate upon connecting the Death Star network and – ta da, he’s avoided any Imperial entanglements.  (As I’m writing this, I realize that the Empire would likely have obtained the very first ever TLD, presumably for .ge for galactic empire – making R2’s DV cert’s Common Name to be something like r2d2.deathstar.ge)

Now, if Death Star IT/IS had configured its systems to demand organization-validated (OV) or Extended Validation (EV) certificates for server-to-server communication, R2 would have either failed to connect (by having a DV cert) or failed OV/EV verification (since he couldn’t have proven that he’s a member of the Empire). 

No OV/EV = no (suitable) cert presented = this isn’t the droid you’re looking for = dead rebels.

Moreover, Imperial IT/IS would’ve been even smarter if they’d have selected any of Symantec-branded SSL certificates, which only come in OV and EV flavors – as the Symantec SSL validation and issuance infrastructures have never been compromised – since clearly the Death Star has its own breach problems.

Moral of the story:   demand Symantec OV or EV certificates, even for server-to-server usage.  And may the Force be with you.

Mitä kuluttajan tulisi tietää SSL-varmenteista

Twitter Card Style: 

summary

eBusiness Green Bar 400x210.jpg

1994 tehtiin ensimmäinen verkko-ostos: iso pepperonipizza herkkusienillä ja extrajuustolla, Pizza Hutista. Seuraavien 20 vuoden aikana verkkokauppatalous on ollut vilkasta ja 2013 myynti ylitti 1,2 biljoonaa Yhdysvaltain dollaria.

Verkkokaupankäynnin kasvu perustuu luottamukseen. Kuluttajat luottavat sivustojen pitävän kirjaa rahavirrasta, ja että ostosten tekeminen on turvallista ja laillista suurimmaksi osaksi Secure Socket Layer (SSL) –varmenteiden ansiosta, joka tunnetaan myös pienenä vihreänä lukkona osoitekentässä.

SSL-varmenteet varmistavat, että toimittaja on se, kenen he väittävät olevansa. Se osoittaa myös, että yhteys kuluttajan laitteiden ja yrityksen verkkosivujen välillä on turvallinen. SSL-varmenteiden toiminnallisuuden ymmärtäminen on tärkeää välttääkseen huijarien ansaan joutumisen. Sillä loppupeleissä kaikki sivustot – tai SSL-varmenteet – eivät ole luotu tasavertaisiksi.

Erilaiset varmennetyypit

Verkkosivustojen omistajat ostavat SSL-varmenteet varmentajalta (Certification Authority, CA). On olemassa kolmen tyyppisiä SSL-varmenteita, joista jokainen tarjoaa eri tasoisen suojan. Ongelma piilee siinä, että vaikka kaikki varmenteet tarjoavat selaimen osoitekenttään tutun turvalukon yhdessä HTTPS-yhteyden (”S” viittaa englannin turvattu-sanaan, ”secure”) kanssa, turvatasot vaihtelevat suurestikin. Tämän vuoksi on tärkeää ymmärtää millaista SSL-varmennetta sivusto käyttää ennen, rahallisen liiketoimen harjoittamista tai ylipäätään mitään, johon liittyy henkilökotaiset käyttäjätiedot.

  • Domain validated eli domainvarmennettu (DV):  Tämä vahvistaa sivuston omistajan. Prosessi on yksinkertainen, jossa varmentaja eli CA toimittaa sähköpostin siihen sähköpostiosoitteeseen, jolla sivusto on rekisteröity identiteetin vahvistaakseen. Yrityksestä itsestään ei vaadita tietoja. Verkkorikolliset käyttävät yleensä DV-varmenteita, koska ne on helppo hankkia ja sen avulla sivustosta saa turvallisemman kuvitelman kuin onkaan.  Huijarit saattavat käyttää DV-varmenteita houkutelleksaan kuluttajia tietojenkalastelusivustoille, jotka näyttävät aidoilta tai kopioidakseen jonkun sivuston näyttämään tunnetulta sivustolta, mutta jonka tarkoitus on varastaa henkilökohtaisia tietoja.
  • Organizationally validated eli yritysvarmennettu (OV): Saadakseen OV-varmenteen varmentajan on varmennettava tiettyjä tietoja, kuten yrityksen olemassaolon yritysrekisteristä, sen fyysisen sijainnin ja verkkosivuston omistajan. Prosessi kestää yleensä muutaman päivän.
  • Extended validation (EV): Tällä varmenteella on korkein suojaustaso ja se on helpoiten havaittavissa. Myöntääkseen EV-varmenteen varmentaja suorittaa hakijasta tehostetun tarkistusprosessin kasvattaakseen yrityksen luottamusta. Tarkistusprosessissa käydään läpi yrityksen asiakirjat, varmennetta hakevan henkilön identiteetin tarkistus ja tietojen tarkistus kolmannen osapuolen tietokannasta. Turvalukon ja HTTPS:n lisäksi EV-varmenteella suojattu sivusto muuttaa osoitekentässä olevan yrityksen nimen vihreäksi.

Huomaatko eron?

norton-communiy.png

Viimeisin osoite on selvästi suojattu EV-varmenteella. Ensimmäinen on DV-varmenne ja keskimmäinen OV-varmenne, jotka näyttävät verrattaessa identtisiltä.

Mitä voi tehdä pysyäkseen turvassa?

Nyt kun tiedetään mikä SSL-varmenne on ja sen kolme eri tyyppiä, ja että DV-varmenteella suojattu sivusto on huijatuksi tulemisen riskialueella, kuinka käyttäjät voivat pienentää riskiä shoppaillessaan ja naputellessaan muuta kriittistä tietoa verkossa?

  1. Ole varuillasi! Vaikka sivustolla olisi turvalukko tai osoiterivin alussa “https” ei tee sivustoa turvalliseksi rahaliikenteelle. Käyttäjät ovat oppineet etsimään näitä kahta ennen tapahtuman läpiviemistä ja juuri tästä syystä verkkorikolliset näkevät vaivan hankkia SSL-varmenteen – näyttääkseen aidolta sivustolta.
  2. Opettele erottamaan, mitä varmennetyyppiä sivusto käyttää. Etsi ensimmäiseksi visuaalisia vihjeitä, kuten lukkosymbolia ja osoitekentän vihreää väriä. Ainoastaan EV-varmennetut sivustot ilmoittavat yrityksen nimen osoitekentässä. Selaimet eivät osaa erottaa DV-varmennetta OV-varmenteesta. Norton on luonut ilmaisen työkalun (https://safeweb.norton.com/) varmenteiden erottamiseksi. Kopioi verkkosivun osoite suoraan työkalun kenttään ja se kertoo, mitä varmennetyyppiä sivusto käyttää ja kuinka turvallinen sivusto on kyseessä.
  3. Asioi ainoastaan OV- ja EV-varmenteilla suojatuilla sivustoilla. DV-varmenteille on aikansa ja paikkansa, mutta niitä ei tulisi käyttää kaupallisilla sivustoilla. Jos käyt testaamassa osoitteen Nortonin työkalulla ((https://safeweb.norton.com/) ja tuloksena on DV-varmenne, mieti kahdesti ennen kuin asioit pidemmälle kyseisellä sivulla. Jos kyseessä on OV- tai EV-varmennettu sivusto tiedät, että yrityksen tiedot ovat tarkistettu.

Verkkoshoppailu ei ole katoamassa mihinkään. Niin kauan kun ala ei vaadi OV- ja EV-varmenteiden käyttöä kuluttajien on kannettava kortensa kekoon riskien minimoimiseksi verkossa.  Kun riskit on tiedossa, kuluttajat jäävät mitä pienemmällä todennäköisyydellä tietojenkalastelijoiden ansaan.

Lisätietoja SSL-varmenteista löytyy hiljattain julkaistusta Symantec whitepaperista (https://www.symantec-wss.com/us/ecommerce-security#.VSfVctW3dYZ) tai vierailemalla Trust Services (https://www.symantec.com/ssl-certificates/) –sivustollamme.

Alkuperäinen teksti: https://community.norton.com/en/blogs/norton-protection-blog/ssl-certificates-what-consumers-need-know

Symantec’s essential guide to today’s threat landscape. Part 1 Out now

In 2014 , the foundations of Internet security were shook by the Hearthbleed bug, a vulnerability of human-built software that reminds us of the need for vigilance, better implementation and more diligent website security.

As part of that story, we saw criminals grow more professional, sophisticated and aggressive in their tactics to the detriment of businesses and individuals.  Poodle and Shellshock provided ways to criminals to use websites to access servers, steal data and install malware;  cryptoware – variant of ransomware encrypts a victim’s files – increased significantly  and  even social media and phishing scams took advantage of people’s fears around hacking to entice them into clicking.

Symantec  has the most comprehensive source of Internet threat data in the world and also maintains one of the world’s most comprehensive vulnerability databases. Spam, phishing and malware data is captured through sources including   Symantec.cloud and other Symantec security technologies; Our websites security solutions provides 100 percent availability and processes over 6 billion online certificate status protocol looks-ups per day.  These resources give Symantec analysts unparalleled sources of data with which to identify, analyse, and provide informed commentary on emerging trends in attacks, malicious code activity, phishing and spam.

The result is the Symantec Website Security Threat Report, which gives enterprises, small businesses, and consumers essential information to secure their systems effectively now and into the future.

Let’s start to point out some of the trends in cybercrime we saw last year:

Web threats

Web threats got bigger and much more aggressive in 2014 as holes in commonly used tools and encryption protocols were exposed and criminals made it harder to escape their malicious clutches.

With no doubt, Heartbleed was the most remarkable security event last year;  a vulnerability in the OpenSSL cryptographic software library meant attackers could access the data stored in a web server’s memory during an encrypted session. Although the response was swift and within five days, that event caused many more people to take note and improve standards in SSL and TLS implementation.

ShellShock and Poodle were other example of vulnerability that appeared last year.

Of all the websites Symantec scanned for vulnerabilities in 2014, around three quarters were found to have vulnerabilities – about the same as last year, however,  the number of websites actually found with malware was much lower than last year, having reduced from 1 in 566 to 1 in 1,126.

Ecrime & Malware

Every day, personal banking details are phished by fake emails and websites. Computers infected with malware are used to send out spam or contribute to distributed denial-of-service attacks. Perhaps the most unlucky see all their files encrypted and their computer made unusable by ransomware.

The underground black market is thriving. Criminals are moving their illegal marketplaces further from public gaze; they have become more professionals and have sophisticated their cybercrime techniques.

Malware – distributed by email- has declined in 2014 but it still reminds as a very dangerous tool of cybercrime or  Ransomware, alternative way of cybercrime-  used to encrypt the data on victims hard drives and demand payment to unlock the files; both are some examples of how criminals work.

Malvertising

During 2014, we saw ransomware and malvertising cross paths as the number of victims getting redirected to the Browlock website hit new heights.

Browlock itself is one of the less aggressive variants of ransomware. Rather than malicious code that runs on the victim’s computer, it’s simply a web page that uses JavaScript tricks to prevent the victim from closing the browser tab.  But iIt’s not just ransomware that malvertising helps to spread: malicious adverts also redirect to sites that install Trojans.

From the website side, it is hard to prevent malvertising, as they have no direct control over the ad networks and their customers. However, site managers can reduce risk by choosing networks that restrict ad functionality so advertisers cannot embed malicious code in their promotions. And of course, when selecting an ad network, due diligence goes a long way.

15948-Symantec-WSTR-403x403fb-V2_0.jpg

Download your free copy of the Symantec Website Security Threat Report Part 1 here: https://www.symantec-wss.com/uk/WSTR-2015-1/social

Discover more about today’s threat landscape in Part 2 of the WSTR. Coming soon.

Stay up to date on potential changes to RC4 encryption algorithm

Twitter Card Style: 

summary

index.jpg

All the major browsers provide “security user interface”, meaning visual elements to inform the user of the security of their connection to the web page they’re visiting. Up until now, those interface elements were tied to the use of SSL/TLS certificates served by the web site. For example, if you went to http://www.example.com, no special elements would be displayed, but if you visited https://www.example.com, you would see a lock icon indicating the presence of a trusted SSL/TLS certificate. You would also see in the address bar the name of the company responsible for the web site, if the web site used an EV certificate. Most browsers change user interface indicators for mixed content (when a secure page loaded scripts, images or other content from a non-secure site).

Some browser vendors are planning to warn users about potential weaknesses in RC4, a popular stream encryption algorithm used in various ciphersuites defined for SSL/TLS, by changing their security user interfaces.

Concerns about RC4 have led the Internet Engineering Task Force (IETF) TLS Working Group to declare that “RC4 can no longer be seen as providing a sufficient level of security for TLS sessions.”, even though it was the preferred method of defense against the BEAST attack years ago.

If your browser and the website you’re visiting negotiate to use a ciphersuite that includes RC4, browsers will warn you by a security user interface change. If the site has an EV certificate, the browser may decline to show the EV display. This is important to understand, since users may expect that security user interface warnings indicate a problem with the website’s certificate, but there may be nothing wrong with the certificate or its chain.

Perhaps more importantly, browser vendors are considering security user interface warnings if RC4 is used in any sub-connection used to build a page. Recall that most modern web pages are built on the fly from multiple sources: static images may be served by a Content Distribution Network (CDN), scripts may come from open source sites, and seal images may be served by the Certificate Authority that issued the website’s certificate. The use of RC4 in any of those connections could result in a broken lock icon or the loss of EV display.

We’re not arguing that it’s unwise to warn about RC4 in a sub-connection – we’re just concerned that many website owners may assume something is wrong with their certificate, and it’s very difficult to determine which sub-connection used RC4 and was responsible for the user interface downgrade. Browser vendors can help by developing enhanced error reporting that pinpoints the cause of the downgrade, allowing website owners to quickly remediate the problem. By the way, remediation would consist of re-configuring the offending web server to de-prioritize or remove those ciphersuites that use RC4. Modern alternatives exist that do not use RC4 and therefore are not affected by its weaknesses.

Symantec provides web-based tools like SSL Toolbox to detect problems with SSL/TLS certificates and chains. We’re also investigating tools and methods to locate websites that still use RC4, to help our customers address RC4-related issues and restore favorable security user interface indicators.

How the Private and Public Key Pair Works

Twitter Card Style: 

summary

Did you know this month was “couple appreciation month”? Let’s use this as an opportunity to explain in simple words how the security of an online transaction relies on a happy, inseparable couple: a public key and a private key.

Public keys and private keys are part of a general structure we call PKI – Public Key Infrastructure. The SSL and TLS protocols, which are globally used to secure not only websites, but also emails and web applications, are based on this structure. So we might as well say that there are thousands and thousands of public and private keys in operation right now around the world!

Keys are used in algorithms to encrypt and decrypt data. You may think the same key is used to encrypt and decrypt, but there’s a twist: there are algorithms in this world which are able to encrypt data with one key… and decrypt it only with the help of another key! Magical, isn’t it? (For those who don’t believe in magic, you can read more about trapdoor functions here). In the case of SSL, one key – the public key – is used to encrypt data; only the corresponding private key can decrypt it. What a lovely (and useful) couple.

Couple_Appreciation_1.png

In the SSL protocol, public keys and private keys are generated by servers. The private key remains locked and secure in the server, while the public key is pinned to the server’s SSL certificate. Whenever a browser connects to the server, the server sends its SSL certificate which contains the public key. The browser can then use this public key to encrypt data and send it to the server, which is now the only one able to decrypt such data thanks to its private key.

Both keys are inseparable, and of course each pair is unique: the public key belongs to its corresponding private key and only to this one.

Couple_Appreciation_2.png

Public and private keys are essential to the security of our exchanges. Thanks to them, we don’t have to worry about someone eavesdropping on our conversations. But there is still a major issue: what if a hacker intercepts the server’s public key, and sends their own public key instead?

What guarantees the browser that the public key received is actually the public key from the server it wanted to reach?  This is why Certification Authorities like Symantec play an essential role: CAs authenticate servers and their public key through a unique document called the SSL certificate!

If you’re curious about SSL and more specifically about how SSL certificates work, you can find more

SSL Certificates: What Consumers Need to Know

Twitter Card Style: 

summary

In 1994, the first online purchase crossed the World Wide Web: a large pepperoni pizza with mushrooms and extra cheese from Pizza Hut. Over the next 20 years, e-commerce has exploded into a bustling economy, exceeding $1.2 trillion in sales in 2013.

This growth in online purchases rests upon a foundation of trust. People trust that the websites they use to track finances and make online purchases are secure and legitimate largely because of Secure Socket Layer (SSL) certificates- otherwise known as that little green padlock in the URL bar of the browser.

SSL certificates verify that the provider is who they claim to be and also indicate secure connections between personal devices and company websites. Understanding SSL certificates is important to help prevent falling victim to scammers. Because at the end of the day, not all sites, or SSL certificates, are created equal.

Different types of certificates

Website owners purchase SSL certificates through Certification Authorities (CA). There are three different types of SSL certificates, each providing a different level of security. The problem is that, even though all of these certificates provide the safety padlock in the URL bar of a browser, along with the HTTPS (“S” indicating “secure”) in the address bar,  the levels of security between types of certificates differ greatly. This is why it is important to understand what kind of SSL certificate a site is using when looking to perform financial transactions or anything involving personal user data.

  • Domain validated (DV): This simply verifies who owns the site. It’s a simple process where the CA will send an email to the website’s registered email address in order to verify their identity. No information about the company itself is required. Cybercriminals commonly use DV certificates because they are easy to obtain and can make a website appear more secure than it actually is. For instance, fraudsters may use DV certificates to lure consumers to phishing websites that look authentic, or to cloned websites that look legitimate, but are designed to steal sensitive information.
  • Organizationally validated (OV): To receive an OV certificate, a CA must validate certain information, including the organization, physical location and its website’s domain name. This process typically takes a couple of days.
  • Extended validation (EV): This certificate has the highest level of security and is the easiest to identify. In order to issue an EV certificate, the CA performs enhanced review of the applicant to increase the level of confidence in the business. The review process includes examination of corporate documents, confirmation of applicant identity and checking information with a third-party database. In addition to adding the padlock in the URL bar of the browser, the “S” part of HTTPS, this adds the company’s name in green in the browser URL bar.

Can you tell the difference?

SSL.jpg

Clearly, the last URL is an EV certificate. The first is the DV certificate and the second is an OV certificate, which both look identical to each other.

What can people do to stay safe?

Now knowing what a SSL certificate is, the three different types, and that DV-enabled sites pose a risk for scams, how can users reduce the risk of shopping or performing other sensitive transactions online?

  1. Be aware! Just because a website has the padlock or “https” next to a URL doesn’t make it safe for financial transactions. Users have learned to look for those two things before conducting a transaction, which is exactly why cybercriminals are going through the trouble of obtaining SSL certificates in the first place – to look like a legitimate site.
  2. Know how to look for the type of SSL certificate a website has. As a first step, look for visual cues indicating security, such as a lock symbol and green color in the address bar. Only EV-enabled websites include the company name in the web address bar. Browsers do not distinguish a DV certificate from an OV certificate, however. To make it easy to tell the difference, Norton has created a free tool. You simply paste a URL directly into the tool and it will tell you if the site is DV-, OV- or EV-enabled, with results clearly highlighting how safe a site is.
  3. Only conduct transactions and provide sensitive data to sites that have OV or EV certificates. There’s a time and place for DV certificates, but that doesn’t include using them for e-commerce sites. If you drop a URL into the Norton tool and the tool reports that the site has a DV certificate, rethink conducting any type of transaction via that site. If it’s an OV or EV certificate site, you know that the business information has been confirmed.

Let’s face it – online shopping isn’t going away. Until the industry requires an OV or EV certificate for e-commerce sites or an easier way to identify the types of certificates, people will have to bear some of the burden of combatting cyber risks. Knowing the risks ahead of time, consumers are less likely to be duped by phishing websites.

Readers can find more information on SSL certificates in this recent Symantec whitepaper or by visiting our Trust Services page.

The FREAK Vulnerability; What You Need to Know

A new SSL/TLS vulnerability named “FREAK” was identified by several security researchers.

Twitter Card Style: 

summary

A new SSL/TLS vulnerability named “FREAK” was identified by several security researchers. It’s a threat because FREAK allows an attacker to get between a client and server and view what is intended to be a secure and private communication. The vulnerability is primarily due to a bug in OpenSSL client software, but only exploitable on poorly-configured web servers. Both clients and servers are at risk. Web site owners can protect their sites by properly configuring their web servers. End users will need to wait for browser vendors to release new versions that include the OpenSSL bug fix.

Note that this vulnerability is not related to SSL certificates. Your existing certificate will continue to work as intended; no certificate replacement is needed.

Organizations should evaluate their web servers to determine if they are vulnerable.  Symantec expects to offer an easy-to-use check in its SSL Toolbox to allow customers to easily verify that their web sites are safe or vulnerable. This will be announced when available. At the time of this writing, Symantec is evaluating its own systems and no Symantec web servers appear to be vulnerable.

Blue Digital Lock 600X.jpg

Technical Details:

It’s relatively easy to determine if a website is vulnerable, and if so, it’s relatively easy to change the configuration to block any possible attacks. Any type of web server (Apache, IIS, nginx, etc.) may be vulnerable if its configuration allows the use of so-called Export Ciphers. In Apache/OpenSSL documentation, for example, the names of these ciphers all begin with EXP (from https://httpd.apache.org/docs/2.4/mod/mod_ssl.html):

EXP-DES-CBC-SHA

EXP-RC2-CBC-MD5

EXP-RC4-MD5

EXP-EDH-RSA-DES-CBC-SHA

EXP-EDH-DSS-DES-CBC-SHA

EXP-ADH-DES-CBC-SHA

EXP-ADH-RC4-MD5

If a customer’s web server supports these ciphers, the customer must reconfigure the web server by removing these ciphers from the list of supported ciphers, and restart the web server. Although not related to this vulnerability, customers should also disable null ciphers if they are supported, since such ciphers do not provide any encryption of the SSL stream:

NULL-SHA

NULL-MD5

In Windows, the names of export ciphers contain the string “EXPORT”. Here is a list taken from http://support.microsoft.com/kb/245030:

SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA

SSL_RSA_EXPORT1024_WITH_RC4_56_SHA

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5

SSL_RSA_EXPORT_WITH_RC4_40_MD5

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

TLS_RSA_EXPORT_WITH_RC4_40_MD5

NULL

We advise customers to consult their web server documentation to determine how to view the list of supported ciphers, and how to disable certain ciphers.

Additional guidance from Symantec

FREAK is another reminder that website security is not just about certificates. Symantec has numerous articles and white papers on security best practices and technical areas related to SSL/TLS and code-signing issues.  Please stay tuned to our Connect blog site for up-to-date information on this and other critical vulnerabilities, for other topics related to advanced threat protection, and for security industry news.  Please access our learning center for more resources that can help your organization make critical decisions related to web server security.  For technical details to help with troubleshooting please bookmark our SSL/TLS and code-signing knowledge base.

SSL Market Leadership

      No Comments on SSL Market Leadership
Twitter Card Style: 

summary

As you might imagine, the Trust Services team at Symantec found ourselves scratching our heads last week when one of our competitors in the SSL market announced that it was now the “number one” certification authority in the world.  How could this claim be real, we questioned?  After all, for over 20 years, market analysts and customers alike have recognized Symantec as the leading and most trusted provider of SSL certificate products, solutions, and services around the world. 

With our curiosity piqued, we did a quick check of the most recent market reports and metrics from both Frost & Sullivan and Netcraft, the two most respected SSL market analysts in the industry.  While Frost & Sullivan analyzes the SSL market from a business perspective based on the revenue share of the various competitors, Netcraft actually crawls the Internet to analyze webservers and SSL certificate information to quantify market size and share.

Their studies continue to show Symantec at the top of the market (see chart below). 

Worldwide Marketshare for SSL Certificates 2015-1.png

Numbers aside, at Symantec, we believe “leadership” is earned rather than claimed.  Symantec’s success has largely been the result of our award-winning track record of Trust, Reliability, and Speed for our customers.  Over the years, we’ve demonstrated best-in-class OCSP response times allowing for faster and more secure web transactions for online businesses and consumers around the world.  Moreover, the Norton Secured Seal has continuously been displayed over half a billion times per day on websites in over 170 countries, serving as the most recognized trust mark on the Internet.  Over the past 2 decades, during the

tremendous growth of Internet activity and increased security threats, Symantec’s global infrastructure has NOT ONCE been compromised, never suffering a breach.  On the other hand, less than a week after this competitor claimed to be “number one” in the SSL market, the U.S. Department of Homeland Security reported on PrivDog, an SSL tampering tool associated with the competitor (see http://www.theregister.co.uk/2015/02/24/comodo_ssl_privdog).

So we’ll let the market decide, while we continue to do our best for our customers, earning every bit of trust that we can each day.

What is OCSP?

      No Comments on What is OCSP?
Twitter Card Style: 

summary

The OCSP (Online Certificate Status Protocol) is one of the two ways for obtaining the revocation status of X.509 digital certificate (e.g. SSL & code-signing certificates) and hence maintains the security of a server or other network resource. The other older mechanism, which OCSP has superseded, is known as “CRL (Certificate Revocation List).”

OCSP overcomes the chief limitation of CRL: the fact that updates must be frequently downloaded to keep the list current at the client end. When a user attempts to access a server, the OCSP sends a request for certificate status information. The server sends back a response of “Success”, “Unauthorized”, “Malformed Request” or “Try Later”. The protocol specifies the syntax for communication between the server (which contains the certificate status) and the client application (which is informed of that status. OCSP responses contain less information than a CRL so it puts less burden on the network and the calling resources.

An OCSP request is a signed message.  It consists mainly of two components: a request body, and an optional signature block.  The request body contains one or multiple certificate status requests.  The body consists of the following fields:
 
Version – OCSP Request version number.  It is default to v1.
Requestor name – optional field
One or more requests – web server only include one certificate status request per OCSP request message.
Extensions – This optional field to include extra information which may be communicated between the client and the OCSP server, such as the expected OCSP response message type from the client, nonce, or archive cutoff date, etc. 
 
Of all these components, the most important component is the certificate status request structure.  It consists of the following:
 
HashAlgorithm – this field specifies the digest algorithm, which is used to digest the CA, subject DN or CA key.
IssuerNameHash – digest of the EE’s CA subject DN
IssuerKeyHash – digest of the EE’s CA public key or a unique key identifier
SerialNumber – EE certificate serial number
The combination of the SerialNumber and the IssuerNameHash or the SerialNumber and the IssuerKeyHash uniquely identifier the EE certificate signed by the CA.

How did Symantec improve OCSP Performance?

Origin Server:  Symantec built a highly efficient and responsive OCSP infrastructure.

CDN: Symantec worked with a CDN to make their EdgeServer OCSP aware and able to read the ASN.1 request and response package.

  • Handle the OCSP traffic intelligently:
    • Use the nextUpdate timestamp to determine the expiration time in cache
    • Use the CertID sequence from the OCSP Request to determine the cache key.  Specifically issueNameHash + issueKeyHash + serialNumber.
    • Check for the presence of the nonce extension (id-pkix-ocsp-nonce) and handle appropriately.
    • Provide the ability to invalidate the CDN cache based on the OCSP URI and OCSP Key for revoke case.
    • Provide reporting on overall traffic and request plus the top 50 requested URIs.
    • Provide the ability to limit the size of the edge for ACLs.
    • Provide the ability to handle OCSP requests without HTTP Host headers.

If the response for a requested cert is found in CDN cache, it’ll be returned from the cache.

If a response can’t be found in cache, a request will be sent to origin server (Symantec OCSP responder) to retrieve the response and stored in cache for later lookup.

Symantec built an OCSP responder to handle any cache miss requests.

What is the Net Result?

The result of our work is that we have become the fastest within the industry. When one adds together the average speeds of our competitors you can see how fast Symantec really is.  The other thing to note is not only is there a massive difference in speed but also a difference in regularity.  Certain days will have more or less demand on the OCSP infrastructure than others, but ultimately, Symantec’s speed is far more consistent that the wild ups and downs of other CAs trying to keep pace with the demands of a modern internet.

OCSP_Performance_Chart_Jan2015_r2_1.jpg

Do you want to go faster?

If speed is important to your organization then why not consider using ECC SSL certificates?  The majority of SSL certificates used today are based on RSA, an aging algorithm.  ECC is the next generation; it uses tighter math and therefore runs more efficiently than RSA.  This allows a server to run more sessions with one company reporting a 46% drop in CPU utilization and a 7% improvement in server response times.  

Please let us know what you think or if you have any questions.  You can reach out on Twitter or follow us on Facebook.