we are upgrading in the next few days.

[Amazonian]

I seem to be on auto pilot here again. The auto log in thing went away, but is back again. Any new upgrades/ changes Torsten?

I will do the old 'clear cache cookies history' thing and see if that helps.

Edit: fixed. Strange how it just started doing it all of a sudden though.

Edited October 17, 2013 by Amazonian

[indigo264nm]

Yeah was going to mention that there was some issue with the cookies and logging me out but figured I should clear my cookies first lol... also went and inspected the cookie data and noticed that I was allowing a pass hash to be saved without SSL on this site so will be turning that feature the fuck off.

Is there any intention of setting up https? I'm kinda not particularly comfortable with having an account on sites without SSL to secure user and pass data during login and it's not exactly difficult to set it up.

[Sallubrious]

https isn't without issues either, there have been a few incidents with fake certificates in recent years. Then there's the dreaded MITM

DNSSEC type of DNS lookup techniques are the way of the future.

Don't get me wrong https would certainly give another layer of security but personally I just don't trust it anymore. Anything you post on here is public information anyway, it's just the PM's that are vulnerable. aTom posted a good thread on basic encryption which you can use for your PM's, most script kiddies wouldn't have a hope in hell of subverting that at the moment.

http://www.shaman-australis.com/forum/index.php?showtopic=35293

If big brother wants your intimate secrets they can monitor you at ISP level and stage their own MITM type of setup which would make an SSL certificate redundant anyway. If they intercept your PGP encrypted PM's they will have to crack the encryption before it can even be analysed and when they do they could be chasing a wild goose.

[indigo264nm]

Oh dude don't get me wrong I know that https isn't perfect. It's a fucking breeze to MITM and drop em down to just http + sniff passes in plain text... if you're standing between the host and a gateway in particular, but at least it has telltale signs which hard to miss.

Basically https is better than nothing.

My concern is not big brother dude. My concern is to do with forums like this being prime targets by hackers... I admin on an telecommunication web server that provides enterprise level service, and I see whats dudes are trying all the time from logreports.

On forums I guarantee plenty of people people use the same password for their email address as their login, and same user and pass for other web accounts, AND provide the email address for which they share those passes. Hackers know this as well.

Edited October 20, 2013 by indigo264nm

[Torsten]

IPB does not run on https without custom modification [beyond me]. apparently it is something they are looking at developing.

[indigo264nm]

Had a look and it's definitely doable. You'd need to a purchase a domain validated certificate but besides that if you're ever keen send me a PM and I'll happily have a crack it for you.

[Sallubrious]

Oh dude don't get me wrong I know that https isn't perfect. It's a fucking breeze to MITM and drop em down to just http + sniff passes in plain text... if you're standing between the host and a gateway in particular, but at least it has telltale signs which hard to miss.

Basically https is better than nothing.

My concern is not big brother dude. My concern is to do with forums like this being prime targets by hackers... I admin on an telecommunication web server that provides enterprise level service, and I see whats dudes are trying all the time from logreports.

On forums I guarantee plenty of people people use the same password for their email address as their login, and same user and pass for other web accounts, AND provide the email address for which they share those passes. Hackers know this as well.

Yeah I had some real reservations about forum logins a few years ago, I even had a bit of hiatus where I stayed away because of the reasons you've outlined. I never had a loose policy when it came to passwords and as a result I had to commit nearly 30 different passwords to memory. There was a few times when I was pissed and typed a password from another site and that always left me wondering if it'd been sniffed.

Recently my ISP blocked ICMP packets which left me in the dark to some extent, now I can only monitor the first two hops.

I see where you're coming from https would give me a quantum of solice. It would be one avenue denied from a thief sitting in some unknown place doing their homework.

[Torsten]

have a look at the discussion HERE.

it's possible, but messy. I was hoping for IPB to fix this. because of the size of this forum we can't afford any errors - it takes many hours to reindex/fix things.

[Nemisty]

Sorry to veer off topic but Torsten. You always seem to post at some insane ealry hour of the morning. Are you nocturnal or do you just wake up super early? I've always wondered

[Torsten]

definitely nocturnal. my normal bedtime is roundabout now.

