Closed WKobes closed 1 year ago
@WKobes Thanks! @mxsasha Is this something you can fix or do we need to ask our hoster to fix this?
So the primary real world problem:
https://conn.internet.nl/ should serve a Strict-Transport-Security: max-age=0
¹ and redirect to http, only because it served Strict-Transport-Security: max-age=36817200
in the past. After the HSTS expire of 1 year, https can 404 and no HSTS header needs to be served.
Secondary:
Fix some Apache virtual host settings, the top most VirtualHost
which uses *
(or the alias _default_
) is used. Since most of the times separate .conf
files are used and files are loaded alphabetically, it helps creating some 000-default.conf
to force loading this default VirtualHost first.
¹ See MDN:
Should it be necessary to disable Strict Transport Security, setting the
max-age
to 0 (over an https connection) will immediately expire theStrict-Transport-Security
header, allowing access via http.
We discussed to hold off on this for #890 (or a follow up PR), because as part of that project we will add testing for our web server setup. Currently it is untested, poorly documented, and fragile.
@aequitas: Has this been fixed in the nginx config of the Docker image?
It has not (curl -kv):
* Trying [2001:19f0:6c01:1ec3:42::1000]:443...
* Connected to conn.id.as213279.net (2001:19f0:6c01:1ec3:42::1000) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN: server accepted http/1.1
* Server certificate:
* subject: CN=id.as213279.net
* start date: Aug 21 13:34:56 2023 GMT
* expire date: Nov 19 13:34:55 2023 GMT
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* using HTTP/1.1
> GET / HTTP/1.1
> Host: conn.id.as213279.net
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Tue, 22 Aug 2023 11:37:28 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 10562
< Connection: keep-alive
< Content-Security-Policy: default-src 'self' *.id.as213279.net; form-action 'self' *.id.as213279.net; base-uri 'self' *.id.as213279.net; frame-ancestors 'none'
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< X-Clacks-Overhead: GNU Terry Pratchett
< Referrer-Policy: strict-origin-when-cross-origin
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31536000;
<
<!DOCTYPE html>
<html lang="en" >
<head>
<meta charset="utf-8">
<title>Test for modern Internet Standards like IPv6, DNSSEC, HTTPS, DMARC, STARTTLS
and DANE.</title>
@aequitas: See @mxsasha's above comment. Could you check/fix? Thanks.
I'll have a look
Fixed in #890
The default response over HTTPS for any hostname on the internet.nl infrastructure defaults to the emailveilig.internet.nl campaign site. This also includes IP addresses:
https://62.204.66.10/ https://[2a00:d00:ff:162:62:204:66:10]/
But in the current configuration, anyone can set up a pointer to these IP addresses which will give the emailveilig campaign: https://internetnl-default-page.wouter-kobes.nl/
The main solution here is to make the default SNI resolve to a 404 response instead.
The current configuration causes specific problems for the connection test. Due to #324, the test is over HTTP instead of HTTPS. However, once a user has visited conn.internet.nl over HTTPS, or uses the "use HTTPS by default" browser option, an HSTS is set and the user will no longer be able to visit conn.internet.nl over HTTP and thus execute the test.
The fix above would prevent the HSTS to be set, but visiting conn.internet.nl over HTTPS would give a 404. To prevent this, we either have to address #324 OR to set a downgrade redirect from https://conn.internet.nl to http://conn.internet.nl.