Skip to content

Exchanged man-in-the-middle for machine-in-the-middle #1846

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Exchanged man-in-the-middle for machine-in-the-middle #1846

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion translations/en/main.po
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3095,7 +3095,7 @@ msgstr ""
"\n"
"Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.\n"
"\n"
"HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period of *at least* 1 year (`max-age=31536000`) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired. \n"
"HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing machine-in-the-middle attacks. We consider a HSTS cache validity period of *at least* 1 year (`max-age=31536000`) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired. \n"
"\n"
"The test does **not** check whether `preload` is used and whether the domain is included in the [HSTS Preload List](https://hstspreload.org/).\n"
"\n"
Expand Down
6 changes: 3 additions & 3 deletions translations/en/news.po
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -303,7 +303,7 @@ msgstr ""
"* The detection of the internet provider is more precise and timeouts occur less frequent.\n"
"\n"
"## Website test\n"
"* The test checks whether a HSTS-policy is available. Through HSTS a web browser will 'know' after the first visit that a website can only be accessed through a secure connection (HTTPS, not HTTP). This can prevent so-called man-in-the-middle attacks, e.g. when using public Wi-Fi. In case of deviations, the message is no longer 'orange' but 'red'.\n"
"* The test checks whether a HSTS-policy is available. Through HSTS a web browser will 'know' after the first visit that a website can only be accessed through a secure connection (HTTPS, not HTTP). This can prevent so-called machine-in-the-middle attacks, e.g. when using public Wi-Fi. In case of deviations, the message is no longer 'orange' but 'red'.\n"
"* The test now checks whether the website enforces HTTPS by using a server redirect (301 or 302) or by applying only HTTPS (and no HTTP). In case of deviations, the message is no longer 'orange' but 'red'.\n"
"* In the case of some websites, the TLS results incorrectly showed that 'client-initiated renegotiation' was allowed. This has been solved.\n"
"* In the test results of websites with a redirect from IPv6/IPv4 to IPv4-only, the HSTS-policy over IPv6 remained incorrectly undetected. This has been solved.\n"
Expand Down Expand Up @@ -448,7 +448,7 @@ msgstr ""
"* Non-receiving domain: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use [Null MX](https://www.rfc-editor.org/rfc/rfc7505). In case your domain does *not* have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even *not* an Null MX record). \n"
"\n"
"## Minimum max-age for HSTS extended\n"
"HTTP Strict Transport Security ([HSTS](https://www.rfc-editor.org/rfc/rfc6797)) forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We have decided to extend the mimimum HSTS cache validity period from 6 months to 1 year (`max-age=31536000`). This is in conformance with the common good practice. \n"
"HTTP Strict Transport Security ([HSTS](https://www.rfc-editor.org/rfc/rfc6797)) forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing machine-in-the-middle attacks. We have decided to extend the mimimum HSTS cache validity period from 6 months to 1 year (`max-age=31536000`). This is in conformance with the common good practice. \n"
"\n"
"Further details on the above improvements can be found in the test explanations of the relevant subtests of the [website test](/test-site/) and the [email test](/test-mail/). \n"
"\n"
Expand Down Expand Up @@ -523,7 +523,7 @@ msgstr ""
"Below we describe the major changes.\n"
"\n"
"* The previous version of Internet.nl did test the **security of the HTTPS configuration over either IPv6 or IPv4**. Through manual testing we regularly see websites that have unintended different HTTPS configurations over IPv6 and IPv4. Therefore in the new release the HTTPS configuration is tested over both IPv6 and IPv4. **From now on** the result of this test item is part of the overall score in the website test.\n"
"* The website tests checks whether a **HSTS policy** is published. Through HSTS a web browser gets informed after the first usage that a website only may be visited over HTTPS. This can prevent so-called man-in-the-middle attacks (for example when a public Wi-Fi hotspot is used). The result of this test item is displayed as an orange warning in case the HSTS policy is absent. As of **July 2016** the result will be part of the score in the website test.\n"
"* The website tests checks whether a **HSTS policy** is published. Through HSTS a web browser gets informed after the first usage that a website only may be visited over HTTPS. This can prevent so-called machine-in-the-middle attacks (for example when a public Wi-Fi hotspot is used). The result of this test item is displayed as an orange warning in case the HSTS policy is absent. As of **July 2016** the result will be part of the score in the website test.\n"
"* The website test does test whether **HTTPS is enforced** for a website. There are two ways to enforce HTTPS that are described below.The result of this test item is displayed as an orange warning in case the HSTS policy is absent. As of **July 2016** the result will be part of the score in the website test.\n"
" 1. By redirecting HTTP to HTTPS. This can be done by redirecting `http://example.nl` to `https://example.nl`. It is important that both domain names are identical because a web browser does only accept a HSTS policy for a certain domain when a HTTPS connection is used. If `http://example.nl` redirects to `https://www.example.nl` then a HSTS policy normally will not be used by the browser, unless a user explicitly enters `https://example.nl` or clicks on a hyperlink with this URL.\n"
" 2. By only supporting HTTPS and no HTTP. Because a browser normally uses a HTTP-connection after a user enters a domain name, users should enter `https://example.nl` to reach the website or click on a hyperlink with this URL.\n"
Expand Down