Secure version of the forum

[giosif]

Hi all,

I am a new member of the forum and I noticed that, although using https://... for the forum URL does work to some degree, it doesn't seem to be fully implemented.
Is this intentional/expected or an unintended problem?

I'm just thinking that at least my login credentials and PM's would be something I want to keep private, especially when accessing the forum via a hotspot.

Thanks,
George

[ve7xen]

+1

[miguelvp]

It's always a good idea to use different credentials for different sites. Https won't prevent an SQL injection. Not saying that it's possible in SMF but if there was an exploit that could be used to get the user's data SSL won't prevent it.

That said, Https will prevent people from intercepting your packets but then they will have to be able to gain access to the networks between you and the server, which is probably not hard since hostmonster and hostgator (same datacenter I believe) offer shells for those that need them.

[EEVblog]

Never considered it before.

[johansen]

I don't think there is really any reason to build a secure forum.

This isn't a chemistry forum, where LEOs are looking for folks with contraband three necked flasks.

[n45048]

Never considered it before.

I never noticed it before! I think it should be HTTPS by default for sure!

Also, I'm a little concerned about how many of the topics can be viewed without a login (and indexed on Google).

[David_AVD]

Also, I'm a little concerned about how many of the topics can be viewed without a login (and indexed on Google).

I suspect that's the way Dave likes it. 

[ovnr]

I never noticed it before! I think it should be HTTPS by default for sure!

Also, I'm a little concerned about how many of the topics can be viewed without a login (and indexed on Google).

Hah, really? If this was some locked-down forum where you couldn't view images or search or do anything without registering, I'd certainly not have joined in the first place. I expect the same applies to several others; I really detest the forums with those practices.

And why in the world would you be concerned about google of all things being able to index the forum? If they weren't, any searches would only turn up the front page - with keywords for that - not threads like the E4 hack, and the like.


On HTTPS: It's a forum. It's public. If you have even remotely good password habits (not reusing things which matter), getting your login credentials stolen is not a big deal. And who sends secret things via the PM system? Really? No, there'd be a ton of other things I'd have liked to see fixed here before full HTTPS support even entered into it.

[EEVblog]

Also, I'm a little concerned about how many of the topics can be viewed without a login (and indexed on Google).

It's a "free and open forum".

[Rick Law]

...
On HTTPS: It's a forum. It's public. If you have even remotely good password habits (not reusing things which matter), getting your login credentials stolen is not a big deal. And who sends secret things via the PM system? Really? No, there'd be a ton of other things I'd have liked to see fixed here before full HTTPS support even entered into it.
...

I think ovnr is right.  This is just a forum.  Communication here is for public to read even without password - so securing message from eavesdrop is pointless.  As to the log-on part, I can't imagine a scenario here where someone would stole a password just to post a note or read the personal message here.

Besides, why waste resources.  Two kinds of resource:

1. Don't care what broadband you use, there is always an upper limit on speed, be it net or CPU;  Encryption will use more data-bandwidth.  If your connection is by volume, it will hurt.

