Lack of interest canonical:, full:, please add secure:

[Rigel Kentaurus]

I am in the middle of implementing https on my site

I am not going "https exclusive". There is no good reason to do that when I have no intention on encrypting the traffic for guests and dealing with the SEO impact. There is some value on having both http and https available

My problem is the login at the top of every page. If it were a different page I could just redirect with mod_rewrite http:[login] to https:[login], however, on the current system, by the time I reach the /login action in XenForo, it is a post, the information has been sent unencrypted, and it is way too late.

I need to do a template edit to change the {xen:link login/login} to secure. However, I would need to hardcode the domain name itself, since there is no way to force a link to be secure. I hate that. I am proposing to add a new "secure:" protocol handler alias in such a way that if I do on the template

{xen:link secure:login/index}

It would generate the proper https link

https://xenforo.com/login

 

[Rigel Kentaurus]

Maybe there's something weird about your domain that Google doesn't like or something... but speaking from experience, our search engine traffic was up 6.22% after our switch to XenForo/HTTPS after 1 month (works out to thousands of more visitors per day).

https://forums.digitalpoint.com/threads/one-month-after-switching-from-vbulletin-to-xenforo.2637721/

The risk-benefit is just not there
Benefit of moving all to https: Less configuration, less tricks to make the login secure
Risk: Loosing 80% or more of the organic traffic

Yeah... I'll pass

 

[digitalpoint]

Google is upgrading their encryption keys in August to 2048-bit.

Two different things... keys should be at least 2048-bits (my encryption key for my certificate is 2048-bits), but the cypher is always less... 2048-bit key, 128-bit cypher for example.

In fact, I don't even think you can get a 1024-bit key anymore from any certificate authority even if you wanted one.

 

[Andy.N]

I am leaving this as reference in the event that someone might find that useful

ssl_ciphers ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:RC4+RSA:!AES256:!CAMELLIA256:+HIGH:+MEDIUM;

Why this and not this

ssl_ciphers ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:RC4+RSA:+HIGH:+MEDIUM

from http://unhandledexpression.com/2013/01/25/5-easy-tips-to-accelerate-ssl/

 

[Rigel Kentaurus]

Why this and not this

ssl_ciphers ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:RC4+RSA:+HIGH:+MEDIUM

from http://unhandledexpression.com/2013/01/25/5-easy-tips-to-accelerate-ssl/

That one would still enable AES and Camellia in 256 bits, and the intention was to encrypt at a maximum of 128 bits

$ openssl ciphers -v 'ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:RC4+RSA:+HIGH:+MEDIUM'

DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5 
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

 

[digitalpoint]

This is what I use for my Ngnix config...

ssl_ciphers    RC4:MEDIUM:!aNULL:!AESGCM:!CAMELLIA:!EDH:!MD5;

Basically I just really want to use RC4-SHA @128-bit

 

[Forsaken]

Two different things... keys should be at least 2048-bits (my encryption key for my certificate is 2048-bits), but the cypher is always less... 2048-bit key, 128-bit cypher for example.

In fact, I don't even think you can get a 1024-bit key anymore from any certificate authority even if you wanted one.

Derp, wasn't really paying attention to the thread.

 

[Anthony Parsons]

When I changed my site from http to https, htaccess force redirect everything from port 80, nothing changed with how Google handled my pages. It seems Google doesn't use the http part as any change of URL. All that happened is they progressively changed their cache of my site to https, zero impact on spidering or traffic.