Tim:
> While it can do what you want, it is subverting the purpose of
> HTTPS. I'm not sure anyone should support a technique that hides an
> insecure connection behind a faked secure one.
Greg Woods:
I would dispute that. In my case, caddy runs on an internet-
accessible server, but the actual web server is behind two firewalls.
The unencrypted connection is entirely behind at least one firewall,
and if someone manages to gain access to the inside of that firewall,
then the game is already over. I don't think I'd recommend this for
enterprise setups, as there are too many potential threats already
behind the firewall (can you really trust every single one of your
employees?)
In the sense that if you can do it, miscreants can. We should be
endeavouring so that browsers can't be fooled, and thereby their users.
And some will argue that means disallowing overrides. e.g. How many
Windows users just clicked away the allow/deny pop-ups that were
supposed to protect them?
If you make things so your browser doesn't warn you that you're about
to do something unencrypted when it otherwise ought to be, you can be
setting yourself up for an exploit in the future.
But from following up on what's been previously written in the thread,
it sounds like something is erroneously triggering the use of HTTPS,
and that's the real problem. It could be how
dyndns.org is handling
redirecting connection attempts through their domain to their IP.
I run an externally hosted website, and I peruse the logs and see
various failed attempts to do something being logged. In my case,
their exploit attempts, not genuine browsing going wrong, so I do
nothing to help those failures.
--
uname -rsvp
Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.