Monthly Archives: August 2010

TLS client/server authentication does not prevent phishing on the Web

Think about the following scenario:

Alice needs to upload a document with sensitive information to The Web server servicing this URL is run by Bob and uses TLS server and client authentication to ensure that Alice’s browser and Bob’s server can authenticate each other. Of course, both parties (client and server) need to have a certificate installed. In todays prevalent CA-based PKI, these certificates must be issued by CA’s that both entities trust. Bob’s server uses Alice’s client certificate for automatic login on Alice’s account.

Another server, run by Eve, is servicing and has been deliberately crafted to mimic the service at in order to fool people into uploading documents at the wrong service.

Eve’s server also has a certificate issued by a mutually trusted CA, and will similarly use Alice’s client certificate to do a login on a (perhaps dynamically created) account. So if Alice by mistake connects to Eve’s server instead of Bob’s server, it is likely that she will not notice her mistake.

Why doesn’t TLS in todays browsers prevent this scenario? Because

  1. todays web browsers by default accepts any server certificate issued by one of the root CA’s that they have been configured to trust. Todays browsers fully rely on CA’s to not issue certificates to servers that have been set up for phishing purposes. I doubt that todays CA’s live up to this responsibility.
  2. client certificates can in some cases actually assist Eve’s server in creating a login experience that makes Eve’s services more closely resemble those of Bob.

In other words, the problem is not in the TLS protocol or the implementation of it. Rather, the problem is in the PKI that underlies the integration of TLS in todays browsers.