A few months ago, I wrote a blog regarding some of the vulnerabilities I see in SSL implementations. In that blog I spoke about SSLv2 and Weak Encryption settings. The blog primarily addressed how these vulnerabilities could be used to compromise the confidentiality SSL can provide. Other than confidentiality, SSL also can be used to provide authentication, non-repudiation, and integrity.
Many of the vulnerabilities I encounter undermine the authentication that SSL provides. Examples of these vulnerabilities include X.509 MD5 Signature Collisions, Self Signed Certificates, and Subject Common Name does not Match FQDN vulnerabilities. In this blog I want to address the significance of the authentication SSL provides. Many times we take for granted the authentication portion of SSL, but in reality we use on a regular basis the authentication that SSL provides.
When you connect to a site like https://www.PayPal.com, how do you know that you are not actually connecting to an evil hacker’s website which they also named https://www.PayPal.com? How can you be sure that an attacker has not poisoned the DNS server that you use to look up the IP address associated with PayPal’s website and you have actually been redirected to a hacker’s site that looks like PayPal? How can you be sure that when you enter your username and password into this site that an attacker is not capturing your credentials and is planning on using them to compromise your PayPal account? In order to help address these issues, an Internet-based public key infrastructure (PKI) has been developed. SSL uses this infrastructure in order to help provide you with a level of protection.
A PKI incorporates public key encryption (also named asymmetric encryption). In public key encryption a device uses two keys in order to provide encryption. The first key is called the private key. This key the device keeps secret and does not disclose to the public. The second key is called the public key, which the device sends to anyone who wishes to communicate with the device over an encrypted channel. Information encrypted with the device’s public key can be decrypted only with the private key, and information encrypted with the device’s private key can be decrypted only with the public key. When client side software such as a web browser attempts to connect to a device using public key encryption such as a secure web server, the public key is used by the client side software in order to establish a secure connection.
In order to tie the identity of an organization with its public key, a public key certificate is created. This association is performed through something called a digital signature. The public key certificate basically says that the website https://www.test.com is owned by Test Corp. and is associated with the public key of 12345. A public key certificate can be self signed or endorsed by a third party. Self signed certificates basically say “I am Test Corp., I own https://www.test.com, and the public key of this website is 12345, because I said so.” The second way the public key can be associated with its identity is through endorsements. This is when a third party validates that a particular public key is associated with an identity. This can be explained as follows. In order to provide authentication, a website can send its public key certificate to a trusted Certificate Authority (CA) such as VeriSign. The CA verifies that the organization is who they claim to be (VeriSign basically asks to see the organization’s driver’s license). Once the CA has verified that the organization is who they claim to be, and they do own the website they are asking the CA to validate, the CA will sign the public key certificate of the website.
The most common place to find SSL being implemented is on the World Wide Web. Today’s web browsers (Such as Internet Explorer and Firefox) are given a list of trusted CAs. When the web browser connects to a web server, the web server will present the browser its public key certificate. The browser will check the certificate to see who the CA was who signed it. The browser will look through its list of trusted CAs to see if it trusts the organization who signed the server’s public key certificate. If the website’s public key certificate was signed by a CA that the browser trusts, then the browser shows the user the website without complaining to the user. The web browser will in most cases provide a pretty little lock icon to the user in order to show that the site is secure (Isn’t this nice of the web browser?). If the CA is not trusted by the browser, the browser will start shouting that it does not trust the site (This is accomplished through warning messages the browser shows the user).
Let’s use a real world Example of how SSL is used. A site like https://www.PayPal.com wants to prove to everyone that they are really owned by PayPal. In order to provide this proof, PayPal will contact a trusted CA like VeriSign and ask them to tell everyone that they are really owned by PayPal (Because everyone trusts VeriSign). VeriSign will work with PayPal in order to verify their identity (Basically VeriSign asks PayPal for their Driver’s License). Once VeriSign has verified PayPal’s identity and that they own https://www.PayPal.com, they will “sign” the websites public key certificate. This signature shows that VeriSign has verified the website’s identity.
Along comes a user named Joe. Joe wants to use his web browser in order to connect to PayPal in order to purchase a new video game (Notice that Joe is cool, because he is not purchasing stuff like clothes). In order to prove to Joe that https://www.PayPal.com is really who they claim to be, PayPal shows the browser its public key certificate. The browser checks to see the CA who signed the public key certificate and sees that it was signed by VeriSign. The browser looks through its list of trusted CAs and sees that VeriSign is a trusted CA. The web browser shows Joe PayPal’s website without showing any warnings. The web browser also shows the proverbial lock on the web browser which makes everyone feel warm and fuzzy. Isn’t this story wonderful? It has the makings of a wonderful movie . . . suspense, trust, and victory . . . but I digress.
Now let’s see what happens if an attacker makes a fake website named https://PayPal.com. An evil hacker named Franz (I think Franz is a good name for a hacker) wants to capture Joe’s PayPal credentials. In order to do this, the evil hacker creates a site named https://www.PayPal.com. Franz cannot contact a trusted CA to have them verify his identity, because he does not own the domain for PayPal (He does not have PayPal’s driver’s license). Instead, the hacker signs his own public key certificate. Franz signs the public key certificate for https://www.PayPal.com and essentially says “I am PayPal, I own https://www.PayPal.com, and my public key is 12345, because I said so.” Franz now redirects Joe’s browser to his site which is named https://www.PayPal.com. Joe’s web browser checks to see who signed the certificate of the website. The browser does not see the signer of the public key certificate on its list of trusted CAs. The web browser tells Joe that something is wrong with the website’s certificate. If Joe is smart, he will be alarmed by these error messages and will drop his connection with the website.
Researchers at Carnegie Mellon University found that the majority of users will ignore these SSL warnings and continue to the website anyway. This paper can be found at the following link: http://www.usenix.org/event/sec09/tech/full_papers/sunshine.pdf.
So, in conclusion, before you go clicking through those SSL warnings, I encourage you to take a second and really consider the risk involved in these actions. If you do not wish to share the information you are sending with the entire world, I would suggest not sending your information to sites with these SSL warnings. It is important that you actually trust the site that you are connecting to before you give your credentials, SSN, Credit Card, etc.
-Gary McCully
Read more!
Wednesday, April 21, 2010
Monday, April 19, 2010
Brand Evolution
Evolution is key to survival in this business climate. That’s why SecureState has undergone a total rebranding effort and new website launch.
Overhauling your entire image is not necessary to rebrand. Simple tweaks to spruce up an image is often all that’s needed. And that’s what SecureState has done. There were already great ‘bones’ to the SecureState brand, so all we needed to do was freshen our image and allow our image to reflect the growth we’re experiencing. The changes have been integrated over a period of time and are now visible in every aspect of customer-facing material, from our Twitter page to client proposals and presentations to, of course, our brand new website, which has just been launched.
Speaking of our new website, be sure to check it out at www.securestate.com! A lot of hard work went in to ensure that our website is now in line with the image we wish to portray. Our website is also much more informative and user friendly, and showcases what’s best about our services and offerings.
One of the things you’ll probably immediately notice is that all of our rebranding has been incorporated throughout the website. We’ve also added a new Media Center–it’s a one-stop shop to find all of our new case studies, whitepapers, blog entries, events, social media outlets, and much more. Our homepage has been updated to allow easier access to our industry-specific service offerings and to highlight our client success stories, which scroll across the bottom.
The strength of our company is now better reflected in our brand. As SecureState continues to provide the best service possible, we’ll also continue to portray that in our identity.
Read more!
Overhauling your entire image is not necessary to rebrand. Simple tweaks to spruce up an image is often all that’s needed. And that’s what SecureState has done. There were already great ‘bones’ to the SecureState brand, so all we needed to do was freshen our image and allow our image to reflect the growth we’re experiencing. The changes have been integrated over a period of time and are now visible in every aspect of customer-facing material, from our Twitter page to client proposals and presentations to, of course, our brand new website, which has just been launched.
Speaking of our new website, be sure to check it out at www.securestate.com! A lot of hard work went in to ensure that our website is now in line with the image we wish to portray. Our website is also much more informative and user friendly, and showcases what’s best about our services and offerings.
One of the things you’ll probably immediately notice is that all of our rebranding has been incorporated throughout the website. We’ve also added a new Media Center–it’s a one-stop shop to find all of our new case studies, whitepapers, blog entries, events, social media outlets, and much more. Our homepage has been updated to allow easier access to our industry-specific service offerings and to highlight our client success stories, which scroll across the bottom.
The strength of our company is now better reflected in our brand. As SecureState continues to provide the best service possible, we’ll also continue to portray that in our identity.
Read more!
Subscribe to:
Posts (Atom)
Posts
