Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Mild Shock <janburse@fastmail.fm>
Newsgroups: comp.lang.prolog
Subject: Re: comp.lang.prolog Frequently Asked Questions
Date: Fri, 20 Sep 2024 20:41:15 +0200
Message-ID: <vckfk9$e32a$2@solani.org>
References: <18c37160924.070003@logic.at> <vcjocm$dmh8$1@solani.org>
 <vckfft$e32a$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 20 Sep 2024 18:41:13 -0000 (UTC)
Injection-Info: solani.org;
	logging-data="461898"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.19
Cancel-Lock: sha1:hCuuBGHnunO+liizx8Ns7sBTlBA=
In-Reply-To: <vckfft$e32a$1@solani.org>
X-User-ID: eJwFwYEBwCAIA7CXRGiVc4TR/09YAqexTxAMCDpl/IboUfFmvBp5pryvuSaAvbO2W74WZZqCFjbTLWbND2tiFdc=
Bytes: 5622
Lines: 131

To make it more secure, one would need to
edit pack.pl, the current content of pack.pl
is as follows. You need to edit line 6, and
change “http” into “https”:

1 name(pac).
2
3 title('Anonymous predicates expansion utility').
4
5 version('1.9.8').
6 download('http://web.sfc.keio.ac.jp/~mukai/pac-1.9.8.tgz').
7
8 author('Kunaki Mukai','mukai@sfc.keio.ac.jp').
9 keywords([anonymous_predicate,conditional_equation...

https://www.swi-prolog.org/pack/file_details/pac/pack.pl

So it shows a HTTP URL and not a HTTPS URL. HTTP
is insecure, HTTPS would be secure, the letter
S stands for secure. If you don’t want to edit

pack.pl ask your administrator to have automatic
HTTP to HTTPS redirect on the web server:

https://whois.jprs.jp/en/

Disclaimer: I don’t know whether the SWI-Prolog
package manager still works if you do some of
these steps. I assume so, but who knows? HTTPS
seems to be something new here,

although HTTPS was already introduced in 1995
by Netscape. Key milestones in the development
of HTTPS were:

- 1995: Initial introduction of HTTPS with SSL 2.0.
- 1999: TLS 1.0 introduced as an upgrade to SSL.
- 2014: The push for widespread HTTPS adoption
   increased with efforts like Let’s Encrypt,
   which provides free HTTPS certificates.

Mild Shock schrieb:
> The problem is the analogue of
> the pager explosion:
> 
>  > package manager directly talks to https
> 
> Thats correct, I get:
> 
>  > ?- setting(prolog_pack:server, ServerBase).
>  > ServerBase = 'https://www.swi-prolog.org/pack/'.
> 
> The pack server could nevertheless act as a
> multiplier of malicious software. For example
> if we look at supply chain attacks, then the
> weakest link determines the overall security.
> 
> How do you initially compute the hash? @kuniaki.mukai
> page doesn’t have HTTP to HTTPS promotion, and
> here he has published a HTTP url:
> 
> Package “pac”
> 1.9.8 526129e98f3910766eace5d63eaf7097739a7c5b 3 
> http://web.sfc.keio.ac.jp/~mukai/pac-1.9.8.tgz
> 
> https://www.swi-prolog.org/pack/list?p=pac
> 
> And the hash is listed side by side with a
> HTTP URL, doesn’t make much sense to me,
> since its not a HTTPS URL. A hacker can use
> this as a gateway to distribute a tampered
> 
> .tar that automatically has a tampered hash.
> And its not a blockchain and/or distributed,
> you compute the hash from the downloaded .tar
> 
> alone at client side, and what is computed at
> client side is identical to the server side,
> so there is no additional security. Or maybe
> 
> there is additional security? How is the pack
> upload realized on the packager side? I don’t know…
> 
> Mild Shock schrieb:
>> Since spoofing GIT content is so easy and
>> non-sandboxed Prolog code is a rather sensitive
>> thing, I guess this is why bother with HTTPS
>>
>> and a HSTS (HTTP Strict Transport Security)
>> policy could be important. SWI-Prolog packs are
>> non-sandboxed, unlike SWISH notebooks, right?
>>
>> Here is what ChatGPT says:
>>
>> An HTTP to HTTPS redirect vulnerability occurs
>> when an insecure HTTP connection is used to
>> redirect users to a secure HTTPS connection,
>> but the initial HTTP request is not adequately
>> protected. Here’s how this vulnerability might be exploited:
>>
>> - Man-in-the-Middle Attack (MitM): Since HTTP is
>> unencrypted, an attacker intercepting the
>> initial HTTP request could manipulate the
>> redirection process before the user reaches
>> the secure HTTPS site. This could involve:
>>
>> * Redirecting the user to a malicious site that
>> looks identical to the intended destination.
>> * Modifying the content in transit, such as
>> injecting malicious scripts.
>>
>> - Downgrade Attacks: Attackers could attempt to
>> keep users on an HTTP connection instead of
>> redirecting them to HTTPS, leaving communication
>> vulnerable to eavesdropping or tampering.
>>
>> The severity of an HTTP to HTTPS redirect
>> vulnerability can vary depending on the
>> context, but it is generally considered
>> moderate to high, depending on the following factors:
>>
>> - Moderate: For non-sensitive sites where the
>> main risk is traffic manipulation (e.g., content
>> modification or ads injection) without
>> significant consequences.
>>
>> - High: For sites handling sensitive user data
>> (e.g., financial services, medical information),
>> especially when users are likely to connect
>> over insecure networks like public Wi-Fi.
>