Why are there only HTTP links for SDK repositories? [released]

Tracked by Jolla (In release)

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.

edit retag reopen delete

The question has been closed for the following reason "released in a software update"by rozgwi close date 2018-06-07 00:29:42.493356

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

( 2018-03-08 10:30:47 +0200 )edit

Thanks. but can you say for sure? I mean, I know that you can just manually enter the URL with https instead of http. But thats for downloading the SDK with the browser.
I tried using https URLs in the SDK maintenance tool for the early access SDK repo. It failed, saying it could not connect. Using the unaltered http URLs provided in the wiki does work.
So, updating from the SDK apparently does not happen over SSL?

( 2018-03-08 14:47:44 +0200 )edit

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

( 2018-03-09 17:29:47 +0200 )edit

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

• no check of authenticity of the server contacted: It could be a rouge one.
• no "state of the art" setup, as HTTP is generally being phased out.

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

( 2018-03-19 13:24:03 +0200 )edit

@Jare: Can you comment on this?

( 2018-04-18 13:52:51 +0200 )edit

Sort by » oldest newest most voted

SDK 1804 which improves on this a lot was just released to Early Access.

more

@martyone:
Now this is a welcome surprise, thank you!

After loading the update for the maintenance tool itself, I switched to https URLs for the EA repo and it works flawlessly!

( 2018-06-07 00:18:31 +0200 )edit