hi,
Windows 11, Firefox
today, trying to download a DEK-file from https://deken.puredata.info/
i get this pop-up message
this did not happen the last time i visited Deken.
rolf
On 10/21/24 11:41, rolfm@dds.nl wrote:
hi,
Windows 11, Firefox
today, trying to download a DEK-file from https://deken.puredata.info/ https://deken.puredata.info/
i get this pop-up message
this did not happen the last time i visited Deken.
then you browser was updated in the meantime :-)
the problem is , that these days browser do not like downloading stuff over http:// any more - *especially* when the http:// download is referred to from a https:// page. this somewhat makes sense, as the security is downgraded from a secure-protocol to an insecure one, and the rowser tries to warn you that now all kind of things could go wrong (man-in-the-middle attacks and what now), while you might (wrongly) believe, that everything is secured via https://.
(in your case: you access httpS://deken.puredata.info/, but it then links to a file on http://puredata.info/ (without the 's').
the reason, why deken uses the insecure http:// links is, that most Pd's out there don't know how to speak https://. TclTk itself does not come with https:// support, only with rudimentary (but good enough for our use-case) http:// support. As a user you can manually install the tcl-tls extension, and Pd will start to speak https://, but while this is easy on linux (with a system-installed TclTk), it's much more complicated on macOS and Windows. I just checked, and our deken server sees about 50 times more access via the http:// than via https://
because of these, the actual links to the DEK-packages (as stored in the deken database) use the http:// protocol.
one possible solution would be to check whether deken.puredata.info is accessed via https://, and then rewrite the package URLs to use https:// as well. i didn't implement this, as I did not want to special case the puredata.info server (which happens to make all content available via both https:// and http:// (the latter for precisely the reason to allow Pd to download the files). of course, puredata.info is currently the *only* server that deken.puredata.info speaks to, so my quest for generalization might be a bit over-the-top.
maybe, i'll implement something (there's already https://git.iem.at/zmoelnig/deken-server/-/issues/7), but i have no ETA.
in any case: the quick workaround for now, is to accept the security risk (and eventually verify the packages via the SHA256 sum and their gpg-signature - if there is one).
*or* just go insecure all the way and use http://deken.puredata.info/ (but this might not work, if you ever accessed https://deken.puredata.info/, as the browser remembers that it should access this page via https://)
gadmfsr IOhannes
On 10/21/24 12:53, IOhannes m zmoelnig wrote:
maybe, i'll implement something (there's already <https://git.iem.at/ zmoelnig/deken-server/-/issues/7>), but i have no ETA.
i think i've fixed the issue now: whenever you access deken.puredata.info via https, you will now also get https:// links to the packages, so the security warning should now be void.
i also think i now know what caused the disturbance in the first place: about a month ago or so, our security adviser told me to tighten up security on our webservices. one of the things that changed is that we know use an HSTS header, indicating that browsers should always use https:// to access deken.puredata.info (while at the same time, allowing the content to be served over http://, so Pd/deken is still happy). usually these headers are served over https:// (preventing a connection downgrade to http://), but we are using them on the http:// connection as well (nudging the browser to upgrade to https://)
long story short: i think we know have a working solution that uses https:// (both for searching an downloading) whenever possible, but still allows http:// access for legacy clients.
gfadmsr IOhannes
@ IOhannes
in my case the fix works: no security warning anymore.
great service rolf
IOhannes m zmoelnig schreef op 22-10-2024 9:50:
On 10/21/24 12:53, IOhannes m zmoelnig wrote:
maybe, i'll implement something (there's already <https://git.iem.at/ zmoelnig/deken-server/-/issues/7>), but i have no ETA.
i think i've fixed the issue now: whenever you access deken.puredata.info via https, you will now also get https:// links to the packages, so the security warning should now be void.
i also think i now know what caused the disturbance in the first place: about a month ago or so, our security adviser told me to tighten up security on our webservices. one of the things that changed is that we know use an HSTS header, indicating that browsers should always use https:// to access deken.puredata.info (while at the same time, allowing the content to be served over http://, so Pd/deken is still happy). usually these headers are served over https:// (preventing a connection downgrade to http://), but we are using them on the http:// connection as well (nudging the browser to upgrade to https://)
long story short: i think we know have a working solution that uses https:// (both for searching an downloading) whenever possible, but still allows http:// access for legacy clients.
gfadmsr IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/6HKM4M52IV...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
-
IOhannes m zmoelnig -
rolfm＠dds.nl