2. Some servers (PC's, smartphones, etc.) somewhere is going to burn cycle (ie:electrical power) just to deal with the overhead in transmit, encrypt, and decrypt things that is open and public.

It will be a stupid waste of resources and added trouble for admin or users for no good reason.

[Richard Crowley]

So is some proponent going to propose some legitimate reason to make this secure?
Else, it just sounds like free-floating anxiety. 

[Rigby]

Arguments about overhead are made only by people who have not measured it.  Bandwidth and CPU overhead for encryption is effectively zero. No one complains about gzip compressed http streams, which have a significant CPU overhead in comparison, and servers that serve gzip compressed http are extremely common.

More concerning to me are the people here trying to convince me that ANYTHING I do on the web should be done in the clear, even if it is just a forum.

[gnif]

Arguments about overhead are made only by people who have not measured it.  Bandwidth and CPU overhead for encryption is effectively zero. No one complains about gzip compressed http streams, which have a significant CPU overhead in comparison, and servers that serve gzip compressed http are extremely common.

Clearly you have not been exposed to large scale hosting setups, even enabling gzip on a site that is handling large amounts of traffic can cause CPU load issues. Also RSA accelerator cards still do exist and are still used in heavy hosting environments as RSA is a slow problem to compute, which is the entire point. I have deployed at least two of these over the last 6 months.

In this instance though, what is the point?

Positives:
  * Nobody can listen in and seal your credit card details... oh wait, this site doesnt use them.

Negatives:
  * Higher CPU usage overall
  * Each page load will invove SSL handshakes slowing down page loads for everyone
  * Since the service is proxied via CloudFlare, you can double that.
  * Harder to debug if there is HTTP connection problems
  * Anything inlined that is non ssl (ie, inlined images/videos from non SSL external servers) will cause SSL warnings and can (atleast with chrome) prevent the content loading.

More concerning to me are the people here trying to convince me that ANYTHING I do on the web should be done in the clear, even if it is just a forum.

I would be more concerned with the fact that the remote server is usually the point of attack, and it is where all your communication is decrypted back into clear. How do you know you can trust the remote server has not been compromised and is stealing your sensative data, or even storing it in the clear (yes, this does happen, look at the Sony PSN fiasco).

[HackedFridgeMagnet]

Once you get the certificate cant you just allow https for those users who do want it but still use http for the other 90%.
Also you can use one of your openssl certs I suppose to save a few dollars.

For example people posting from work may not want to send stuff in plain text.

[gnif]

Once you get the certificate cant you just allow https for those users who do want it but still use http for the other 90%.
Also you can use one of your openssl certs I suppose to save a few dollars.

For example people posting from work may not want to send stuff in plain text.

So you want us to fix every 'http' to 'https' across the entire forum & website since the beginning of time, just so the few paranoid users can use HTTPS when there is really no point?

Do you want your newspaper to come encrypted to your front door each day too?

If you are posting from work and you don't want your employer to know, doesn't that mean you are doing something suspicious anyway? And if you are that worried, a simple SSH tunnel to a remote server running a proxy such as squid would be the way to go.

SMTP, POP3 and IMAP are protocols that were originally all clear text, including password authentication. Recently SSL has become quite widely available for these... but if you send an email, servers still communicate between each other using SMTP with NO encryption. Now most in the field know it is not a good idea to send passwords/details via email, but many many many still do, some even take credit card details via email. So before we switch every public HTTP website to HTTPS, how about we fix other glaring holes in the way we do things.

[HackedFridgeMagnet]

I just thought it was a fairly simple change, but then again I have never run a forum.
My only experiences were running apache and IIS years ago on smaller web sites. I remember it being a relatively easy change.

I acknowledge you are in the best position to know how difficult the change is.

As to the moral side of things, I don't think posting on eevblog is immoral.
But some bosses may not like being talked about on EEVblog, or may see EEVBlog as a time wasting activity. I disagree.
Some posters who posting because they are bored@work may think it best to keep snoopers out of the loop though.

[ve7xen]

Encryption by default is a good policy, and where sensible should be adopted. In large part because trusting people with their own security is a good way to ensure they are not secure at all. Most people should know by now about good password policy, but of those, who exercises it? Especially on low-value accounts like EEVblog. I would wager that >> 75% of users here use the same password here as at least 5 other sites, probably many more. Some of those will be web e-mail accounts that lead to identity theft or blah blah blah. Defense in depth and don't trust the user: secure everything as well as you can without major hardship, regardless of perceived value.

And as "useless" as this account is, it would still be quite annoying if it were compromised, and not necessarily only for me, but for the EEVblog moderators as well.

On top of that, there are decent arguments for proxy traversal, privacy at work, etc.

There are few good reasons these days to do anything in the clear, even something as mundane as this. I'm kind of surprised to see the backlash on this thread, adding crypto is usually nothing but good.

That said, the embedding remote content issue is a problem, but the way forward is to offer your local content via HTTPS, not reject the idea and commit to the status quo forevermore.

Also: CloudFlare will handle SSL termination for you, along with all the performance implications for your backend. Use relative URIs in generated content and everything should "just work", aside from remote content.

[ve7xen]

SMTP, POP3 and IMAP are protocols that were originally all clear text, including password authentication. Recently SSL has become quite widely available for these... but if you send an email, servers still communicate between each other using SMTP with NO encryption. Now most in the field know it is not a good idea to send passwords/details via email, but many many many still do, some even take credit card details via email. So before we switch every public HTTP website to HTTPS, how about we fix other glaring holes in the way we do things.

Because the weak point is generally the end user's access. Aside from corrupt employees, obtaining sufficient access to a service provider network to sniff this traffic is a huge barrier to doing this kind of attack against a home user. When the attacker controls the access network (ie. your workplace) or when the access network is multiple-access (ie. WiFi), it is trivial.

Opportunistic SSL in SMTP is also fairly widely implemented these days, at least by the big boys. Google, Yahoo and Hotmail all do it.

Also EEVblog doesn't offer e-mail services, so those problems are not ones that can be addressed by its administrators.

[gnif]

There are few good reasons these days to do anything in the clear, even something as mundane as this. I'm kind of surprised to see the backlash on this thread, adding crypto is usually nothing but good.

It is not backlash, just pointless. As for SSL termination at CF, CF still needs a secure way to talk to the HTTP server, it does not terminate at CF, otherwise someone could just sniff the traffic between CF and the HTTP server.

Also EEVblog doesn't offer e-mail services, so those problems are not ones that can be addressed by its administrators.

That was not the point, it was an example of people thinking things are secure just because their connection to the server is secure.

In short, SSL will not be enabled on the server for the reasons stated previously.

[ve7xen]

It is not backlash, just pointless. As for SSL termination at CF, CF still needs a secure way to talk to the HTTP server, it does not terminate at CF, otherwise someone could just sniff the traffic between CF and the HTTP server.

Exactly. Which is comparatively extremely difficult, unless Dave decides to move the server to a coffee shop. Some security >> no security. Of course you could do it right, but you're railing against that idea, so the CF solution that requires basically zero effort and causes zero performance impact seems appealing.

That was not the point, it was an example of people thinking things are secure just because their connection to the server is secure.

The point is that a) people are fixing these problems and b) how about fixing the ones you can fix instead of deflecting to ones you can't. Anyway, there is no "secure", it's a continuum from airgapped, underground, TEMPEST-shielded vault to a machine with no passwords that does everything in the clear. Securing the "last metre" goes a long, long way to increasing the difficulty for this sort of thing. Most of the "attackers" are bored teenagers camping out at coffee shops, they're not going to start social engineering service provider networks to get that traffic another way if people start encrypting everything on the wireless. Neither are 99% of the criminals, it's a crime of opportunity and they're just going to move on to something else.

