Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.prolog > #14200

Re: comp.lang.prolog Frequently Asked Questions

From Mild Shock <janburse@fastmail.fm>
Newsgroups comp.lang.prolog
Subject Re: comp.lang.prolog Frequently Asked Questions
Date 2024-09-20 20:41 +0200
Message-ID <vckfk9$e32a$2@solani.org> (permalink)
References <18c37160924.070003@logic.at> <vcjocm$dmh8$1@solani.org> <vckfft$e32a$1@solani.org>

Show all headers | View raw


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.
> 

Back to comp.lang.prolog | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

comp.lang.prolog Frequently Asked Questions Markus Triska <triska@logic.at> - 2024-09-16 04:59 +0000
  broken and insecure links (Was: comp.lang.prolog Frequently Asked Questions) Mild Shock <janburse@fastmail.fm> - 2024-09-20 10:02 +0200
    Re: broken and insecure links (Was: comp.lang.prolog Frequently Asked Questions) Mild Shock <janburse@fastmail.fm> - 2024-09-20 10:39 +0200
      Re: broken and insecure links (Was: comp.lang.prolog Frequently Asked Questions) Mild Shock <janburse@fastmail.fm> - 2024-09-20 10:42 +0200
        Re: broken and insecure links (Was: comp.lang.prolog Frequently Asked Questions) Mild Shock <janburse@fastmail.fm> - 2024-09-20 10:59 +0200
          Re: broken and insecure links (Was: comp.lang.prolog Frequently Asked Questions) Mild Shock <janburse@fastmail.fm> - 2024-09-20 11:19 +0200
  Re: comp.lang.prolog Frequently Asked Questions Mild Shock <janburse@fastmail.fm> - 2024-09-20 14:04 +0200
    Re: comp.lang.prolog Frequently Asked Questions Mild Shock <janburse@fastmail.fm> - 2024-09-20 20:38 +0200
      Re: comp.lang.prolog Frequently Asked Questions Mild Shock <janburse@fastmail.fm> - 2024-09-20 20:41 +0200

csiph-web