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. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
