Cloudflare 'Always use HTTPS' behavior change causing 'SSL not available' risks to be raised.

All additional risks generated have now been removed.

The score history graph may continue to show a dip for a period of a week. If needed, please use this incident as evidence of why the score dropped temporarily.

A change to UpGuard's scanning engine has been deployed. The additional 'SSL not found' risk detected on domains using Cloudflare proxy services, will be removed upon the next scan. All domains will be rescanned within 24 hours, and this issue will be resolved.

We are currently developing and testing a change to UpGuard's scanning engine to ignore unused Cloudflare HTTP ports. This will cause the 'SSL Not Available' risks to be removed when the domains are rescanned next.
The next update will be after this change has been implemented.

In Cloudflare, there is a setting in SSL->'Edge Certificates'->'Always use HTTPS' that is used to redirect from http to https for Cloudflare proxied domains.

The behavior of this setting changed last week (approx June 26) for non-standard ports. This change causes a failure when browsing to the port, instead of a successful redirect and response. This has caused UpGuard's scanning engine to detect these as not using HTTPS, and therefore raises a risk 'SSL Not Available'.

The non-standard ports HTTP ports used by Cloudflare are: 8080, 8880, 2052, 2082, 2086, 2095. The default http port (80), has not changed behavior.

Using upguard.in as an example, previously this setting would perform like this:
http://upguard.in:8080 → redirect to https://upguard.in
and now it behaves like this:
http://upguard.in:8080 → redirect to https://upguard.in:8080 (and https fails on this http only port).

Cloudflare support have not responded at this time, and we have found no documentation to support a change in behavior.

Public risk waivers with an short expiry have been put in place against UpGuards domains, while we investigate.