invite link uses insecure plain http

[freewil]

I was surprised to find out that the built-in invite link meant to send to friends doesn't even use https. This is somewhat concerning as it could be used to intercept requests and deliver phony software.

[jonathancross]

More info.
This is the URL: http://sgnl.link/1IvurmD
Here is the relevant line of code:
https://github.com/WhisperSystems/TextSecure/blob/84fa2d1a34c7d74efc3eab1599e03c036ab50b2f/src/org/thoughtcrime/securesms/ConversationActivity.java#L494

It is a "Branded short domain" from bitly.com.
Unfortunately https://sgnl.link is not configured.

[heyimgay]

It seems bitly does not support https. One solution is moving over to something self hosted like polr

[jonathancross]

Self-hosted would be better anyways. Security should trump marketing and in the case of encrypted chat software... security == good marketing.

[diederikdehaas]

I was also unpleasantly surprised by this. I'm trying to convince people to use Signal because it's secure and that argument isn't supported when the invite link is insecure.

[heyimgay]

We can use let's encrypt for a free https cert

[e12e]

Any progress on this? It's ridiculous to have users click a http link in an sms in order to install a "secure" app. I suppose one could claim that sms' are insecure anyway -- but if nothing else, it sends a bad signal (no pun intended). As the pwn2own competition has shown, following a link can be enough to compromise a phone.

As far as I understand from http://support.bitly.com/knowledgebase/articles/76741-how-do-i-set-up-a-branded-short-domain, and the whois record of sgnl.link - this is a domain name Whisper Systems own, registered through Dreamhost.I have no idea why a custom short-link is even needed. It would seem a better thing would be to set up a page that simply lists links to Android, iOS and Chrome versions -- or failing that does user-agent sniffing in order to redirect Android->Google app store, iOS->iTunes/Apple app store, and presents a list to desktop browsers (as one can install apps on a device from a desktop browser).

Currently the code redirects to either https://whispersystems.org/signal/install/param=a2 or https://whispersystems.org/signal/install/param=b2 (presumably for a/b testing?). I don't really see any reason for doing the randomization on the client - couldn't the code just link to: https://whispersystems.org/signal/install/ (and optionally have the web server/proxy do the a/b redirection)?

I don't really see people typing in the link manually (as opposed to clicking it, or copying it on the same device) -- so is there any real need for a short-url at all? Right now it just sets up a framework for easy interception of Signal install on insecure networks.