If you're not part of the solution, you're part of the problem.

In short, SSL will not be enabled on the server for the reasons stated previously.

It already is (or it is at CF, anyway), but semi broken. Google might even be directing traffic there, now that they're paying attention to HTTPs, since it is up and working just referencing insecure assets, so they can probably still index. Fix the absolute references to JS etc. and it will probably just work. Or we could stay in the 90s, it'll go with our test gear collections .

Edit: expand.

[SirNick]

SSL certs cost money to buy and maintain every year.  Maybe ~$100 a year is no big deal to Dave, but it's a non-zero sum of money that would be spent to protect a low-value resource.  (That being the passwords of forum users.)  The MUCH better solution would be to set your password here to "DavesForum12" or something like that, and not use it elsewhere.  That would sidestep the potential damage from sniffing and server cracking.

On a busy site, SSL overhead can be significant.  Especially if that busy site is on a shared hosting platform.  I dunno if Dave's server is dedicated, but either way it gets a lot of hits.  I've also deployed dedicated reverse proxy boxen in a former job role to mitigate the performance effects of encryption.  (The web servers were virtualized, so keeping their CPU usage low was beneficial.)

Finally, if Dave's site is in fact on a shared server, having an SSL cert would usually require having a dedicated IP, and IPv4 addresses are getting to be a scarce commodity.

In short, I don't see a pressing need for security here.  In most forum software, the actual password is exchanged fairly rarely anyway -- provided you allow persistent logins.  ("Remember me" on the site, and don't kill your cookies with fire every five minutes.)  Most of the time it's just a token that is mostly worthless to anyone else.

If you want to make the world a more secure place, it would be much more worthy of your time to focus on the pervasive practice of allowing password recovery with "security questions."  Remember -- don't write down your password, and don't use something easy to guess, but we'll let you reset it by providing some personal information that is often public record.

