Printable View
Surely, bearing in mind Google's intention to label all non-encrypted sites as "insecure" and the huge disadvantage in Google search rankings, GPWA.Org should be moving to SSL/https?
Even my affiliate site uses encryption! You do realise (English spelling) that any info members enter on the site is sent in plain text, over the internet? Think: hackers, sniffers, etc..
Just saying..
P.S. It cost me $7 (and a bit of hassle) to upgrade my site..
We do currently make limited use of SSL. For example, for those that use the GPWA seal, the site certify.gpwa.org that serves the GPWA seals is configured to work with SSL when it is requested. We did that a while ago so that a GPWA member site page using SSL could include a seal without warning messages being issued about insecure content being used on a secure page.
The big security vulnerability for vBulletin sites is for hackers to be able to gain control of an administrative account, and use that account to hack the site. We closed that vulnerability a long time ago by precluding access to any administrative portion of the site to anyone that is not accessing the site from a select set of trusted IP addresses, and to require secure VPN acccess for remote access to any of those trusted IP addresses. Separately, we also monitor all instances of administrative vBulletin accounts, and receive an alert within one minute if any new administrative accounts are added or modified.
However, I do agree 100% it makes sense for the GPWA to make broader use of SSL, and plan to have discussions with our technical staff this week on that topic. I do know we would want to use a more expensive certificate that will also confirm our identity as well, and we will need to factor in the level of technical effort required to change the site to use SSL, and how to effect a transition if there are technical issues to resolve first.
Michael
We did meet today to discuss providing ssl/https based encryption for users of the GPWA website. Our plan is to move in that direction as quickly as we can. We have determined that we would like to use an Extended Validation, or EV certificate. You can read about EV certificates here:
Wikipedia Article on Extended Validation Certificate
We expect to validate the following sites with the certificate once we have it:
www.gpwa.org
certify.gpwa.org
www.gpwatimes.org
We would like to use our trading name for the GPWA, and not our actual legal corporate name of Information Technology Systems, Inc. for these sites, so the process will likely require some additional work on our part to establish to the satisfaction of the certificate authority the legitimacy of the trading name and of our corporate entity. We actually plan to obtain a series of EV certificates for the different trading names we use (including, for example, Casino City and Casino City Press).
Michael
There is no "huge disadvantage in Google search rankings" for non-encrypted sites. That is a complete myth. I know because I have been through all this with several sites. If anything a site's rankings will decline slightly as all the 301 redirects from the non-SSL to SSL protected URLs take effect. If that is the only reason you are doing it then you're wasting your time and money. You should be more concerned about your visitors' privacy and transmission of personal data, or protecting your own admin logins to your site's back-end for example.
This has been discussed here before:
https://www.gpwa.org/forum/https-goo...ce-226547.html
That said, GPWA should be encrypting because everyone logging into an account here is exposing their password to interception. Depending on what people do or say on the forums here and in private messages that could be problematic. Also there have been incidences of this forum being hacked and having malware injected into pages in the past and SSL may help mitigate the risk of that happening again.
GPWA is without doubt going to run into some issues because of the site's ability for people to reference non-encrypted images and videos in the forums. Once you switch to SSL every single page with an externally referenced non-encrypted image or video on it is either going to throw up a mixed content warning in a visitor's browser or simply not display the image at all (nor the encrypted lock icon in the address bar) as the browser blocks it. The same thing will happen if you are using externally hosted banner ads served from a non SSL encrypted domain. So for sites with community created content it is not a simple task of just installing a certificate and redirecting.
Muppet, thank you for your feedback and comments. See below for my reply.
No, we are doing it to make sure passwords are secure and that private messages and other content cannot be intercepted. We are not concerned about admin logins or access to the administrative back-end because of other measures we have taken that we are comfortable provide appropriate security on that front.Quote:
Originally Posted by Muppet
Yes, I agree. In terms of the hacking that occurred in the past, use of SSL will also add complete protection against the man-in-the-middle attacks, which I do feel remain a current vulnerability until we make full use of SSL.Quote:
Originally Posted by Muppet
Fortunately, at least the non-encrypted images should not be an issue for us. Because of problems we previously had with images from other sites, we always cache local copies of images and serve those, rather than remotely referenced images, in our pages. Pretty nasty attacks are possible if you use images hosted on other sites, and we've seen that. Also, caching the images means that image references in posts don't become broken over time as the external references gradually stop working. In terms of videos, at least the major sites hosting videos all use HTTPS now, so there might not be too much of an issue on that front. We don't serve externally hosted banner advertisements, but we do use a separate ad server of our own, so we will need to also support SSL on the ad server, but we expect that will be fairly straightforward.Quote:
Originally Posted by Muppet
Michael
Thats great, it will make the job a whole lot easier!
I can confirm that.Quote:
Originally Posted by Muppet
Even with a very small pure old fashion html website without Wordpress or something like that, without any SEO "tricks" and facing a 5,000,000 keyword phrase you can rank in the top 5 without SSL if you have good content and disavow every 3-5 months the bad links sent by complete idiots who still believe such Kidergarten games will harm you.
Leopold
Don't believe everything you read. I'm glad others have jumped in on that remark too.Quote:
huge disadvantage in Google search rankings
Certainly not a "huge" disadvantage, but it has been a ranking factor at Google for a couple of years and they could choose to ramp it up at any point. With the recent change to Chrome, it looks like they are going that way.
Anyway... I have SSL on my site and the GPWA seal throws up an unsecure error even though I am using the https version of the code. Does anyone know how to fix it?
I will ask our technical team to investigate what might be happening. We will be in touch with you if we need help reproducing the issue ourselves.Quote:
Originally Posted by ukeaglesfan
Michael
Regarding the unsecure error mentioned above, I noticed in your html source that you are requesting the GPWA seal script using http:// not https://.
The Javascript script block should reference
https://certify.gpwa.org/script/goalprofits.com/
Steve
Today we did change the GPWA seal code to always make full use of SSL.
We encourage folks using the seal to use the new SSL version of the seal code. If you click on "My Seal Preferences" under "My Account" in the top navigation, you will be take to a page that lists all of your sites that are currently authorized to display the seal. Associated with each site there is a "Generate Code" link that will provide you with snippets of code to use that make use of SSL. Previously we let users specify whether they wanted to use http or https, and the default was http. In thinking about this more clearly, https should always be used. As mentioned in an earlier post in this thread, switching to use https prevents any hacker from intercepting seal insertions from intermediary transmission points on the web, something that we know was responsible for reported instances of seal hacking in the past in the form of a "man-in-the-middle" attack.
Separately, we will be changing the way the seal server works shortly, so that any attempts to reference the seal using http will be redirected to uses https instead.
Michael
Ahhh I forgot about the header code too. Thanks, that fixed it!Quote:
Originally Posted by GPWA Steve