There has been a lot of talking, over the past few months, about a Firefox extension called Firesheep which, in the words of author Eric Butler,

"demonstrates  HTTP session hijacking attacks".

Discussions around the Internet on the matter have been quite heated, with lots of people thanking him for his efforts in raising awareness on the security issues of modern Internet applications, and many others blaming him for making it way too easy for anyone -even people who know close to nothing regarding security- to hack into other people's accounts on social networks, webmails and other web applications, provided some conditions are met. In reality, all these issues have been well known for years, so there is very little to blame Butler for, in my opinion, while we should pay more attention to the fact that most websites are vulnerable to these issues, still today.  So, if the issues highlighted by Firesheep hardly are news, why has it caught so much attention over the past few months?

Some context

Whenever you login on any website that requires authentication, two things typically happen:

1- first, you are usually shown a page asking you to enter your credentials (typically a username and a password -unless the service uses  OpenID or any other  single sign on solution, which is a quite different story), and upon the submission of a form, if your credentials match those of a valid account in the system, you are authenticated and thus redirected to a page or area of the site whose access would otherwise be forbidden.

2- for improved usability, the website may use  cookies to make logins persistent for a certain amount of time across sessions, so you won't have to login again each time you open your browser and visit the restricted pages -unless you have previously logged out or these cookies have expired.

During the first step, the authentication requires your credentials to travel over the Internet to reach their destination, and  -because of the way the Internet works- this data is likely to travel across a number of different networks between your client and the destination servers; if this data is transferred in clear on an unencrypted connection, then there is the potential risk that somebody may be able to intercept this traffic, and therefore they could get hold of your credentials and be able to login on the target website by impersonating you. Over the years, many techniques have been attempted and used with different degrees of success to protect login data, but to date the only one which has proven to be effective -for the most part- is the full encryption of the data.

In most cases, the encryption of data transferred back and forth between the servers hosting web applications and the clients, is done by using  HTTPS. That is, the standard HTTP protocol, but with the communication encrypted with  SSL. SSL works pretty well for the most part: nowadays it is economically and computationally cheap, and it is supported by many types of clients. SSL encryption isn't perfect though; it has some technical downsides more or less important and, besides these, it often gives the user a false sense of security if we also take into consideration other security treats concerning today's web applications such as -for example-  Cross-Site Scripting: many people think that a website is "secure" as long as it uses SSL (and some websites even display a banner that says "this site is secure" and links to their provider of SSL certificates... -good cheap advertising for them), while in reality most websites may be affected by other security issues regardless of whether they use SSL encryption or not. However,  if we forget for a moment other security issues, the main problem with SSL encryption is, ironically, in the way it is used by most web applications, rather than in the SSL encryption itself.

As mentioned above, web applications usually make use of cookies to make logins persistent across sessions; this is because the web is  stateless. For this to work, these cookies must travel between client and server with each request, that is for each web page you visit during a session within the same web application. This way the application on the other side can recognise each request made by your client and keep you logged in for as long as the authentication cookies are available and still valid.

The biggest problem highlighted by Firesheep is that most websites only enable or enforce SSL encryption during the authentication phase, so to protect your credentials while you log in, but then revert to standard, unencrypted HTTP transfers from that point on. This means that if the website makes logins persistent by using cookies, since these cookies -as said- must travel with each request, unless the authentication tokens stored in these cookies are themselves encrypted and thus protected in a way or another (on the subject, I suggest you read  this), as soon as the user has been authenticated these cookies will travel with subsequent HTTP requests in clear (unencrypted) form, so the original risk of somebody being able to intercept and use this information still exists; the only difference is that in this case an attacker would more likely have to hijack your session by replaying the stolen cookies in their browser, rather than trying to login themselves by entering your credentials directly in the authentication form (this is because these cookies, usually, store  authentication tokens rather than credentials). The end result, however, is pretty much the same, in that the attacker can impersonate you in the context of the application.

So, why don't websites just use SSL all the time?

CPU usage, latency, memory requirements

At this point, if you wonder why all companies don't just switch SSL on by default for all their services all the time, perhaps the most common reason is that, traditionally, SSL-encrypted HTTP traffic has been known to require more resources (mainly CPU and memory) on servers, than unencrypted HTTP. While this is true, with the hardware available today this really is no longer too big of an issue, as also demonstrated by Google when they decided to allow SSL encryption for all requests to their services, even for their popular search engine. Here's is what Google engineer Adam Langley said on this a few months ago:

" all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. "