[ve7xen]

SSL certs cost money to buy and maintain every year.  Maybe ~$100 a year is no big deal to Dave, but it's a non-zero sum of money that would be spent to protect a low-value resource.  (That being the passwords of forum users.)  The MUCH better solution would be to set your password here to "DavesForum12" or something like that, and not use it elsewhere.  That would sidestep the potential damage from sniffing and server cracking.

Free certificates can be had from StartCom. Purchased ones can be had for < $15/yr. EEVBlog is hosted through CloudFlare which provides a free certificate, which they even provision and keep updated for you. Notice that https connections work today, with a validated cert.

Finally, if Dave's site is in fact on a shared server, having an SSL cert would usually require having a dedicated IP, and IPv4 addresses are getting to be a scarce commodity.

Most browsers that people actually use support SNI now, and this is a dedicated server anyway, so this is moot. Performance I already addressed. It can be an issue, but probably isn't, but this is moot because CF will do it for you if you don't care about end-to-end encryption (not advocating for it).

In short, I don't see a pressing need for security here.  In most forum software, the actual password is exchanged fairly rarely anyway -- provided you allow persistent logins.  ("Remember me" on the site, and don't kill your cookies with fire every five minutes.)  Most of the time it's just a token that is mostly worthless to anyone else.

The token can of course still be used to steal your session. This does not address any of the privacy issues.

There doesn't seem to be any argument for not fixing the minor absolute URI issues and letting CF frontend SSL requests as they already are. It's free, will benefit some users, and requires little work to get to 99% functional. Much embedded content can even work (YouTube, imgur etc.) if referenced properly.

If you want to make the world a more secure place, it would be much more worthy of your time to focus on the pervasive practice of allowing password recovery with "security questions."  Remember -- don't write down your password, and don't use something easy to guess, but we'll let you reset it by providing some personal information that is often public record.

I hate security questions, but can do little to get rid of them. Always put random strings in there. I can however advocate for crypto everywhere which will both make people more secure and make crypto less of an indicator of 'interesting activity' or people thinking you're a terrorist because you encrypt your hard drive. In most cases there is very little reason not to do it, and in those cases, I think we should.

[justanothercanuck]

Another issue with SSL is that you can't use a proxy (ie: squid) to cache text (posts) and images (in posts, as well as avatars, emoticons).  Well, you could, but it would involve MITM'ing everything that passes through the proxy (bad - some orgs do it, but it's not recommended).

[miguelvp]

Encryption is hardly pointless for this forum. In the UK ISPs are required by law to monitor the domain name of every site you visit, and scan every URL to matches against a secret blacklist using a system called Cleanfeed. More over it is known that the security services monitor the URLs that people access to profile them. Considering the crap that Dave got just for ordering some electronic components recently, I can see how someone accessing some "suspicious" URLs or making some "suspicious" posts here and then placing a Farnell order could cause them a lot of trouble.

In the post-Snowden world we have to re-build the internet to be resistant to mass surveillance. Encrypting everything, no matter how trivial, when possible is a good start. If it was not a major hassle (it shouldn't be) then the forum should use HTTPS by default, as all sites should.

And then there is this:
http://www.bbc.com/news/technology-29950946

Good luck on building your own internet or getting people to pay for the infrastructure of a freedom internet.
And even if you build it, you have to hook it to the actual net because you can't prevent the forwarding of data. It used to be a problem before until it was regulated so packets that don't originate or are destined for your network can use other networks so they can get there faster without having direct connectivity.

Kind of having to provide a public path on your property if that's the only way to access your destination.

[sunnyhighway]

There are only two valid reasons for using SSL encryption.

#1: Making sure you are looking at the EEVblog and not some imitation website who wants to trick you into thinking it is the real deal.
#2: Making sure the data you enter (like a password) cannot be intercepted by the Man In The Middle who now can start trolling under your name.

As for argument #1, this would cost the culprit a lot of money... to what avail?
Argument #2 would make some sense. Nobody would like his good name to be smeared by some troll who took the effort. But lets be realistic, wouldn't it be more easy for that wannabe troll to create a new account and start trolling away?