HSTS Vulnerability Scan Failing on Port 8443 - Cloudflare's IPs

Hello -

We have HSTS enabled on our web app in Cloudflare as well as the directive in the site’s htaccess file. If our security company (Security Metrics) scans the domain, it is scanning Cloudflare’s IP’s where Ports 443 and 80 are passing, but Port 8443 is failing.

Is there a way to close Port 8443 or otherwise add HSTS to the headers on this port?

Thanks

Cloudflare’s edge listens on lots of ports…

You could listen on port 8443 on your origin as well and serve a redirect on it. Anything Cloudflare can do will return a block page so won’t satisfy your needs.

Or just explain to your security company you are using Cloudflare; they will have seen it before with other customers.

Our origin host blocks any requests to port 8443 which allowed the scan to pass. But it seems like Cloudflare was not blocking anything which caused the scans to fail.

It was made known to them that we were using Cloudflare and it didn’t really make a difference.

This is what was returned from a scan on the domain - i.e. through Cloudflare

https://i.imgur.com/uQLUfDt.png

30% of the Fortune 1000 use Cloudflare, they must have seen it before.

Is HSTS enabled in your Cloudflare account or are you just relying on the origin to do it? The former should make it work at the edge as on all my sites…

curl -I https://sjr.org.uk:8443
HTTP/2 301
date: Wed, 13 Dec 2023 21:51:02 GMT
location: https://www.sjr.org.uk/
cache-control: max-age=3600
expires: Wed, 13 Dec 2023 22:51:02 GMT
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=mJi%2BF%2BWimu6vHTa27xc5B6l2WkIikUt64x1TeI2Rd5GyPl4P3L2Sqq75SgRQbFvUP5aSQAgozw1w7adwefTJsADm57cLFcHelaSlON7R9dNOPfGYBxxZMoOXJIAcg8iLPps%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
strict-transport-security: max-age=15552000; includeSubDomains; preload
x-content-type-options: nosniff
server: cloudflare
cf-ray: 83516d15ae3f6582-LHR
alt-svc: h3=":8443"; ma=86400

@sjr -

Yes, HSTS is enabled on the account. I had Security Metrics revert back to scanning the domain again rather than the origin IP so that ports 443 and 80 are covered. But again, once the scan completes it is going to show that HSTS is failing on Port 8443.

They are going to submit it as a “False Positive” in order for the domain gets a “passing” grade, but this is something that we will have to resubmit quarterly which I was hoping to avoid.

What is the domain? If HSTS is enabled on the account (is it also enabled for subdomains?), an HSTS header should be being returned for it as above. (I don’t return HSTS from the origin, just leave Cloudflare to do it - and it would overwrite any HSTS origin header anyway).

@sjr -

The domain is https://theikefoundation.org - and yes, it is enabled for subdomains as well.

Your site does return a 522 timeout since your web server isn’t listening on 8443, however HSTS looks fine, even on 8443, see the strict-transport-security header

➜  Lagbrie curl -svo /dev/null https://theikefoundation.org:8443 |& grep --color=always -e "^" -e "transport"
*   Trying 104.21.15.195:8443...
* Connected to theikefoundation.org (104.21.15.195) port 8443 (#0)
* ALPN: offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /home/lagbrie/anaconda3/ssl/cacert.pem
*  CApath: none
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [4246 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=theikefoundation.org
*  start date: Oct 30 00:38:58 2023 GMT
*  expire date: Jan 28 00:38:57 2024 GMT
*  subjectAltName: host "theikefoundation.org" matched cert's "theikefoundation.org"
*  issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1P5
*  SSL certificate verify ok.
} [5 bytes data]
* using HTTP/2
* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: theikefoundation.org:8443]
* h2 [:path: /]
* h2 [user-agent: curl/8.1.1]
* h2 [accept: */*]
* Using Stream ID: 1 (easy handle 0x1023040)
} [5 bytes data]
> GET / HTTP/2
> Host: theikefoundation.org:8443
> User-Agent: curl/8.1.1
> Accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/2 522
< date: Sun, 17 Dec 2023 18:45:44 GMT
< content-type: text/plain; charset=UTF-8
< content-length: 15
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=ZIE2%2BdfLatFlupyya%2FPa0tJ1RwKDkxB5poxa2SfLBVE3mU7sZ%2Bk23DXZdm6P8VtXEF5FgF7pPwRyq5UUxosNYF4I2j2bfKoKR6oDdneVE4ad%2F%2B2ZFKKN7iPrkFYkOrzigVLc2jUDBSrs0uA3"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}

< strict-transport-security: max-age=15552000; includeSubDomains  <----- HSTS header without HSTS Preloading

< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< referrer-policy: same-origin
< cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< expires: Thu, 01 Jan 1970 00:00:01 GMT
< server: cloudflare
< cf-ray: 8371526958b02cd8-DFW
< alt-svc: h3=":8443"; ma=86400
<
{ [15 bytes data]
* Connection #0 to host theikefoundation.org left intact

What could be the problem is that your PCI Checker may require a larger max-age for the HSTS header (much like preloading does), however, HSTS is correct, on all available ports.