So, if SSL/HTTPS does not require a significantly higher amount of resources on servers, is it just as fine as unencrypted HTTP, only more secure? Well, more or less. In reality, SSL still introduces some latency especially during the handshake phase (up to 3 or 4 times higher than without SSL), and still requires some more memory; however, once the handshake is done, the latency is slightly reduced, plus Google are working on ways to improve latency. So connections are a bit slower, true, but Google -see Langley's blog post- have partially solved this issues by caching a lot also HTTPS requests. Google have also solved the issue with higher memory usage by patching  OpenSSL to reduce up to 90% the memory allocated for each connection.

Static content and CDNs

Besides CPU/memory requirements and increased latency, there are other issues to take into account when switching SSL on all the time for a website. For example, many websites (especially large and popular ones like Facebook and others that are also targeted by Firesheep) use a  CDN distribution to reduce load on their servers, as well as to improve performance for their users depending on their geographical location; CDNs are great for this since they are highly optimised to serve static content from locations that are closer to users. This often reduces latency and so helps improve the overall performance of the site for those users. In most cases, using a CDN is as easy as serving the static content from  canonical hostnames that point to the CDN's servers directly.

But what happens if a website using a CDN is adapted to use SSL all the time? First, a few general considerations on the usage of SSL encryption with static content.

By "static content", we usually mean images, stylesheets, JavasScript, files available for download and anything else that does not require server side processing. This kind of content is not supposed to contain any sensitive information; therefore, at least in theory, we could mix SSL-encrypted, sensitive information served via HTTPS, with unencrypted static content served via HTTP, for the same website, at the same time. In reality, because of the way SSL support is implemented in the browsers, if a page that uses SSL also includes images and other content that is downloaded with normal HTTP transfers, the browser will show warnings that may look "scary" to users who do not know what SSL/HTTPS is. Here's an example with Internet Explorer:

Because of this, it is clear that for a page using SSL to work correctly in browsers, all the static resources included in the page must also be served with SSL encryption. But this sounds like a waste of processing power.. doesn't it? Do we really need to encrypt images, for example? So you may wonder why browsers behave that way by displaying those warnings. Actually, there is a very good reason for this: remember cookies? If a web page is encrypted with SSL but it also includes resources that are downloaded with standard, unencrypted HTTP transfers, as long as these resources are served from hostnames that can access the same cookies as the encrypted page those cookies will also travel in clear over HTTP together with those resources (for reasons I've already mentioned), making the SSL encryption of the page useless in first place. If browsers didn't display those warnings, it would be possible to avoid this issue by serving the static resources from hostnames that cannot access the same cookies as the encrypted page (for example, with the page served from mydomain.com and static content served from anotherdomain.com), but it's just easier and safer to enforce full SSL encryption for everything...

Sounds dirty and patchy, yeah? That's the web today... a collection of technologies developed for the most part ages ago, when people just couldn't foresee all the potential issues that have been discovered over the years. And it is funny, to me, that over the past few years we have been using buzzwords like "web 2.0" not to refer to a set of new technologies that address all those issues but, instead... to refer to new ways of using the same old stuff (and perhaps not even "new".. think of  AJAX)  that have either introduced or highlighted more security issues than ever before.

Back to the CDNs...

SSL requires a certificate for each of the hostnames used to serve static content, or a "wildcard" certificate provided that all the hostnames involved are just sub domains of the same domain name (for example, static.domain.com, images.domain.com and www.domain.com would all be sub domains for domain.com); if hostnames for the static content to be served by a CDN are configured as CNAME records that point directly to the CDN's server, requests for that static content will obviously go straight to the CDN servers rather than to the website's servers. Therefore, although the required SSL certificates would already be available on the website's servers, those certificates must also be installed on the CDN servers for the CDN to serve the static content under those hostnames and with SSL encryption; so in theory it is necessary for the website's owner to simply provide the CDN company with the required certificates; the CDN provider then has to install those certificates on their servers. In reality, the SSL support provided by some CDN providers can be seriously expensive since it requires additional setup and larger infrastructure because of the aforementioned overhead; plus, most CDN providers do not even offer this possibility since traditionally they have been optimised for unencrypted HTTP traffic, at least so far.

As you can easily guess, the static content/CDN issues alone are already something that could make switching a site like Facebook to using SSL all the time, more challenging than expected.

"Secure-only" cookies

After all I've already said about cookies, you may think that as long as the website uses SSL by default, all should be fine. Well.. not exactly. If the website uses by default SSL but still allows requests to a page with unencrypted HTTP, it would still be possible to steal cookies containing authentication tokens / session ids by issuing an unencrypted request (http:// without the s) towards the target website.

This will allow once again the cookies to travel unencrypted, and therefore they could still be used by an attacked to replay a victim user's session and impersonate them in the context of the web application.

There are two ways to avoid this. The first is to flag the cookies as secure, which means the cookies can only be downloaded with https://, therefore they will be encrypted and the problem disappears. The second is to make sure the web server hosting the web application enforces SSL by rewriting http:// requests to https://. Both methods have basically the same effect with regards to the cookies, however I prefer the second one since it also helps prevent the mixed encrypted/unencrypted content issues we've seen above and the related browser warnings.

