By Garret Grajek, CISSP
COO, MultiFactor Corp.
In early July, Dan Kaminsky reported that a serious flaw exists in DNS software. Despite the bad news, Dan remained scrupulous and worked behind the scenes with Microsoft, Cisco, Sun, CERT and others before publicly disclosing the flaw on July 9th, details of which will be revealed in August. Patches have been made available by various vendors.
The question enterprises have to ask themselves is, are they comfortable with the public DNS system being their only line of defense in assuring that their END-USERS are actually connected to their site? (e.g. When the end-user clicks http://www.ubank.com/ is the end-user going to the site hosted by “Ubank,” or is the end-user being rerouted to a fictitious site)? (See Figure 1)
Figure 1 - The hacker utilizes a DNS attack as one of the methods to lure the Internet user to the attacker site.
The key to addressing this solution is to provide the end-user with a secondary mechanism that ensures he or she is at the correct site. As the Kaminsky report reveals, DNS alone is not 100% reliable, and it should not be the only mechanism utilized for resource-valued sites.
A mechanism that does ensure an end-user’s connection to the legitimate site is client-side SSL (C-SSL). C-SSL technology utilizes public/private key cryptography to conduct a bi-lateral authentication that affirms the proper identity of not only the client, but also the server.
Figure 2 - A deployment utilizing PKI can thwart this type of DNS attack by utilizing public/private key technology to verify the site’s address.
The issue has been implementing this technology on two sides:
- Client side
- Server side
Historically, PKI has been too difficult to implement on the client-side due to end-user education. Equally difficult, certain components have made implementation and maintenance too burdensome on the server-side. MultiFactor SecureAuth addresses both of these issues. (See Figure 3)
Figure 3 - SecureAuth addresses client-side and server-side complexities to allow bi-lateral, X.509 authentication. (Click to enlarge)
MultiFactor SecureAuth resolves PKI issues for the client
SecureAuth is 100% browser-based. It uses the browser to:
- Store the Private/Public Key Pair
- Retrieve the proper end-users’ key pair
- Validate the proper end-users’ key pair
The end-user requires no knowledge of storing, revocation, or porting of certificates. SecureAuth’s unique, click-through registration method handles all the complexities for end-users.
MultiFactor SecureAuth resolves PKI issues for the Server
SecureAuth handles the X.509v3 authentication and validation without C-SSL; this saves an enormous amount of complexity for end-users. SecureAuth’s uniqueness is a self-contained X.509 validation mechanism that enables the validation of end- users’ X.509 credentials by utilizing standard server-side certificates. (E.G. SecureAuth utilizes the certificate that enables SSL encryption for a site, such as https://www.company.com/).
Figure 4 - SecureAuth utilizes its own technology to validate the client-server authentication, thereby validating both parties. This greatly reduces overhead and deployment cost to the X.509 solution. (Click to enlarge.)
In summary, enterprises wishing to provide secure sites are concerned about authenticating servers and end-users accessing the targeted sites. MultiFactor SecureAuth is an excellent solution that securely validates both parties, in a deployable manner.
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others