Why are there only HTTP links for SDK repositories? [released]
asked 2018-03-07 23:47:28 +0300
Prelude question: Do the repo servers forward to HTTPS?
If not:
The SailfishOS Wiki and (more importantly) the SDK itself right now only have HTTP links to the repositories in place.
Given the generally sensitive nature of the transfered data (core libraries for the OS) and due to the weak checksum algorithm (SHA1 is obsolete and proven to be insecure since early 2017!) it seems like it's not too hard to mess with the SDK files in transit.
Also, credentials can be provided in the maintenance tool and unless the repo server forwards to HTTPS to default, they will be sent unencrypted.
Shouldn't all these connections be set to HTTPS/SSL by default? Probably even without the above security considerations, since releases.sailfish.org has SSL support?
Edit: I seem to have overestimated the gravity of SHA-1's demise. It's apparently not critical to use for file integrity checks.
Yes, it should only allow you to access via TLS (https) and switch over from http automatically.
But you can download the SDK using TLS by prefixing the URL with https: https://releases.sailfishos.org/sdk/installers/1710/SailfishOSSDK-Beta-1710-Qt5-linux-64-offline.run
takimata ( 2018-03-08 10:30:47 +0300 )editThanks. but can you say for sure? I mean, I know that you can just manually enter the URL with
rozgwi ( 2018-03-08 14:47:44 +0300 )edithttpsinstead ofhttp. But thats for downloading the SDK with the browser.I tried using
httpsURLs in the SDK maintenance tool for the early access SDK repo. It failed, saying it could not connect. Using the unalteredhttpURLs provided in the wiki does work.So, updating from the SDK apparently does not happen over SSL?
Yes, you are right. The application SDK even uses some 3rd party CDN: dtex8uumrfogh.cloudfront.net Indeed, not that secure... or maybe I've missed the signature files...
takimata ( 2018-03-09 17:29:47 +0300 )editEven though the "the gravity of SHA-1's demise" for checking file integrity may be exaggerated a bit in the original question, it raises a couple of valid points.
Without the use of HTTPS (i.e. currently) there is ...
Even if the integrity of the files in the download package are ckecked later via checksums or signatures files (e.g. while unpacking or installing), these files may also have been altered by an attacker, in line with altered executables.
olf ( 2018-03-19 13:24:03 +0300 )editAs authenticity checking is lacking, alterered files could be delivered by a rouge server, or due to the lack of integrity checking, they could be substituted (or altered on the fly) by a middle box.
@Jare: Can you comment on this?
rozgwi ( 2018-04-18 13:52:51 +0300 )edit