Websites that use SSL but only for the "submit" action of an authentication form

I have seen SSL used in various wrong ways, but this is my favourite one. I've mentioned how Firesheep has highlighted that most websites only use SSL for the login page, and why this is a weak way to protect the user's credentials. Unfortunately, there are also websites that only use SSL not for the login page itself, which simply contains the authentication form, but for the page that form will submit the user's credentials to.

I've found an example earlier of a website that once clicked on the "Login" link, redirected me to the page at http://domain.com/login.php - so without SSL. But in the source code I could see that the form's action was instead set to the page https://domain.com/authenticate.php which was using SSL. This may sound kind of right, in that the user's credentials would be submitted to the server as encrypted with SSL. But there's a problem: since the login page itself is not encrypted, who can guarantee that this page will not be tampered with and perhaps submit the user's credentials to another page (a page the attacker has control over) rather than the authenticate.php page the website's owner meant?

See now why this is not a good idea?

Content hosted by third parties

CDN is only part of the story when it comes to static content. The other part of the story concerns content that may be included on a page but is served by third parties and you have no control on the content itself nor the way it is served. This has become an increasingly bigger problem nowadays with the rise of social networks, content aggregators, and services that add new functionalities to a website, very easily. Think of all the social sharing buttons that these days we see on almost every website; it's extremely easy for a website's owner to integrate these buttons in order to help increase traffic to the site: in most cases, all you have to do is add some JavaScript code to your pages and you're done.

But what happens if you turn SSL on for your page, which then includes this kind of external content? Many of these services already support the HTTPS protocol, but not all of them, for the reasons we've already seen regarding overhead and generally higher demands in terms of resources. Plus, for the ones that do support SSL/HTTPS, you as website owner would need to make sure you're using the right code snippet that automatically takes care of switching to either HTTP or HTTPS for the external content, depending on the protocol used by your own page. Otherwise, you may have to adapt your own pages so that this switching is done by your code, provided the external service supports SSL, at least.

As for those services that make it easy to add functionality to your website, I've already mentioned Disqus, for example, as my favourite service to "outsource" comments. There are other services that do the same (IntenseDebate being one of them), and there are a lot of other services that add other kinds of functionality such as content rating or even the possibility for the users of your website to login on that website with their Facebook, Google, etc. credentials.

All these possibilities make it easy nowadays to develop feature-rich websites in a much shorter time, and make it pretty easy to let applications interact with each other and exchange data. However, if you own a website and plan to switch SSL always on for your site, you need to make sure all of the external services the site uses already support SSL. Otherwise, those browser warnings we've seen will be back, together with some security concerns.

Issues with SSL certificates

There's a couple of other issues, perhaps less important, but still worth mentioning, concerning domain names and SSL certificates, regardless of whether a CDN is used or not. The first one is that, normally, it is possible to reach a website both with and without www. So for example both vitobotta.com and www.vitobotta.com lead to this site. At the moment, since readers do not need to login on this site (comments are outsourced to Disqus) there is no reason why I would want to switch this site to always use SSL, at this stage. But if I wanted to do so, I would have to take into account that both vitobotta.com and www.vitobotta.com lead to my homepage, when purchasing an SSL certificate. The reason is that not all SSL certificates secure both www and non-www domains;  even wildcard certificates often secure all sub domains (including www) but not the non-www domain; this means that if you buy the wrong certificate for a site you want to use with always-on SSL encryption, you may actually need to buy a separate certificate for the non-www domain. I was looking for an example earlier and I found one very quickly in the website of my favourite  VPS provider Linode. The website uses a wildcard certificate that secures all the *.linode.com subdomains, but not linode.com, so if you try to open https://linode.com in your browser you'll see a warning similar to this (in Firefox in the example):

Generally speaking, it is better to purchase a certificate that secures both www and non-www domains (and perhaps other subdomains depending on the case). In case you are interested, an example of cheap wildcard certificate that does this is the RapidSSL Wildcard certificate. An alternative could be a certificate with the subjectAltName field, which allows you to specify all the hostnames you want to secure with a single certificate (provided you know all of them in advance).

The other issue with certificates is that companies often reserve several versions of the same domain name differing just by extension, with the purpose of protecting the branding of a website. So, for example, a company may want to purchase the domains company.com, company.info, company.net, company.org, company.mobi and so on; otherwise, if they only purchased for example company.com, others would be able to purchase the other domains and use them to their own benefit, black hat  SEO techniques and more. Good SEO demands that a websites only uses a single, canonical domain, so it's best practice to redirect all requests to the alternate domain names to the "most important" one the company wants to use as the default one (for example company.com). But as for the SSL certificates, it just means that the company must spend more money when purchasing SSL certificates.

