HTTPS deployment Overview

Many Web developers know SSL, but it is common that SSL is not fully deployed or is not deployed where it should be deployed. This brief guide on when and how to deploy SSL will help you avoid most common errors.

Key Points

If you have any confidential information, or you want to log on to a user, even if you only want the Administrator to log on, you should deploy HTTPS. Risks do not exist only in theory. Never deploy HTTPS in part: use it for all content. Otherwise, you will face many risks. For example, the session ID is intercepted, which is no less harmful than the password being intercepted. If you have deployed HTTPS, redirect any common HTTP requests to the https url to force all requests to be processed through HTTPS. Enable HTTP strict Transmission Security Protocol (HSTS) to further reduce the possibility of attacks. Set security tags on your cookies, such as session cookies, to ensure that they are not exposed through normal HTTP requests. What is HTTPS?

HTTPS places HTTP over SSL/TLS. The effect is to Encrypt HTTP traffic (traffic), including the requested URL, result page, cookies, media resources, and other content transmitted over HTTP. The person attempting to interfere with the HTTPS connection cannot listen for traffic or change its content. In addition to encryption, the identity of the remote server also needs to be verified: after all, if you do not know who the other end is, encrypted connections are useless. These measures will make it extremely difficult to intercept traffic. Although the attacker may still know which website the user is accessing, all he knows is limited to this.

When and why to deploy HTTPS

If your website has any non-public information, you should deploy HTTPS, including those websites that need to be logged in. After all, if the information is public, you do not need to log in. Websites that can only be accessed by administrators, such as typical Wordpress sites, also require HTTPS.

It is necessary to deploy HTTPS, because without it, even if someone is passively listening, that is, listening does not control network traffic, he can also read confidential information such as passwords or authentication tokens along the HTTP transmission.

This attack does not only exist in theory. I have done this myself (with my license) several times-it's too easy to do on public hotspots. Public hotspots usually do not use any WiFi encryption, so listening to all traffic is just a piece of cake. This situation is common in bars, hotels, trains, and other public places. In other words, if your users sometimes access your website from a public hotspot and you do not use HTTPS, then anyone nearby the public hotspot can listen to all the traffic of the user. This is not the only situation that may happen to listeners, but it is indeed easy to do.

What if I only use HTTPS on the login page?

Don't do this. Using HTTPS only on the login page can prevent password theft, but this is only part of the problem.

First, the less HTTPS is used on your website, the easier it will be to actively intercept: your login link may point to an https url, however, if I change the link before the user clicks, HTTPS will not be able to help you. Some users may also face the risk of passive interception when using HTTPS.

The authentication username and password are only part of web user authentication: we also need to remember the account that a specific user has been verified and used for verification. The most common method is to use session cookies, which usually means that the browser stores a long random string, that is, session ID, in a cookie, for example, PHPSESSID can be used in PHP. The database on the server knows that the random string corresponds to a specific session, and that session corresponds to a specific authenticated user. If I get your session ID in some way, then after you log on, I will get all your permissions, which is no different from knowing your password.

Considering this risk, the session ID is very long and random, and its life cycle is limited. This means that I cannot guess it, so the session ID is safe enough. However, because of the cookie operation method, the browser will contain cookie information each time it sends a request to the website. Therefore, even if I have been logging on to every webpage for a long time, even if it is a public webpage, my session cookie will be sent by the browser. If someone is listening at this time, they can still tamper with my account.

If you only put the website administrator-related parts under SSL protection, the same situation may occur: When you log on and then access non-SSL public content, the browser also sends session cookies.

In short: Since session cookies that allow access to user accounts are sent in every request, it is absolutely not enough to ensure the security of login pages.

How can I correctly enable HTTPS? Force HTTPS

Some websites have purchased SSL certificates and configured them on the Web server, so that they are done. However, this only indicates that you have enabled the HTTPS option, and the user may not notice it. To ensure that each user benefits from HTTPS, you should redirect all incoming HTTP requests to HTTPS. This means that any user accessing your website will automatically switch to HTTPS, and their information transmission will be secure from then on.

However, the above practice leaves a blank: when a user sends a request to your website for the first time, they use common HTTP, and then they may already be transmitting confidential information. The preceding procedure also leaves a man-in-the-middle hole vulnerability ).

Strict Transmission Security Protocol

To further strengthen control, enable HTTP strict Transmission security protocol. This is a special header that can be sent by the server. It means that you cannot access the website through common HTTP within the specified time limit, you cannot access the website through HTTPS when the certificate is not reliable. The second-level domain name can also contain HSTS.

HSTS is a simple server header and easy to configure. However, you must note that you cannot undo the setting before the time limit ends. Therefore, do not set the time limit too long. You should use HSTS and HTTPS redirection at the same time, instead of replacing the latter with the former.

Secure cookies

Cookies, including session Cookies, have an optional security tag. Its general meaning is: "Do not send this cookie with a normal HTTP Connection" enable this security flag, so that your cookie will not be sent by the browser's initial HTTP request, the connection is switched to HTTPS and will no longer be listened on.

Can I only deploy SSL for authenticated users?

No. Once you have followed these guidelines, you cannot know whether the user has verified the normal HTTP connection. The key is that users should not transmit any confidential information, such as session cookies, unless they have already connected to SSL.

Although I can come up with other solutions to solve these security problems, they may fail at some point. Today, the cost of SSL is quite low, and it is not cost-effective to use other solutions.