1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

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

Discussion in 'Closed Suggestions' started by Rigel Kentaurus, May 30, 2013.

  1. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    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
  2. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    I achieved this through TMS finally using a workaround

    {xen:link 'login/login'}

    That will force to ALWAYS login with https

    I could style use that secure: link scheme though
  3. Kent

    Kent Active Member

    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.
  4. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    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
  5. Kent

    Kent Active Member

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

    Rigel Kentaurus Well-Known Member

    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.
    erich37 likes this.
  7. Mike

    Mike XenForo Developer Staff Member

    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.
  8. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    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.
  9. Da Bookie Mon

    Da Bookie Mon Well-Known Member

    Why not just add to your .htaccess

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

    Rigel Kentaurus Well-Known Member

    I do not intend to make the site https only
    That would be the trivial solution :)
  11. digitalpoint

    digitalpoint Well-Known Member

    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:


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

    Da Bookie Mon Well-Known Member

    Are you using 128 or 256-bit for DP?
  13. digitalpoint

    digitalpoint Well-Known Member

    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

    Da Bookie Mon likes this.
  14. Da Bookie Mon

    Da Bookie Mon Well-Known Member

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

    Rigel Kentaurus Well-Known Member

    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.
  16. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    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 :)
  17. digitalpoint

    digitalpoint Well-Known Member

    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.
  18. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    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
  19. digitalpoint

    digitalpoint Well-Known Member

    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).

  20. Forsaken

    Forsaken Well-Known Member

    Google is upgrading their encryption keys in August to 2048-bit.
    Rigel Kentaurus likes this.

Share This Page