Caching

Caching is one of the techniques most commonly used by websites to reduce load on servers and improve the performance both on the server and on the client. The problem with caching, in the context of SSL encryption, is that browsers differ in the way they handle caching of SSL-encrypted content on the client. Some allow caching of this content, others do not or will only cache it temporarily in memory but not on disk, meaning that next time the user visits the same content, all of it must be downloaded (and decrypted) again even though it has not changed since last time, thus affecting the performance of the website.

And it's not just about the browsers: ISPs and companies often use  proxies to cache content with the purpose of making web surfing faster. The funny thing is that many caching proxies, by default, do not cache SSL-encrypted content...

So... is an SSL-only web possible or not?

It's nice to see that Facebook now gives the options to turn SSL on. However, it is a) disappointing, because it's just an option, not the default, and most people do not even know what SSL is; b) surprising, that this change came not following the hype for Firesheep months ago, despite Facebook being one of the higher profile websites Firesheep had targeted; the change, instead, came after somebody hacked into Mark Zuckemberg's own Facebook profile.... Perhaps the privacy of Facebook's CEO is more important than that of the other users?

As for the other several sites targeted by Firesheep, I haven't yet read of others that have already switched to using SSL all the time by default.

So it's a slow process.... but I definitely think it is possible to think of an SSL-only web in the near future. Despite switching a website to using SSL all the time can be technically more challenging than one would otherwise expect, the truth is that all the technical issues listed above can be overcome in a way or another. I've mentioned how Google has pretty easily adapted some of their services to use SSL by default already, thanks to research and the optimisation of the technologies they were using for those services.  So what Google shows us is that other companies really have no excuses not to use SSL for all their services, all the time, since by doing so they could dramatically improve the security of their services (and, most importantly, their users' privacy), if only they cared a bit more about the aforementioned issues.

The only problem that may be a little more difficult to overcome depending on the web application and on the available budget, is of economical nature rather than technical. It is true that SSL encrypted traffic still costs more money than unencrypted traffic, but that's it. In particular, I mean the cost of the required changes to a site's infrastructure and the overhead in management, rather than the cost of the SSL certificates, which may not be a problem even for smaller companies, these days.

It is unlikely that we'll see completely new and more secure technologies replacing the web as we know it today, any time soon; but it is likely that with hardware and network connections becoming faster all the time, the prices of SSL certificates also going down, and further improvements to the current technologies, HTTPS will replace the standard HTTP as the default protocol for the Internet - sooner or later.

In the meantime, as users, we can either wait for this to happen, thus exposing ourselves to the potential risks, or we can instead solve at least partially the problem on our end; in the next few posts we'll see the easiest and most effective ways of securing our Internet browsing on the most common operating systems, and also 

why I used the word "partially".

So, as usually, stay tuned!

MOUNTAIN VIEW, Calif. - With summer travel plans in full swing, GeoTrust SSL Certificates provide security for online vacation and transportation companies offering safe and encrypted online booking. Companies including Excellence Resorts, Context Travel and RentSomeWheels.com count on GeoTrust to secure customer transactions, ensuring that personal and financial information is encrypted and protected while in transit. According to the July Alexa Netcraft Index, GeoTrust remains the most widely used cheap SSL provider among the top one million most visited web domains globally.

Click to Tweet: More of the top one million most visited web domains use GeoTrust: http://bit.ly/rq1S5s #SSL

Customer Quotes

“We work with Excellence Resorts to present a luxury brand for both travel agents and end users, and in order to maintain this reputation, Excellence Resorts insists on trust and professionalism, especially in the online transaction process,” said Mirek Nisenbaum, Principal, Studio Mobile. “The company takes pride in knowing that its elite client base’s information is secure because the entire transaction process online is protected by GeoTrust. Customers can clearly see the Web address change to “https” the moment they begin booking their getaway and know their information is secure, and with the Netcraft Alexa index pointing to GeoTrust as a leader in the SSL space, we feel that Excellence Resorts offers the best.”

“When our customers travel abroad, many for the first time, questions about security arise,” said Paul Bennett, co-founder, Context Travel. “It is our policy at Context Travel to supply customers with valuable, interesting seminars with knowledgeable and trustworthy guides, and that trust needs to start at the beginning by presenting a secure, stable Web experience for our savvy prospective customers. Our years of experience have given us absolute confidence in GeoTrust’s ability to help us with this, and we know that by using GeoTrust SSL on our site, our customers’ information is secure. After years with a standard certificate, we upgraded to the EV certificate to provide added security, which also turns the address bar green and increases customers’ trust in our site.”

“We value a partnership that allows us to secure our online transactions in a cost-effective way,” John Lawson, CTO and co-founder, RentSomeWheels.com. “Our customers depend on RentSomeWheels.com as a source of reasonably-priced auto rentals online, and when we save money, we can pass that savings along to our customers. It goes without saying that cost savings cannot come at the cost of security, which is why it comes as no surprise that GeoTrust SSL is a leader in the market. By using GeoTrust SSL on our site, we can provide total encryption and security of personal and financial information affordably, which translates to less concern over security and cost and more focus on serving our customers.”

Cost-Effective Transactional Security

GeoTrust’s range of digital certificate and trust products enable organizations of all sizes to maximize the security of their digital transactions cost-effectively. The company’s world-class SSL certificates offer fast delivery at cost-effective prices, enable up to 256-bit SSL encryption, and include a range of GeoTrust® True Site seals based on the level of identity verification.

Compiled monthly by CatapultWorks, the Alexa-Netcraft SSL Index obtains an accurate picture of SSL certificate usage across the websites that matter most by cross-referencing the Netcraft SSL Survey with the Alexa Top Sites list. The Netcraft SSL survey tallies all public-facing SSL certificates on the Internet. The Alexa 1 Million is a well-known site traffic measurement service that ranks the 1 million most visited sites in order of popularity.

About GeoTrust

A wholly owned subsidiary of Symantec, Corp. (NASDAQ: SYMC), GeoTrust is the world’s largest low-cost digital certificate provider solely focused on security. More than 100,000 customers in over 150 countries trust GeoTrust to secure online transactions and conduct business over the internet. GeoTrust’s range of digital certificate and trust products enable organizations of all sizes to maximize the security of their digital transactions cost-effectively. For more information, visit www.geotrust.com.

About Symantec

Symantec is a global leader in providing security, storage and systems management solutions to help consumers and organizations secure and manage their information-driven world. Our software and services protect against more risks at more points, more completely and efficiently, enabling confidence wherever information is used or stored. More information is available at www.symantec.com.

Note to Editors: If you would like additional information on Symantec Corporation and its products, please visit the Symantec News Room at http://www.symantec.com/news. All prices noted are in U.S. dollars and are valid only in the United States.

Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.

Source URL:

http://www.webwire.com/ViewPressRel.asp?aId=143806

Improper configuration is rendering SSL nearly useless as organizations are transmitting sensitive information online without any security.

Security researchers are buzzing about the flaws in the Secure Sockets Layer system and the fact that a significant portion of the Internet is vulnerable to attack. At the recent Black Hat security conference in Las Vegas, there were several reports and panels addressing various issues.

Based on the PKI (public key infrastructure), the cheap SSL protocol has grown "organically" to become nearly ubiquitous within the world's largest organizations to keep Internet communications secure, Jeff Hudson, CEO of Venafi, told eWEEK.

However, less than a fifth of Websites claiming to have SSL deployed correctly redirect traffic, according to a report released by Qualys at Black Hat. Of the nearly 250,000 sites with SSL turned on that were surveyed, only 51,000 were properly redirecting to SSL for authentication, according to the report from the Qualys community project, SSL Labs. The remaining 80 percent of the sites may or may not redirect to SSL, making them vulnerable to a man-in-the middle attack from Firesheep and other tools.

Overall, there has not been a lot of improvement worldwide in how SSL has been deployed over the past few years, Philippe Courtot, chairman and CEO of Qualys, told eWEEK. Organizations are just rolling out SSL servers and not taking the time to ensure the servers are properly configured, the report found.

Courtot declined to specify any of the offenders, noting that the problem was widespread.

There were a number of configuration flaws, including the use of insecure cookies and mixing unsecure traffic with secured traffic on the same page. Websites using SSL have to redirect to SSL immediately, instead of encrypting only a portion of the page, as that opens the user to session hijacking attacks, Courtot said.

When users see a padlock on the Web browser or some other form of visual notification that the site has SSL deployed, they expect their log-in credentials are protected, Courtot said. However, it turns out many organizations made a conscious choice not to use SSL in authentication despite rolling out the security protocol, researchers found. Nearly 70 percent of the surveyed servers handled the log-in process in plain text, and a little over half the servers were transmitting passwords as plain text, making it easy for a malicious attacker to intercept the sensitive information, according to the report.

This is actually a significant problem in the mobile space, according to Julien Sobrier, a senior security researcher at Zscaler. There is no "UI element equivalent to the lock" on mobile browsers and no visibility into the URLs to tell if the traffic is going over HTTP and HTTPS, Sobrier wrote Aug. 11 on the Zscaler Research Labs blog.

Citigroup learned the hard way that just having SSL on a Website doesn't keep data secure, as attackers exploited a weakness in the SSL connection on the financial giant's credit card Website and the Web browser to intercept sensitive information, Rainer Enders, CTO of NCP Engineering, told eWEEK.

While some companies, such as Google and Twitter, have taken steps to protect users by implementing HTTPS, all Websites where users log in should be encrypting traffic, as well as requiring HTTPS for all requests sent with a cookie, Sobrier said.

Qualys looked at how sites secured cookies and found that only six percent had properly configured session cookies, the report found. Even if the Websites are 100 percent encrypted, if the developer doesn't set a secure flag on the session cookies from within the application, a malicious third-party can sniff the contents of that cookie. This technique is very commonly used to force the browser to display session values stored on the insecure cookie.

Authenticity is important in the SSL system because it ensures that users are talking to the entity they intended to and that no one is listening, Chester Wisniewski, senior security advisor at Sophos, wrote on the Naked Security blog. The way the current system is set up, every major government in the world and many minor ones have the ability to sign any certificate they wish, Wisniewski said, speculating that the Department of Homeland Security could probably get a certificate claiming to be Google.

Security researcher Moxie Marlinspike presented an alternative system that bypasses certificate authorities and relies on a series of trusted notaries selected by the user, as opposed to relying on the 600 or so certificate authorities accepted by major Web browsers.

"CAs can be compromised and that major damage can result from related man-in-the-middle attacks," Hudson said, adding that Marlinspike's presentation should be a "wake-up call for better security and management of PKI and SSL."

NCP Engineering also released a white paper at Black Hat discussing "endemic vulnerabilities" in SSL, and by extension, SSL VPNs, which organizations often use to secure remote connections to the corporate severs. Enders said organizations should not just rely on SSL alone, but should layer it with IPSec to cover security weaknesses present in both technologies.

Qualys researchers also looked at how many sites were using HTTP Strict Transport Security, which defends against cookie-forcing attacks and Extended Validation SSL certificates in conjunction with standard SSL. The numbers were disheartening, as only 80 sites used HSTS and nine used EV SSL, Courtot said.

Source URL:

http://www.eweek.com/c/a/Security/Improper-SSL-Implementations-Leave-Web-Sites-Wide-Open-to-Attack-679456/

 

Is SSL a security must-have, or mere smoke and mirrors? Symantec is readying a public beta of a certificate management program this fall.

Is it a security must-have or simply a good branding tactic?

Secure socket layer (SSL) encryption has been called by some tech experts as a Web site must-have for businesses of any size, while other quarters contend it's a nice-to-have that in some instances might even be harmful to your site's health.

A recent announcement by security software firm Symantec Corp., of a new SSL certificate management offering for users and channel partners turns the spotlight on this security question once more. SSL pertains to cryptographic protocols that provide communication security over the Internet by encrypting segments of network communications. With technology gained from SSL company VeriSign Inc., which it acquired last year, Symantec will release for public beta in September, products aimed at helping IT administrators, Web hosting firms and tech service providers monitor and maintain SSL certificates.

The release will include  free downloadable SSL certificates for users and an onsite appliance which IT administrators can use to maintain and manage cheap SSL certificates used by their companies, said Fran Rosch, vice president of trust services for the enterprise security group of Symantec.

How SSL works

Because a lot of today's communications and transactions occurred on the Web, there is a need to make sure that information being transmitted between Web sites and customers are safe from interception or from being read by unauthorized people.

For users, it is also important to know that the Web site they are transacting with is the authentic site and not a spoofed site. “People's personal information, banking and financial information are being transmitted over the Internet. Consumers want to make sure they are dealing with the right people and not cybercriminals,” said Michael Murphy, vice president and general manager of Symantec Canada.

Secure Socket Layer works through a combination of encryption and decryption routines existing between the hosting computer and browser such as Internet Explorer, Chrome, Firefox or Safari to secure communications. It is akin to HTTPS (hypertext transfer protocol secure) and what is called "social authentication”, which was recently deployed by Facebook.

Source URL:

http://www.itbusiness.ca/it/client/en/home/News.asp?id=63593&PageMem=1

Regular SSL certificates are only allowed for a single domain or subdomain. This means that buying an SSL certificate for example dot com will not give you SSL security for www.example dot com or secure.example dot com. 

Most people can get away with only one SSL certificate, but what if you have a really big website that uses lots of subdomains? One SSL certificate will not work if you own a big website offering several services, like shop.buyshop dot com, mail.buyshop dot com, secure.buyshop dot com etc.You can say, "I can just get more SSL certificates, right?" but costs will become unbearably high not to mention the nightmare of having to manage several SSL certificates. Fortunately, you have the option to go for wildcard certificates that allow you to use one cheap SSL certificate on an unlimited number of subdomains.Wildcard? What's that? Before talking about the wildcard certificate, we should first talk about wildcards. In computer terminology, a wildcard is basically a sybol, usually an asterisk (*), what stands to be replaced by another character or string. Basically, an asterisk symbolstands for any word.

For example, *.example dot com refers to all subdomains of example dot com like mail.example dot com, secure.example dot com, news.example dot com, etc.If you look at an SSL certificate, you'll notice the "Common Name" field. It's the part that indicates the domain that will use the certificate. If you think that wildcard certificates use wildcards in the "Common Name" field, you're right. You might find Common Names like *.example dot com. If, in the future, you choose to get a wildcard certificate, you will be asked to supply the Common Name. Wildcard Certificates: Laying Down the BenefitsIf you want to save money on several subdomains, wildcard certificates are for you. At $150 each, a typical SSL certificate should be fine for those who only need it for a few subdomains, but costs will bloat to $750 in the event that you need SSL for five subdomains. On the other hand, $600 is the average prive for wildcard certificates. You can just imagine how much you're saving if you use more than five subdomains with SSL.

The websites of big companies will sometimes need SSL on over 30 subdomains.Wildcard certificates are popular for another reason - manageability. It's a daunting task to purchase, set up, and annually renew a dozen or so SSL certificates. Errors can easily happen when one person manages several SSL certificates all at once. It's a very difficult task. You lose a lot of time and money while putting effort into fixing SSL certificate errors. Just think about how that compares to worrying about just a single wildcard certificate. It's a simpler task to manage just a single certificate. It also reduces the chances of errors.The Bad Things about Wildcard CertificatesUsing wildcard certificates does have some drawbacks. The first thing that experts will point out is problems with security. Big websites are usually run by multiple servers, and by sharing one wildcard certificate, they share a single private decryption key. If a hacker manages to get access to the decrypiton key, the hacker also gets the ability to crack all encryptions made by each other serverIf, for some reason, your wildcard certificate is revoked, all subdomains will not work. Until you fix the wildcard certificate or get individual SSL certificates for each subdomain, you may have to put your website on down time.Finally, you should know that you cannot get wildcard certificates with Extended Verification (EV).

EV was basically invented to increase public confidence in SSL by enforcing more stringent guidelines to approving SSL applications. Wildcards in the Common Name are not allowed by EV guidelines. The green address bar feature only works in EV certificates, so you don't get that feature with wildcard certificates.

Source URL:

http://www.world-class-articles.com/Art/45701/147/Know-What-Wildcard-Certificates-Can-Do-for-You.html

The SSL system helps to protect secure communications across the Internet. It's also a technology that relies on trust; specifically, the trust of the SSL Certificate Authority (CA), which may not always be trustworthy, according to security researcher Moxie Marlinspike.

Speaking at the Black Hat security conference, Marlinspike detailed issues with the current CA system and proposed a new system to replace it.

The need to replace the CA system according to Marlinspike was highlighted by the recent attack on CA provider Comodo in March. Marlinspike noted that Comodo is the second largest CA in the world and the attack was able to do a lot of damage. Comodo officially blamed Iran for the attack.

Marlinspike has a publicly available tool called SSLsniff that enables security researcher to sniff SSL traffic to see if it is secure. Comodo published the IP address of their attacker and Marlinspike was able to identify from his weblogs that someone from the same IP address had downloaded SSLsniff from his website. The logs shows that the attacker was using Windows and had followed a YouTube tutorial one how to intercept SSL.

Marlinspike argued that Comodo is likely not as trustworthy as they should be. He also noted that as a result of the Comodo hack, nothing punitive happened to Comodo and they didn't get sued.

Marlinspike explained that for SSL to work, security, integrity and authenticity are needed. In his view, authenticity is the weak link today. Authenticity helps to prevent man in the middle attacks and it's the role of the CA's to ensure that sites are authentic.

"The real story with the Comodo attack is that it's not unique," Marlinspike said. "It's happening every day."

Marlinspike said that with the current CA model, if a user doesn't trust Comodo there is little they can do.

"If you remove them from the list of trust authorities the problem is that a quarter of the Internet will disappear," Marlinspike said. "It's same problem for a browser vendor they can't remove Comodo either."

The essence of the problem is that the current CA system doesn't provide for trust agility.

"Trust agility means that a trust decision can be revised at any time," Marlinspike said.

The other issue for Marlinspike is about giving users the choice of where they want to anchor their trust. He explained that in the current SSL CA model the user connects to a site which then connects to the CA authority, which then in turn authenticates the SSL certificate. Marlinspike wants to invert the relationship and have the user interact with the authority system directly as a way to provide trust agility.

To that end, Marlinspike introduced a replacement for the CA system, called Convergence. Marlinspike explained that instead of a CA there is a notary server that allows for trust agility. Privacy is achieved via local caching on the browser side, so the second time the users talks to an SSL site, if the Cheap SSL certificate is the same, there will be no need to check with a notary. On the first attempt the user side will check with the notary to ensure SSL authenticity.

Convergence is available as of today as a Firefox add-on at Marlinspike's site, convergence.io. He said that the system does not require any changes for websites.

"I want to leave you with this," Marlinspike concluded. "If anyone is trying to convince you to use a trust system, you have to ask , who do I have to trust and for how long?"

Source URL:
http://www.esecurityplanet.com/news/article.php/3938211/Who-Do-You-Trust-with-SSL.htm

 

     

The iOS vulnerability for which Apple (Nasdaq: AAPL) issued a security patch on July 25 is very severe, according to security experts who are warning iOS device users to apply that patch as soon as possible.

The vulnerability lies in a failure to validate SSL certificates correctly. That lets hackers use a tool called "sslsniff" to take over victims' iOS devices by using fake certificates.

Apple's patch is for iOS 3.0 through 4.3.4 for the iPhone 3GS and iPhone 4 GSM -- meaning the AT&T (NYSE: T) iPhone, iOS 3.1 through 4.3.4 for the third-generation iPod touch and later, and iOS 3.2 through 4.3.4 for the iPad.

Apple's notification stated that a certificate chain validation issue exists in the handling of X.509 certificates, and an attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS encryption.

In plain English, this means the vulnerability allows hackers to compromise users' cheap SSL certificates, then steal or modify data protected by SSL encryption.

SSL, the Secure Socket Layer protocol, is used for security on the Web.

"Everything's moving to the cloud, so SSL capabilities will become even more important as iOS offers cloud services," Michael Morgan, a senior analyst at ABI Research, told MacNewsWorld.

Apple revealed its iCloud service in June. Once up and running, the service will store new iDevice content in that cloud.

"I think Apple should take the time to tell people the patch is critical, because some people won't update their systems otherwise," Morgan added.

Apple did not immediately respond to a request for comment.

About the iOS Vulnerability

Like other operating systems, iOS validates all the signatures in a certificate chain. Its vulnerability lies in its failing to check whether intermediate certificates have valid signatures, as required by the x509 standard.

This means hackers can take an old certificate signed by a certificate authority, such as VeriSign (Nasdaq: VRSN) or Symantec (Nasdaq: SYMC), and use that to create valid signatures for other certificates and to intercept SSL traffic.

In order to check whether a certificate is valid, the OS must check the Basic Constraints extension in the certificate. This is a multi-valued extension which indicates whether a certificate was issued by a certificate authority (CA).

A genuine CA certificate must include the Basic Constraints value with the CA field set to "true," and that field is followed by a "pathlen" parameter that indicates the maximum number of CA certificates that can be included with the master certificate in a chain.

If the pathlen parameter is set to 1, for example, then there can only be two genuine CA certificates \-- the master and another one -- in the chain.

The vulnerability was first discovered in Internet Explorer by Moxie Marlinspike, who publicized it back in 2002.

Marlinspike developed the "sslsniff" tool as a proof of concept exploit for this vulnerability.

Everything Old Is New Again

"This is an old attack," pointed out Chet Wisniewski, a senior security adviser at Sophos.

"It was also in Webkit, which is in Safari, and that means Apple fixed it in their browser in 2002," Wisniewski told MacNewsWorld.

"Somehow they may have recreated the flaw when they created iOS. It is a bit strange."

 

Vulnerability Is for Victims

Apple's low-key approach to the security patch is in keeping with its past behavior. The company's general practice is to say nothing about vulnerabilities for a while and then suddenly release a slew of patches.

"Apple have been able to say they're more secure than some other operating systems for some time, but that's a bit of a fallacy because, in the past, they haven't been as much of a target," Richard Shim, a senior analyst at Display Search, told MacNewsWorld.

"Now, they're a big target because they're so well established," Shim stated.

The skyrocketing popularity of first the iPhone and now the iPad has changed the situation.

"In the past, people weren't trying to hack Apple so much, so Apple could back off a bit on security and focus on products," ABI Research's Morgan said.

"Now, they're big enough and important enough and, because they haven't spent as much time hardening their system as Microsoft (Nasdaq: MSFT) had to, they're becoming more of a target and may have to shift gears on security," Morgan remarked.

Apple should perhaps have been more forthcoming about the dangers of the Basic Constraints vulnerability so that users would understand they need to apply its patches as soon as possible.

On the other hand, Apple seems to be moving in the right direction with regard to security, Sophos' Wisniewski said.

"I've heard that iOS 5 may include over-the-air updates and that will be a big help," Wisniewski stated. "It's not that people don't want to update their iOS devices, it's just that it's so inconvenient because you have to plug your device into your computer first."

Source URL:

http://www.macnewsworld.com/story/Security-Wonks-Urge-iPhoners-to-Patch-Em-Up-72970.html