Breaches Raise Questions about SSL Security

by VPNHaus | 09/01/2011 |Industry Commentary, Rethink Remote Access, SSL

Theubling SSL hacks. Earlier this year, Comodo alerted its customers to a serious SSL breach that impacted nine Web domains, including Google and Yahoo. Now with details emerging about the attack on DigiNotar’s SSL and EV-SSL CA system, we think it’s time to take a closer look at SSL security.

In fact, in July NCP engineering* released a whitepaper “Debunking the Myths of SSL VPN Security,” taking on this very topic. So using this whitepaper as a guide, VPN Haus is launching a multi-part series that the asks questions: why do so many high profile breaches occur using SSL VPN? Do users simply not implement the technology correctly? Or does SSL fall short of the marketing hype? We’ll dig for these answers by exploring the following SSL VPN myths:

Myth 1: Using trusted certificates from a certificate authority (CA) is airtight.

Myth 2:  One-way certificate authentication of a SOA web service is secure because it uses HTTPS.

Myth 3: Online banking via SSL session is secure.

Myth 4: Java Authentication and Authorization Services (JAAS) framework handles all protocols and mechanisms in a secure manner.

Myth 5: Two-way certificate exchange between a SOA web service and a client can always be trusted.

Myth 6:  RSA SecurID provides a secure connection.

Myth 7: Thick-client SSL VPNs are more secure than thin-client SSL VPNs.

Myth 8: Security is the responsibility of a specialist department.

Moreover, Myth 1 deals head-on with issue Comodo, and now DigiNortar, faced with its fraudulent certificates. More on that soon. But for now, we invite you to weigh in with your thoughts as we take a deep dive into the murky waters of SSL, in hopes of eliminating confusion, providing greater clarity, and ultimately, peace-of-mind on SSL and security.

*NCP engineering manages VPN Haus

This website uses cookies

We use cookies to personalize content and analyze access to our website. You can find further information in our data protection policy.