[indigo264nm]

Yeah that was the forum

have a look at the discussion HERE.

it's possible, but messy. I was hoping for IPB to fix this. because of the size of this forum we can't afford any errors - it takes many hours to reindex/fix things.

Yeah that was the thread I read about it when I said it looks doable.

I've had to do far messier over the past few months when downtime isn't an option because it means losing money.

There are only 3 files I see necessary to be modified in the process - httpd.conf, .htaccess and conf_global.php. Way I usually go about it is I create a backup of the file, make a modification, refresh webpage in browser - if connection fails, revert to backup file. Downtime less than 60 seconds each time this happens.

Also for this kind of operation if the SSL side of things errors in configuration during majority of the process just means the connection when trying to use https will revert to http instead.

Worth considering anyway.

[Torsten]

The problem isn't the modification. There are plenty who can write the code. The problem is that these modifications get overwritten with each update. So I need to make sure the coding is done each time. It may also break the autoupdate because it may then not look for the things in the right places.

I'll do a bit more reading on IPB forums to see if there are plans for full SSL soon.

[Sallubrious]

It sounds like you've had some headaches with indexing problems in the past T.

That sort of shit can be an absolute nightmare & I can understand the trepidation. From my limited understanding the config files indigo is referring to aren't really involved with indexing though.

The main issues seem to be offsite data dropping back to a http connection. After login that becomes to some extent irrelevant.

IPB seem to be sitting on their hands with this issue and making excuses, in this day a forum admin really should have https as an option that can be disabled in the event of problems.

[indigo264nm]

Sure, I understand Torsten. I'm not really a coder - just deal with more the virtual server and network side of things, and often bridging services to PHP apis which can often require coding or at least modification of other source code. So basically majority of my scripting involves just automating custom tasks for the server.

As Sally said the files I'm taking about don't really involve indexing, and the first two I mentioned are strictly involved with the webserver which should only get overwritten if you were to purge Apache or whatever of the configuration files. The first more specifies the global Apache (as an example) config like the webserver IP and port configurations, the location of the folder on the server, and the modules to load etc. The second provides more the rules specific to particular hosts, pages and folders on the server.

e.g. of stuff in httpd.conf info

#<VirtualHost *:80>

# ServerAdmin [email protected]

# DocumentRoot /www/docs/dummy-host.example.com

# ServerName dummy-host.example.com

# ErrorLog logs/dummy-host.example.com-error_log

# CustomLog logs/dummy-host.example.com-access_log common

#</VirtualHost>

The SSL server and certificate configuration runs as it's own service outside of PHP and Apache, and then a module for Apache (mod_ssl) allows you to tell sites how to use SSL.

mod_ssl:

<VirtualHost example.com:443>

ServerName example.com

ServerAlias example.com

DocumentRoot /var/www/html/example.com

LogLevel warn

SSLEngine on

SSLProtocol all -SSLv2

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

SSLCertificateFile /etc/ssl/cert.crt

SSLCertificateKeyFile /etc/ssl/keyfile.key

SSLCACertificateFile /etc/ssl/Bundle.crt

.....etc etc etc

</VirtualHost>

The convenient thing about HTTPS is that it just serves to direct the same information but just over a secure channel if it can, but otherwise business as usual if a secure connection cannot be established. When configured this way at least a tell tail sign that a MITM + SSLstrip is occurring is that there isn't green colour and a padlock symbol.

There is no need to alter the structure of the website itself, and the autoupdate will find everything in the exact same places.

In terms of indexing there is a htaccess rewrite that directs secure traffic over SSL and unsecure traffic as normal.

"Doing this will redirect any traffic on the secure socket layer that is requesting your robots.txt file to the robots_ssl.txt (but not on unsecure version. your regular robots.txt will be served). Bam you can now serve both secure and unsecured versions of your website without fear IMO it is better to have your non secure pages be indexed. My website did much better in google with non secure pages, and this will avoid duplicate content penalization. "

Hope you find this information useful at the very least when SSL is supported enough for you to consider configuring, and I do understand your reservations. I was just trying to help since I deal with this stuff a fair bit - work and hobby.