This is a detailed technical discussion but it is important to explain how HTTPS, combined with an end user digital certificate, effectively neuters Phishing and makes it ineffective.
We all know what Phishing is: you get an email with a link to a well known site and you are prompted to logon. The site you are brought to is actually a hoax, impersonating the true website. After sharing your ID & password, the hackers that put up the hoax site can now impersonate you to the real site. (For more information on Phishing, please visit the Anti Phishing Working Group.)
This is effective because Id's and passwords are easily shared and can be replayed from any device. To combat the risk of stolen Id's and passwords, many companies now text you an additional code to logon. There are many other approaches to enhancing Id's and passwords. However, many solutions to Phishing are not all that effective. We can say this because Phishing has been around for 20 years and its only gotten worse. Phishing has become so effective it has matured from a consumer issue to a business issue (called Business Email Compromise), and is a multi billion dollar fraud.
The root cause for all this fraud is the insecurity of Id's and passwords and the ability to replay a password over and over again.
HTTPS & Digital Certificates as a Solution
One goal of Phishing is to steal an end user's Id and password. That Id and password can then be used to impersonate the true end user and takeover their account or perform other malicious activities. The root cause of all this is that once a password is stolen, it can be replayed. That is the fundamental issue: passwords do not change after they are used. A password can be used over and over again - replayed - from anywhere by anyone.
HTTPS combined with an end user digital certificate, solves this problem. There are detailed technical explanations available (see below), but fundamentally, when accessing a website, the HTTPS protocol combined with an end user's digital certificate creates a cryptographically strong one time passcode specifically for that website. That 1 time passcode is only valid at the destination website. If an end user accesses a rogue website, their 1 time code is not valid at any other website. The rogue website can attempt to replay the 1 time code to another website, but that website can detect the attack and deny access.
In our view, this addresses the risk of Phishing: Phishing has been around for over 20 years and it is not going away anytime soon. Instead of trying to stop Phishing with email filters or a 2nd factor to a password, we propose replacing passwords with HTTPS and digital certificates. Because HTTPS with digital certificates creates a 1 time logon that cannot be replayed, even if you do get Phished and access a rogue website, the logon is only meant for that site. If it is replayed, the other site can detect the replay and deny access. Because HTTPS and digital certificates address the problem of replay, the technology neuters Phishing and makes it an ineffective, useless exercise. This is a much more sound, secure approach to address Phishing than sending a code to a phone to complement a password.
An academic white paper reviewed the technical details of HTTPS with end user digital certificates and how the combination defends against Phishing:
- Practical Issues with TLS Client Certificate Authentication
- Arnis Parsovs, Software Technology and Applications Competence Center, Estonia.
- The most widely used secure Internet communication standard TLS (Transport Layer Security) has an optional client certificate authentication feature that in theory has significant security advantages over HTML form-based password authentication.
- Active security research is being conducted to improve password security, educate users on how to resist phishing attacks, and to fix CA trust issues , . However, the attacks mentioned above can be prevented or their impact can be greatly reduced by using TLS client certificate authentication (CCA), since the TLS CCA on the TLS protocol level protects the client's account on a legitimate server from a MITM attacker even in the case of a very powerful attacker who has obtained a valid certificate signed by a trusted CA and who thus is able to impersonate the legitimate server. We believe that TLS CCA has great potential for improving Internet security, and therefore in this paper we discuss current issues with TLS CCA and provide solutions that will improve the security of TLS CCA and enable its usage on a larger scale.
- The proof that the client has access to the private key that corresponds to the public key in the client's certificate is given by calculating the hash of all the previous handshake messages exchanged between the client and the server so far and signing it with the client's private key. This signature is sent in the client's CertificateVerify message.
- As can be seen, the signature given using the client's private key is bound to the client's and the server's randomness, the server's certificate and the encrypted pre-master secret sent by the client. This means that even an attacker that has obtained the signature in a MITM attack, cannot reuse the signature in any other TLS handshake either with the legitimate server or any other server. As a result, in cases where TLS CCA is used, the attacker cannot impersonate the victim to the legitimate server even if the attacker is able to impersonate the legitimate server.