To configure a tutorial that uses only HTTPS traffic on the server _linux

HTTP Strict transport Security (HSTs) is a security feature that Web servers use to tell browsers to communicate with them using HTTPS only, rather than using HTTP. This article explains how to enable HSTs on Apache2, Nginx, and LIGHTTPD. Tested on mainstream Web servers: Nginx 1.1.19, Lighttpd 1.4.28, and Apache 2.2.22, the environment is Ubuntu 12.04, Debian 6 & 7, and CentOS 6, only some of the parameters need to be adjusted Can work on other distributions.
What is HTTP strict transmission security?

Referenced from Mozilla Developer network:

• If a Web server supports HTTP access and redirects it to HTTPS access, the initial session of the visitor before redirection is unencrypted. For example, when a visitor enters a http://www.foo.com/or enters a foo.com directly.
• This gives an opportunity for man-in-the-middle attacks, which can be corrupted to redirect to a malicious site rather than an encrypted page that should be accessed.
• The HTTP strict transport security (HSTs) feature enables the WEB server to tell the browser never to use HTTP access and automatically replace all HTTP access to that site with HTTPS access at the browser end.

Here's a quote from Wikipedia:

HSTs can be used to protect against SSL split attacks. SSL Peel attack is a kind of man-in-the-middle attack, invented by Moxie Marlinspike in 2009. He exposed the attack in a speech titled "New Tricks for defeating SSL in Practice", published at the Black Hat conference. SSL stripping is implemented by preventing browsers from creating HTTPS connections with the server. The premise is that users rarely enter https://directly in the address bar, and users always enter the HTTPS page from an HTTP page by clicking a link or a 3xx redirect. So an attacker can block HTTPS by replacing all https://links at the beginning of a user's access to an HTTP page as http://.

HSTs can largely resolve SSL split attacks because as long as the browser has once created a secure connection with the server, the browser enforces HTTPS, even if the link is replaced with HTTP.

In addition, if the middleman uses his own self-signed certificate to attack, the browser warns, but many users ignore the warning. HSTs solves this problem, and once the server sends the HSTs field, the user will no longer be allowed to ignore the warning.

Scenario Examples:

When you access your net silver via free WiFi from a wireless router, unfortunately, this free WiFi may be provided by a hacker's laptop that will hijack your original request and redirect it to the cloned web-banking site, and all of your privacy data will be exposed to the hacker at the moment.

Strict transmission security can solve this problem. If you have previously used HTTPS to access your net silver, and your Web site supports HSTs, your browser will know that you should use HTTPS only, regardless of whether you have entered https. This will prevent the man-in-the-middle hijacking attack.

Note that if you have not used HTTPS to access the site before, then HSTs does not work. The website needs to tell your browser via HTTPS protocol that it supports HSTs.

The server opens HSTs by including the Strict-transport-security field in the HTTP response header returned by the server when the client makes a request through HTTPS. The HSTs field set when unencrypted transfer is not valid.
set up hsts in Apache2

Edit your Apache configuration files (such as/etc/apache2/sites-enabled/website.conf and/etc/apache2/httpd.conf) and downlink to your HTTPS virtualhost:

Copy Code code as follows:

# Optionally load the headers module:
LoadModule Headers_module modules/mod_headers.so
<virtualhost 67.89.123.45:443>
Header always set strict-transport-security "max-age=63072000; Includesubdomains; Preload "
</VirtualHost>

Your Web site now sends the request header on every visit, and the expiration time is two years (seconds). This expiration time is set to two years later, so tomorrow when you visit, it will be set for two years after tomorrow.

You can only set this header in the HTTPS virtual machine, not in the HTTP virtual machine.

To redirect your visitors to a corresponding HTTPS site, you can use the following settings:

Copy Code code as follows:

<virtualhost *:80>
[...]
ServerName example.com
Redirect permanent/https://example.com/
</VirtualHost>

If you're just doing redirects, you don't even need to set documentroot.

You can also use Mod_rewrite to redirect, but the above approach is simpler and more secure. However, Mod_rewrite can redirect the page to the corresponding HTTPS page, and the above configuration is redirected only to "/":

Copy Code code as follows:

<virtualhost *:80>
[...]
<ifmodule mod_rewrite.c>
Rewriteengine on
Rewritecond%{https} off
Rewriterule (. *) Https://%{http_host}%{request_uri}
</IfModule>
</VirtualHost>

Don't forget to restart Apache.
Lighttpd

For lighttpd It is simple to add the following configuration to your LIGHTTPD profile (for example:/etc/lighttpd/lighttpd.conf):

Copy Code code as follows:

Server.modules + + ("mod_setenv")
$HTTP ["scheme"] = = "https" {
Setenv.add-response-header = ("strict-transport-security" =>) max-age=63072000; Includesubdomains; Preload ")
}

Restart LIGHTTPD. The expiration time is also two years.
Nginx

Nginx is even simpler, add the following lines to the server block of your HTTPS configuration:

Copy Code code as follows:

Add_header strict-transport-security "max-age=63072000; Includesubdomains; Preload ";

Don't forget to restart Nginx.