Domain name causing phishing warnings

1. Caddy version (caddy version):

V2, latest

2. How I run Caddy:

I’m running Caddy from a docker container on AWS lightsail, using a startup script since AWS lightsail containers don’t seem to permit persistence or modifying of container files. I cannot for the life of me get docker to run on multiple windows 10 machines that otherwise have no issues running VM’s, so have given up trying to make a custom image.

I’m mainly using lightsail containers because I both have access to them, and because they are provisioned with an SSL certificate and come with a system-generated URL/URI, as seen in the second example below (anonymised).

My current, url is here: I’ll change this if anyone can offer some support and I get the issue resolved:

I’m currenlty experimenting with versions of the following:
caddy reverse-proxy --from \:80 --to http\://\:1880
caddy reverse-proxy --from \:80 --to http\://\:1880 rewrite\:1880

a. System environment:

Docker container, caddy:latest, per the above.

b. Command:

Per the above examples

d. My complete Caddyfile or JSON config:

Not using a custom Caddfile as I’m not building a custom image. Please see the above comments.

3. The problem I’m having:

The issue that I’m having is that the reverse-proxy is causing a phiahing warning in Chrome. I can only assume that there’s some SSL interference happening here.

Does Caddy strip and replace SSL when operating as a reverse proxy? If so, this seems to be flowing through to the client browser, though it’s not clear to me what is going wrong.

4. Error messages and/or full log output:

Tripping up Chrome / Googles safe browsing extension.
Also fails in Firefox due to Safe Browsing

Seems to be getting triggered by mishandling of this:

5. What I already tried:

I’ve tried modifying the open ports and public endpoint port for the docker image. Variations of 80 and 443, or both.
80 for the public endpoint and 80 for the Caddy internal port works but fails with a security warning, meaning that the lightsail container access looks like URI:443 → Caddy:80 → Reverse Proxy Function → IP address of server

443 for the public endpoint seems to fail routinely under all scenarios. No route.

80 for the public endpoint, 443 for the Caddy internal port seems to fail. No route.

6. Links to relevant resources:

vs Google safe browsing:

According to the docs of the Safe Browsing API, one of the heuristics is suffix/prefix matching of the host/path of known list in Google’s database. When suffix-matching of the host, the rule is:

Up to four hostnames formed by starting with the last five components and successively removing the leading component.

The example of http://a.b.c.d.e.f.g/1.html shows it will try:

(Note: skip b.c.d.e.f.g, since we’ll take only the last five hostname components, and the full hostname)
c.d.e.f.g/ ← yours gets matched here

Applying the rule to your hostname, the test subjects of your hostname are: <-- or here <-- you're most likely matched here

I guess this means someone used the same platform for phishing before, and Google made note of it. You shouldn’t see it once you change the domain to your own.

Edit: Here’s background on the Enhanced Safe Browsing project: Google Online Security Blog: Enhanced Safe Browsing Protection now available in Chrome


This topic was automatically closed after 30 days. New replies are no longer allowed.