Any chance of SSL/https support in the future? Not only would this add security, but it would cut down on keyword sniffers, prying eyes, etc watching traffic (especially at work).
-
If you enjoy the forum please consider supporting it by signing up for a NES Membership The benefits pay for the membership many times over.
-
Be sure to enter the NES/MFS May Giveaway ***Canik METE SFX***
SSL Support?
- Thread starter Gadsden
- Start date
Speaking as someone who runs web sites: Adding SSL to all pages tends to add a lot of CPU cycles on the web server. It also costs a couple hundred bucks a year for the cert.
If your company is actively sniffing packets then they likely have monitoring software on your system and nothing is private.
On your own personal system on employers network try TOR...it encrypts traffic same as SSL. I wouldnt do any online banking with TOR, but for browsing NES its probably safe enough.
If your company is actively sniffing packets then they likely have monitoring software on your system and nothing is private.
On your own personal system on employers network try TOR...it encrypts traffic same as SSL. I wouldnt do any online banking with TOR, but for browsing NES its probably safe enough.
The Cert isn't an issue... for casual use you can just use a fake/self signed cert... who cares.
The CPU cycle thing is definitely a big problem, though.
What I'd probably do is run an SSH tunnel from your PC, set up a separate browser with a proxy back to your home PC and push the traffic through the tunnel.
-Mike
The CPU cycle thing is definitely a big problem, though.
What I'd probably do is run an SSH tunnel from your PC, set up a separate browser with a proxy back to your home PC and push the traffic through the tunnel.
-Mike
There are ISPs who sniff traffic for targeted ads, wireless attacks that capture cookies to hijack your session, and hostile TOR exit nodes that do all of the above. Correctly implemented, SSL protects against the majority of likely privacy compromises by non-state-actors.
As far as CPU overhead, in recent years processors have gotten a lot better, and the overhead for 'always SSL' is no longer a big deal. Google reports that switching GMail over to being fully SSLized only added about 1% to their CPU load:
http://techie-buzz.com/tech-news/google-switch-ssl-cost.html
No reason to buy a premium certificate, for under $50/year you can get a standard certificate from GoDaddy or another CA that is trusted by all modern browsers.
As far as CPU overhead, in recent years processors have gotten a lot better, and the overhead for 'always SSL' is no longer a big deal. Google reports that switching GMail over to being fully SSLized only added about 1% to their CPU load:
http://techie-buzz.com/tech-news/google-switch-ssl-cost.html
Google has the luxury of writing a custom app server. Part of that includes optimizations to SSL to reduce latency and overhead. If NES is running on a web server that has spare CPU cycles then sure spend the 50 bucks and have at it. I suspect that you will see some latency (ESP on cell phones) and the CPU will go up by a lot more than 2% if SSL were enforced for all requests.
As for TOR, who cares if some knuckle dragger in Istanbul sees you browsing NES...it's for anonymous browsing not banking. Argue JS exploits I guess....
As for TOR, who cares if some knuckle dragger in Istanbul sees you browsing NES...it's for anonymous browsing not banking. Argue JS exploits I guess....
JS injection is a big issue. If you control the exit node, you control the content. Try running a TOR exit node sometime.. you can do some very interesting things if you chose to be evil.
![[wink]](/xen/styles/default/xenforo/smilies.vb/002.gif "Wink [wink]")
Combine that with the auth being simple MD5 hashes and SSL may not be a bad thing. ![[smile]](/xen/styles/default/xenforo/smilies.vb/001.gif "Smile [smile]")
Going to 100% SSL provides optimal security, but yes, there is some latency
There's always the approach of locking down the highest risks first, for example implement SSL for logins, to prevent anybody from capturing usernames and passwords. Yes, sessions can still be hijacked, but at least the attacker doesn't have the actual password, just a (relatively) short-lived cookie.
Next, maybe configure the forum to do 100% SSL for admins, then green members, then all logged-in users. A staged approach doesn't give the same security as you'd get from forcing all traffic to always go SSL, but it does make it easier to determine whether the overhead is becoming a problem, and if so, take a step back.
There's always the approach of locking down the highest risks first, for example implement SSL for logins, to prevent anybody from capturing usernames and passwords. Yes, sessions can still be hijacked, but at least the attacker doesn't have the actual password, just a (relatively) short-lived cookie.
Next, maybe configure the forum to do 100% SSL for admins, then green members, then all logged-in users. A staged approach doesn't give the same security as you'd get from forcing all traffic to always go SSL, but it does make it easier to determine whether the overhead is becoming a problem, and if so, take a step back.
