What to do if the HTTPS certificate is forged?

The security of the HTTPS protocol relies on its certificate mechanism. If an attacker applies for a certificate that is exactly the same as your website, the security mechanism of your website will no longer exist. This article will talk about how to prevent HTTPS certificate forgery.

Certificate hijacking

If you want to deploy an HTTPS website, you must first apply for a certificate from a CA. After verifying the identity of the applicant, the CA will issue a certificate that contains the host name and public key of the applicant's website. The CA will also sign the entire certificate with its own private key, add the signature to the certificate file, and then send it to the applicant. Certificates are a critical part of the TLS protocol, and their main functions are:

• Confirm the true identity of the server to the website visitor, ensure that the client (browser) is communicating with the real website provider, avoid man-in-the-middle attacks, and implement the identity authentication feature in cryptography.
• The client and server use the public key in the certificate (depending on different password negotiation algorithms, the functions are different) to negotiate the master key (Master Secret). With the master key, the client and server can ensure that the communication data is encrypted and has not been tampered with.

The biggest problem with HTTPS certificates is the existence of forged certificates. Once a forged certificate appears, the security system will be very vulnerable. The reasons for forged certificates are as follows:

• CA organizations may intentionally or unintentionally issue some wrong certificates, for example, the CA organization fails to correctly verify the identity of the applicant.
• CA is a profit-seeking organization. Driven by profit, it may issue certificates without restraint. If a malicious secondary CA certificate is issued, the harm caused will be even greater.
• Attackers will use various technical attack methods to impersonate or forge the owner of a domain name, thereby successfully applying for a certificate, and then use the certificate to perform harmful operations.

At this time, the certificate user may have the following confusion:

• The domain name owner has no way of knowing which CA organizations have issued the certificate to him, nor does he know whether someone has impersonated him to apply for a certificate and provide services.
• The CA organization does not know how many certificates it has issued, nor is it sure whether it has issued forged certificates. The secondary CA issuance mechanism is uncontrollable.
• There is no technical means for the browser to verify whether the certificate is legitimate.

Certificate Transparency

In order to solve the potential problems of certificates, Google proposed a solution, which is Certificate Transparency (CT). CT is a set of technical solutions that can audit and monitor the issuance and use of certificates to make them more transparent. It is not a substitute solution for certificates, but an effective supplement to certificates. Through CT, the following goals can be achieved:

• CAs can know which certificates they have issued and quickly detect whether malicious certificates have been issued.
• Website owners can know the entire process of issuing certificates corresponding to domain names. Once they find that an attacker has forged a certificate corresponding to a domain name, they can quickly contact the CA organization to revoke the certificate.
• Browser manufacturers can audit the use of certificates. If a malicious certificate is found, the HTTPS connection can be quickly closed to ensure user security.

The technology used by the CT log service is very similar to blockchain technology. Cryptography (Merkle hash tree) ensures that data can only grow, but modifications, insertions, and deletions will be discovered. Since the cost of auditing a single piece of data is not high, the auditor can be a separate service, a function of the observer, or even part of the client.

Expect-CT

To ensure that browsers can take action when accessing certificates that lack CT supervision (such as certificates accidentally issued by CAs), Google proposed adding a new Expect-CT HTTP Header, which is used to tell the browser to expect the use of certificate transparency services. The Expect-CT CT header allows sites to choose to report or enforce certificate transparency requirements, which can prevent site certificate errors from being ignored. When a site enables the Expect-CT CT Header, the browser will check whether the certificate used by the site appears in the public CT log, which can effectively avoid HTTPS threats such as man-in-the-middle attacks and make the site more secure.

 Expect-CT: report-uri = "<uri>" , enforce, max-age = < age >  

There are two strategies to choose from when deploying, one is report-only and the other is enforcement. In the report-only strategy, the browser will send a report to the address set by report-uri if it does not receive valid CT information. For this strategy, you can set it as follows:

 Expect-CT: max-age = 0 , report-uri = "https://{$subdomain}.report-uri.com/r/d/ct/reportOnly"  

Under this policy, if the browser does not receive valid CT information, it will not terminate the connection, but will only send a report to the URI you specified. The second policy can be set as follows:

 Expect-CT: enforce, max-age = 30 , report-uri = "https://{$subdomain}.report-uri.com/r/d/ct/enforce"  

This tells the browser to enforce the CT policy and cache the state for 30 seconds. If the browser does not receive valid CT information, it will terminate the connection and send a report. After configuring the CT information correctly, you can set this time longer.