Is eCommerce Really Secure?

I have pondered quite a bit here lately on the impact of SSL or Secure Sockets Layer on our culture.   It is used for nearly every eCommerce site including huge players like Amazon, eBay, Paypal, and Bank of America.  There are no realistic alternatives for SSL and HTTPS for securing web nformation in transit.  The beauty of SSL is the fact that it allows a web user to verify or authenticate that they are actually connecting to the web site that they think they are.  It does this by using a list of trusted digital certificates that contain public keys that sign certificates that are presented by the web server. 

 

This process is a complex series of hashes, digests, encryption and decryption.    The goal is to verify the validity of a site prior to building an encrypted channel and passing user credentials from the client to the server.  Have you ever wondered what would happen to eCommerce if SSL was exploited tomorrow?  What if it is being exploited today?  Is there an alternative that can be deployed quickly?

If SSL were to be widely exploited, there is the obvious issue of financial loss.  The loss would likely be incurred by the users of these services.  One exception that I can think of would be a case when a consumer could demonstrate that the entity that they were executing a transaction with was actually negligent in the handling of the private key that resides on their web server or load balancing device.  Beyond that, it is our jobs as consumers to authenticate the site that we are connecting to.

It is their jobs as a provider of these services to ensure that the requisite credentials were passed to them and they can say with reasonable surety that we are the customer who we are claiming to be.  The issue in this scenario is that if we as customers do not take adequate precautions and validate the site we are connecting to, then we could possibly be passing this information to someone other than our provider.  Later when the thief uses this information, the bank may allow them access to your account or services.  At this point, there are many ways that your account can be drained.

If SSL were to become openly exploited, there would be huge ramifications for many markets.  Major players in online stores would quickly have their profits dip into the red due to the lack of consumer confidence and in some cases, financial loss.  Banks that have become targets could be dealing with customer relation issues as well as losses.  There would likely be a mad scramble by many organizations to develop what will later be determined to be flawed proprietary ways to augment the weaknesses in SSL or its implementation.  The simple truth is there is currently no realistic alternative for this protocol that could be rapidly deployed.  It is entirely possible that SSL is being exploited today.  There are many attack vectors that when combined can allow for the exploitation of SSL even if the protocol itself is completely impenetrable and irreversible.

So how could someone compromise SSL?  Personally, I think SSL is a well thought out process or algorithm.  However, I am a strong believer that the way it is implemented, it could fall prey to other attacks.  The first thing that I would call into question is the Trusted Root Certificates that is installed into the client operating system.  These include the likes of Thawte, Verisign, Entrust and other root CA or Certificate Authorities.  These are the “validation tokens” that allow the browser to verify that a web sites certificate was in fact signed by a trusted authority.  In other words, this is the third party validation.

So who determines the third parties that should be trusted and how are they inserted into the operating system?  If you are using a Microsoft operating system, this decision is made by Microsoft.  They have a “Root Certificate Program” that contains the criteria for inclusion.  With Windows Vista, these certificates are updated over the internet any time that a user accesses a secured web site, read an encrypted email, or access a signed ActiveX applet.  With Windows XP these are updated through the Windows Update process.  I’m not sure that I trust my bank account to a Microsoft developed process.  However, in reality, I along with millions of individuals do just that on a daily basis.

I believe this risk has increased tremendously as well as our dependence on the services that are supposedly protected by this authentication algorithm.  Recently there have been two major exploitation methods that could allow a man in the middle attack to be highly successful when combined with a compromised set of root CA certificates.  One of these attacks was outlined by a security researcher by the name of Dan Kaminsky at the Black Hat security conference.  This was a  dns attack method for getting bogus IP addresses associated with fully qualified domain names.

The other attack was announced at Defcon and involves the routing protocol BGP4 which maintains the tables of routes for the internet infrastructure.  It is easy to see that either of these two attacks can put an attacker in the middle of a conversation.  With the compromise of the root ca’s, the attacker can simply sign the public key on his server that is in the middle with the private key for the compromised root ca.  As the traffic is passed through, decrypted, manipulated and re-encrypted, the user will not see any clues to the fact that they have just been compromised.

Another vulnerability in SSL was also announced in many Debian based systems.  This was basically a not so random private key.  The problem was with a predictable key generation in the openssl suite.  To solve the problem, it is imperative that all organizations using key material that was generated with this version of openssl revoke their certificates, regenerate their keys and get new certificates from a root ca.   This buggy version of openssl was in Debian and its variants for a significant amount of time and subsequently there are many private keys that are very similar.  An attacker would always have access to the public key and could brute force the private key by throwing data through an encryption algorithm using the public key and decrypting the data with the private key.  When the pre-encrypted data matches the decrypted data, the private key has been determined.  Now this key could be used on a man in the middle device and any redirection or man in the middle attack would likely be successful.  So do you know if your bank regenerated their private key with real randomization?

Another question that may come up is, “What about organizations that are using additional methods for users to authenticate that they are connecting to the correct servers?”  One popular method is to require the username first, provide a picture that this user will recognize (a train, a teddy bear, etc).  If the user sees this, he or she supposedly knows that they are talking to the correct server.  However, in the man in the middle attack that I outlined, the user could still see the correct image.  Additionally, a security researcher at Defcon 15 had an excellent presentation entitled “Greater than One ” that outlined other vulnerabilities to this.  My position to entities that take this approach is that they are exposing themselves to even greater liability.  While this is not a real solution, they are telling their customers that they can trust the site if they see their image.  I think this is a mistake and will certainly have repercussion in the form of liability.

Will SSL vulnerabilities ever be widely exploited?  I certainly hope not.  It would change the direction of our industry and adversely hurt the world market.  The lack of confidence would cause the globalization of our economy would quickly dissolve.  Internet Banking and eCommerce would cease to exist until not one, but two things happened.  First a mutual authentication protocol would have to be developed that is completely aware of the fact that there is no other aspect of the internet that can be trusted.  This includes the user’s pc and the path the traffic goes from client to server and vice versa.  The second thing that would have to happen is that consumer confidence would have to return.  While the first obstacle is huge, rebuilding of the faith in these systems may take far longer.  As I previously said, I certainly hope attacks on this scale never happen.  However, we must remain realistic in how vulnerabilities work together to increase their potency.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Other. Bookmark the permalink.