I appreciate all websites who support ssl.
When visiting https://www.portableapps.com/ with firefox there is a warning becuase the certificate is for portableapps.com without www.
Afaik (I may be wrong) the standard way to deal with the certificate is to create it for the www.site.
+ is there still no certificate authority who creates free certificates (and built into browser by standard)?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Websites have the choice to use a www or not. The www is pretty much redundant these days and unnecessary for most sites, so this site doesn't even use it. If you type in www.portableapps.com, you're redirected to portableapps.com. Same if you use it on any pages here. That is by design.
And no, there is no free SSL provider that works with the major browsers nor is there likely to ever be.
Sometimes, the impossible can become possible, if you're awesome!
I always visit sites without www, because it's redundant. I hate it when sites don't work without it.
Also, question: aren't you supposed to have a valid email address for it?
"If you're not part of the solution, you're part of the precipitate."
Another issue, while visiting https://portableapps.com it switches me to https://portableapps.com/cached/front.html.
Next one, I visit https://portableapps.com/forums and click to some forum, then I see 'The selected file /var/www/vhosts/portableapps.com/httpdocs/tmp/fileimCua6 could not be copied.' (only when using SSL).
Might be also a good improvement to publish the sha1 fingerprint somewhere on this site. It could be used to confirm that the certificate is really from you and not someone else. (to confirm it users could search in some free internet cache service for this info)
Oh well, this is not really criticism, just ideas for improvements.
You're not supposed to be using SSL on this site. The SSL cert is only installed to get to the backend stuff securely. At no time does the site redirect you to an SSL version of the pages.
I'll drop a rule in to disable SSL for the rest of the site.
Sometimes, the impossible can become possible, if you're awesome!
Isn't it about time for all non-encrypted traffic to disappear
from the Internets ? ..
The site is certainly not set up for normal people to use SSL. Of course, since the site never asks for personal or confidential information, there's not a real reason for SSL. If it took credit cards or something, SSL would be mandatory.
There's also the minor detail that SSL causes a bit more traffic and requires more computing power. High volume sites frequently try to avoid anything that increases bandwidth or costs.
That said, I generally support standard use of encrypted protocols on the Internet. The days of sending everything in plain text are long past. It'd be good to be able at least to log on to the forum using ssl.
BTW the main restriction on names is that the name on the certificate has to match the name in the web address. It's the name in the web address that is being certified. If you put a different name there, the certificate doesn't apply. (It's not that www is optional, just that if you use it you have to include it in the certificate, and vice versa.) That can be controlled for the most part with redirections and links. If you make the web address (in the address field) match the certificate and still have warnings about the name, then you might have cause to wonder.
MC
(Choosing to revive this old thread instead of creating a new one about the same issue, as it is practical to keep such information together.)
I see two "SSL-related" needs that are currently not catered for, both which can be ommitted with additional solutions that would not require that portableapps.com is using its own SSL:
Example 1:
The ability to verify downloads can help rule out the potential situation where a man-in-the-middle could grab your (non-SSL/insecure) download and serve you a modified file instead. Such an attempt could easily also replace the list of MD5 checksums on-the-fly with one that reflected the checksum of the replaced download.
Example 2:
When we log in, we should either use an SSL protected page, or be able to use OpenID or the like from major other webservices that actually use SSL for their logins.
The rest of the information at portableapps.com does not need SSL, but those two examples should have their remedies, IMO.
There are plenty of situations and places around the world where it would be very useful to be somewhat "sure" that the list of MD5 checksums is the real/original one, and not tampered with, so that downloaded files can be calculated and compared to be sure they are the original version. Having the MD5-info downloaded insecurely from the same host (and mostly/most likely to the same place at the same time), defeats the purpose of such checksums. Those checksums are not a security measure unless they are either served over SSL or sent through a different, secured channel.
Those two concerns may be addressed WITHOUT enabling SSL for portableapps.com ..:
1a) To simplify and avoid unnecessary costs, etc., I think that one or more separate (external?) services should synchronize and archive all MD5 checksums on another (SSL-protected) domain, and automatically get all new filenames/file versions and checksum as new downloads are added.
1b) Alternatively: could the SourceForge links use SourceForge.net's own, existing SSL certificate? Right now it seems that there is a deliberate redirect in place to prevent the use of SSL, possibly from performance concerns. If not protecting the very downloads, how about making a deal with them about allowing manually entered SSL (add S to http yourself) for the page that contain the checksums there?
2) The login could be handled through OpenID/Single-Sign-On(SSO), which then would not require SSL certificate for portableapps.com.
For all intents and purposes, OpenID is dead... with the exception of some open source idealists. All the major players decided to ignore it and so we have multiple individual providers of single sign on (Facebook, Twitter, Google, etc), which means no single sign on.
SSL is overrated in terms of security as it only semi-secures a link between you and the server. Man in the middle attacks can still be done, of course. And forged certs are available from multiple legit providers via hacking, bribes, etc, as has been demonstrated hundreds of times last year. That's moot anyway as it does nothing to tell you that a server itself is secured.
Mirroring the MD5s to another server won't help as if the main server were compromised, the compromised app list would be shared to the uncompromised mirror server, which defeats the whole purpose.
We will be adding SSL logins at some point in the future (it's yet another thing that costs money, of course). Single signon actually makes things less secure (multiple points of failure) but we will be likely adding Facebook and Google at least as users demand it. OpenID is a failure in terms of the general population (95% of people have no clue what it even is) so we may very well skip it. And we'll be adding code to the updater and server to lock things down even further to prevent tampering.
Sometimes, the impossible can become possible, if you're awesome!
It's kinda strange to see an open source enthusiast discard a good idea because it isn't backed by the majority of internet users.
In my vision of the internet plurality is key and it is definitely not run by web moguls like Google, Twitter and Facebook. Steering the web in the right direction does not mean that you follow the population, but lead the population. Having principles and ideals costs resources and are not easy to maintain, that's why they can be so rewarding. So if OpenID works and is a good idea, why not join in?
Ok, I had to respond. This in no way negates the work you guys do and have done. I respect your decisions. It's only my reaction to your reasoning to not use OpenID.
Sure, technically it is OAuth that is the development focus, but OpenID also has its use cases, depending on site/situation, etc. And since this was a Drupal related consideration for PortableApps, I referred to that standard.
IMHO, it is not a matter of securing every possible vulnerability OR _none_. SSL is also not only for securing _your_ end. I am much more concerned with securing my password from the people on the same public Wi-Fi network wherever I go. Therefore, I prefer to log in through SSL, and I think that any service with respect for oneself and their users should offer SSL these days.
Having the downloads and MD5 checksums behind SSL would also help reduce (not _eliminate_) the potential risks and vulnerabilities from the downloader's perspective. It will help raise the trust/confidence for this service. Even if you could pose several technical reasons against that "real security", it would still offer _some_ extra security, and overall give a signal that PA takes security seriously.
So I would say it is worthwhile anyway.
A certificate costs around 70-120 USD for a limited scope, which would be sufficient in this scenario, I think. Could even use a self-signed certificate and post its public data on a reference site, so that it was possible to compare and verify it, if it was important to avoid such a cost.
I would not mind a self-signed cert, if the only alternative was to send the password entirely unprotected...
Hi again. The concern to protect the user account/password here is still valid.
You can now obtain free SSL certs at https://LetsEncrypt.org
But meanwhile there is a new option that might be easier to implement: TOTP/2FA..:
Since this web site is based on Drupal, there is now a functional TFA module here: https://www.drupal.org/project/tfa
That one will let us use both Google Auth and/or the GAUTH tool available via Mozilla Marketplace:
https://marketplace.firefox.com/app/gauth/
By installing that TFA module and making it optional to use its function, you can let users that want to secure their accounts do that even without SSL.
The GAUTH tool from Mozilla marketplace can be used with many sites, each with their own, unique ID, and export its list for backup purposes. Quite handy. Works on several platforms, and does not need a smartphone/can easily be re-installed also on USB sticks if one just has the list of IDs available for restore or manual re-entry.
I am using the Drupal 7 TFA module on several Drupal sites that I administer, it works well.
Two-Factor Authentication based on the TOTP open standard which also Google Authenticator is using (and thus can optionally also use that Google Authenticator App on modern Smartphones), will solve the concern about securing user accounts.
However, it will not solve the concern about serving checksums over insecure connection (even the same connection as the downloads).
That concern is at least as important as the account protection, as it is impossible to vouch for the security and reliability of the software that this web site is serving without it. We always have to warn people about the obvious risk of getting "something else" than expected when downloading. This is both annoying, unnecessary and prevents many people from using these tools.
As I am using virtualization on my computers, so I can still take that risk myself and with others that follow suit, but for people only using Windows in the normal sense (several clients of mine and other people I know), they cannot, and I therefore have yet never been able to fully recommend the downloads here without fat warnings and disclaimers. Just FYI.