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]

I achieved this through TMS finally using a workaround

Replacing

{xen:link 'login/login'}

For

https://{$requestPaths.host}/index.php?login/login

That will force to ALWAYS login with https

I could style use that secure: link scheme though

 

[Kent]

It'll do you no good if a targeted user requests a single page over HTTP, as it could be modified to send the entered username/password on the login form or cookie to an external site. The user wouldn't even be aware it happened.

 

[Rigel Kentaurus]

It'll do you no good if a targeted user requests a single page over HTTP, as it could be modified to send the entered username/password on the login form or cookie to an external site. The user wouldn't even be aware it happened.

This is not to protect against xss or man in the middle attacks.

This is so I can force the login/login controller to always be generated as https from the html itself

 

[Kent]

This is not to protect against xss or man in the middle attacks.

This is so I can force the login/login controller to always be generated as https from the html itself

Then I misunderstood. What is your goal or reason for doing so?

 

[Rigel Kentaurus]

Then I misunderstood. What is your goal or reason for doing so?

There are different attack vectors that can be used by an attacker, one common one, in which I am vulnerable is: I take my laptop to a Starbucks, or any other common area, and I just enter my forum (not even login, just enter). With a plain connection an attacker can sniff the activity and steal my session. He suddenly has the ability to post as myself and do pretty much anything that my account can do.

Enter https. If I encrypt the site, the attacker can no longer sniff my session, or steal my session credential. This works if I am logged in.

However, if I am not logged in, then I need to login first. I need to send the credentials. Since I don't do https for guests the landing gets on mydomain.com is rendered without https. I fill my user and password, click on submit. And then after login, the site detects that I am a logged in user and redirects me to https.

But by then, it is too late. The original request was completely in plain. Anybody listening intercepted my user, password, and session. They even have even more information than with the other vector. The solution for this is changing the form action to secure:login/login, since then the post will be made to https, encrypted, and any sniffer would be able to see absolutely nothing.

This basic layer protects me for eavesdropper's in public places, which is basically what I want.

-----------

Now, there is always the chance that the router is a rogue one, or there is a promiscuous MAC pretending to be the router and is proxing the requests or pretending to be an authority for my site. In that case, as you were saying they could modify the html. However ...

The moment I hit on "login" it will go to https. At that moment the browser will check for the certificate. They won't have it. The request will not complete and my login would be stopped. While the person can show me any page they want with any content they want, they cannot intercept my credentials if the login is set up to be over https.

 

[Mike]

While the person can show me any page they want with any content they want, they cannot intercept my credentials if the login is set up to be over https.

Just to clarify, I think the point he was making was that if you are displaying the login form on a non-secure page, you have no way of guaranteeing that the request will actually to to the secure login form (or even your form at all) because they could just manipulate that page.

 

[Rigel Kentaurus]

Just to clarify, I think the point he was making was that if you are displaying the login form on a non-secure page, you have no way of guaranteeing that the request will actually to to the secure login form (or even your form at all) because they could just manipulate that page.

That is however a more advanced attack, it requires way more tools than a a passive sniffer being used by a script kiddie in a cafeteria.

 

[Mike Edge]

Why not just add to your .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

 

[Rigel Kentaurus]

Why not just add to your .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

I do not intend to make the site https only
That would be the trivial solution

 

[digitalpoint]

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

Sort of off topic, but I'm curious what the upside to having non-secure available? Overall, it would actually be a little more load on your server... since you are using SPDY for your website, it requires less HTTP connections to be made since SPDY sessions use a single one. Also makes the site faster for users under HTTPS because things like cookies and HTTP headers are able to be compressed (they are not without SPDY).

You should also consider using 128-bit encryption instead of the 256-bit you are using by default. The overhead of 256-bit encryption isn't worth it, and a higher number doesn't mean better.

Some good info:

http://security.stackexchange.com/q...ple-use-256-bit-encryption-instead-of-128-bit

if it takes with a 128 bit key 500 years to break a ciphertext and 1000000000 years with a 256 bit one, does it matter?

If you look at all the major sites, they all use 128-bit encryption (Google, Twitter, Facebook, Bing, etc.)

 

[Mike Edge]

Are you using 128 or 256-bit for DP?

 

[digitalpoint]

Would be kind of funny if I was running 256-bit after I just posted it's a pointless waste of resources...

But yeah... 128-bit. heh

 

[Mike Edge]

Would be kind of funny if I was running 256-bit after I just posted it's a pointless waste of resources...

Never know.. sometimes what's good for the goose isn't always good for the gander Ok, it's been a long week!

 

[Rigel Kentaurus]

Yeah, I think I will go down to 128, it is not inherently safer to use 256. The intention is just to get out of plain text anyway.

My main driver for not going full https is SEO, if this were a new site I would go full https no questions asked, but since it is a established site, Google considers the http and https addresses as different, it would have to do 301 redirects, and it is akin to changing the domain name.

Theoretically it would just work and the index and ranking would be transfered to the https, but this is a domain that recently changed from www to without www and I am discouraging doing yet another domain change in a short period of time.

 

[Rigel Kentaurus]

One single line in nginx and I am down to 128 bits. Provided I just want to protect myself from eavesdroppers this is good enough for me
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;

All this conversation is really nice, but I still stand to my suggestion of adding a secure: alias besides the canonical and full, and then I can use that through XenForo_Link::buildLink

 

[digitalpoint]

You won't lose any rankings at all by switching to https as long as you just 301 redirect http to https. Google is a lot smarter than you are giving them credit for. We went through going from vBulletin and HTTP-only to XenForo on HTTPS-only on the same day... different URLs, different protocol, and we didn't lose on iota of search traffic.

 

[Rigel Kentaurus]

You won't lose any rankings at all by switching to https as long as you just 301 redirect http to https. Google is a lot smarter than you are giving them credit for. We went through going from vBulletin and HTTP-only to XenForo on HTTPS-only on the same day... different URLs, different protocol, and we didn't lose on iota of search traffic.

I knew you would say that, because that is the common sense advice quoted by almost everyone

Funny thing, if this was someone else I would give the exact same advice, but since it is my site I am compelled not to follow it, because I have had past experiences that complete disprove that Google is as smart as we would like to believe

 

[digitalpoint]

I knew you would say that, because that is the common sense advice quoted by almost everyone

Funny thing, if this was someone else I would give the exact same advice, but since it is my site I am compelled not to follow it, because I have had past experiences that complete disprove that Google is as smart as we would like to believe

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/

 

[Forsaken]

Sort of off topic, but I'm curious what the upside to having non-secure available? Overall, it would actually be a little more load on your server... since you are using SPDY for your website, it requires less HTTP connections to be made since SPDY sessions use a single one. Also makes the site faster for users under HTTPS because things like cookies and HTTP headers are able to be compressed (they are not without SPDY).

You should also consider using 128-bit encryption instead of the 256-bit you are using by default. The overhead of 256-bit encryption isn't worth it, and a higher number doesn't mean better.

Some good info:

http://security.stackexchange.com/q...ple-use-256-bit-encryption-instead-of-128-bit



If you look at all the major sites, they all use 128-bit encryption (Google, Twitter, Facebook, Bing, etc.)

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