Mailing List Archive

Hi Peter,

On 30.08.21 04:24, Peter Horn wrote:
> I have been successfully running an Apache server for some years (currently 2.4.41 on Ubuntu 20.04LTS).
> I have three "real" http vhosts on port 80, findable through a dynamic DNS service. I also have a (first in line) default vhost with an "unreachable" ServerName, which returns a 4xx status,
> and exposes the request to fail2ban.
> This takes care of the script kiddies and IOT bug-probers who access by IP address, not hostname.
> Recently I upgraded to https on port 443, using LetsEncrypt and CertBot. The transition went smoothly; http requests to the vhosts on port 80 are returned a 301 redirect permanent to https.
> I have two questions:

> 1. Can I implement the same "nameless catchall" in the https environment, or does the vhost selection work differently there? My ssl cert appears to name all three real vhosts, but I am unsure
> what happens when a request doesn't match any of them.

The cert you are using lists only these three names (you could check via "openssl x509 -in <certfile> -noout -text"). All connections using IP addresses or names not part of the cert should
fail on TLS handshake (at least if certificate is validated by the client). You might catch clients, which do not validate certificates with your current TLS setup (that would be clients
connecting using IP). Clients that validate the certificate will not send the actual request.

Let's encrypt does not issue certificates for IP addresses (https://community.letsencrypt.org/t/ssl-on-a-ip-instead-of-domain/90635/3), so you can not simply add your IP to the certificate.

> 2. Are there any adverse consequences to closing down http / port 80 now that the vhosts are up on https / port 443?

That depends, new browsers versions are currently changing their behaviour on site access (e.g. see
https://blog.mozilla.org/security/2021/08/10/firefox-91-introduces-https-by-default-in-private-browsing/,
https://www.bleepingcomputer.com/news/google/google-chrome-90-released-with-https-as-the-default-protocol/). Older Browsers try HTTP (port 80) before trying HTTPS (port 443), some even do not
try HTTPS, if the initial HTTP fails. YMMV. I'd suggest to keep the HTTP vhost for pure redirects and additionally set the Strict-Transport-Security header (see
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) on HTTPS requests. With the header, most browsers will cache the information that HTTPS is enabled for your
site and even enforce it for the time you set in the header.

hth.
Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

> I'd suggest to keep the HTTP vhost for pure redirects and additionally set the Strict-Transport-Security header on HTTPS requests. With the header, most browsers will cache the information that HTTPS is enabled for your site and even enforce it for the time you set in the header.

If all your domain and its subdomains are HTTPS - you could look at using preload on the HSTS header...

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

and then submit the domain to https://hstspreload.org/

Most of the mainstream browsers will know not to send HTTP requests - and instead send HTTPS requests. This works better than the redirect as with the redirect the payload has already been sent un encrypted before being resent, and also POST data is in the redirect.


James



--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.B?KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB??[??X???X?KK[XZ[?\?\??][??X???X?P?\X?K???B???Y][?[??[X[??K[XZ[?\?\??Z[?\X?K???B

On 31/8/21 6:10 am, apache-httpd-users@thomas.freit.ag wrote:
> Hi Peter,
>
> On 30.08.21 04:24, Peter Horn wrote:
>> I have been successfully running an Apache server for some years (currently 2.4.41 on Ubuntu 20.04LTS).
>> I have three "real" http vhosts on port 80, findable through a dynamic DNS service. I also have a (first in line) default vhost with an "unreachable" ServerName, which returns a 4xx status,
>> and exposes the request to fail2ban.
>> This takes care of the script kiddies and IOT bug-probers who access by IP address, not hostname.
>> Recently I upgraded to https on port 443, using LetsEncrypt and CertBot. The transition went smoothly; http requests to the vhosts on port 80 are returned a 301 redirect permanent to https.
>> I have two questions:
>> 1. Can I implement the same "nameless catchall" in the https environment, or does the vhost selection work differently there? My ssl cert appears to name all three real vhosts, but I am unsure
>> what happens when a request doesn't match any of them.
> The cert you are using lists only these three names (you could check via "openssl x509 -in <certfile> -noout -text"). All connections using IP addresses or names not part of the cert should
> fail on TLS handshake (at least if certificate is validated by the client). You might catch clients, which do not validate certificates with your current TLS setup (that would be clients
> connecting using IP). Clients that validate the certificate will not send the actual request.
>
> Let's encrypt does not issue certificates for IP addresses (https://community.letsencrypt.org/t/ssl-on-a-ip-instead-of-domain/90635/3), so you can not simply add your IP to the certificate.
>
I wasn't expecting (and wouldn't want) a cert for an IP address,
particularly seeing mine is not static. What I am looking for is
something I could put into a RewriteCond on the first *:443 vhost to
trap that condition. Maybe an empty HTTP_HOST ?
>> 2. Are there any adverse consequences to closing down http / port 80 now that the vhosts are up on https / port 443?
> That depends, new browsers versions are currently changing their behaviour on site access (e.g. see
> https://blog.mozilla.org/security/2021/08/10/firefox-91-introduces-https-by-default-in-private-browsing/,
> https://www.bleepingcomputer.com/news/google/google-chrome-90-released-with-https-as-the-default-protocol/). Older Browsers try HTTP (port 80) before trying HTTPS (port 443), some even do not
> try HTTPS, if the initial HTTP fails. YMMV. I'd suggest to keep the HTTP vhost for pure redirects and additionally set the Strict-Transport-Security header (see
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) on HTTPS requests. With the header, most browsers will cache the information that HTTPS is enabled for your
> site and even enforce it for the time you set in the header.
I'll leave http / port 80 for a while, and keep an eye on legitimate
traffic (that would be redirected). I'll have a look at
Strict-Transport-Security.
> hth.
> Thomas
Thank you,
Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org