New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop login-over-https feature #5729

Closed
ewinslow opened this Issue Jul 1, 2013 · 12 comments

Comments

Projects
None yet
5 participants
@ewinslow
Member

ewinslow commented Jul 1, 2013

Current available setting is login-over-https:

  • provides marginal benefits to end users
  • adds significant complexity to Elgg.

Full https:

  • easier for us to support
  • much safer for end users
  • already usable by someone using login-over-https.

I'm personally in favor of dropping login-over-https support completely and forcing admins to go all or nothing.

@cash

This comment has been minimized.

Show comment
Hide comment
@cash

cash Jul 1, 2013

Contributor

I'm fine with dropping login over https. Sites that really want it can probably implement it by overriding the login views.

Contributor

cash commented Jul 1, 2013

I'm fine with dropping login over https. Sites that really want it can probably implement it by overriding the login views.

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Jul 1, 2013

Member

@mrclay, thoughts?

Member

ewinslow commented Jul 1, 2013

@mrclay, thoughts?

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay Jul 2, 2013

Member

Cash is probably right on the do this via a plugin, but I still see this as forcing a big change on sites that want to protect user's passwords but don't have the overhead to serve everything over SSL.

What is the "significant complexity" in supporting this?

Member

mrclay commented Jul 2, 2013

Cash is probably right on the do this via a plugin, but I still see this as forcing a big change on sites that want to protect user's passwords but don't have the overhead to serve everything over SSL.

What is the "significant complexity" in supporting this?

@cash

This comment has been minimized.

Show comment
Hide comment
@cash

cash Jul 2, 2013

Contributor

I think Evan is exaggerating a little on the significant complexity. It does involve some hacky code where we check if https login is on and add an extra 's' to certain actions. It also doesn't work for sites that don't use 443 for their SSL port.

Contributor

cash commented Jul 2, 2013

I think Evan is exaggerating a little on the significant complexity. It does involve some hacky code where we check if https login is on and add an extra 's' to certain actions. It also doesn't work for sites that don't use 443 for their SSL port.

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Jul 2, 2013

Member

See #4693. Our current implementation is providing near 0 benefit because of this. Fixing it will be complex. Much easier to just set your site root to https.

Also, the logic for https login is duplicated in a few places. If you spit out your own login form, you have to remember to respect the setting, etc.

Is the overhead you're concerned about just the additional CPU required for encryption?

Member

ewinslow commented Jul 2, 2013

See #4693. Our current implementation is providing near 0 benefit because of this. Fixing it will be complex. Much easier to just set your site root to https.

Also, the logic for https login is duplicated in a few places. If you spit out your own login form, you have to remember to respect the setting, etc.

Is the overhead you're concerned about just the additional CPU required for encryption?

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay Jul 2, 2013

Member

Concerns as I understand them:

  • Round trips introduced by SSL handshakes, particularly painful on mobile. Keep-Alive should mitigate this somewhat
  • Not sure how this interferes with caching proxies*.

I can do more testing in this area.

(*aside: I turned on Apache's mod_cache and it delivers quite a dramatic boost. We should recommend all Apache users use it as it's trivial to enable.)

Member

mrclay commented Jul 2, 2013

Concerns as I understand them:

  • Round trips introduced by SSL handshakes, particularly painful on mobile. Keep-Alive should mitigate this somewhat
  • Not sure how this interferes with caching proxies*.

I can do more testing in this area.

(*aside: I turned on Apache's mod_cache and it delivers quite a dramatic boost. We should recommend all Apache users use it as it's trivial to enable.)

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Jul 27, 2014

Member

Some more data on HTTPS performance: https://istlsfastyet.com/

  • SPDY/HTTP2 is only supported over HTTPS
  • HSTS can get rid of the HTTP->HTTPS round trip problem
Member

ewinslow commented Jul 27, 2014

Some more data on HTTPS performance: https://istlsfastyet.com/

  • SPDY/HTTP2 is only supported over HTTPS
  • HSTS can get rid of the HTTP->HTTPS round trip problem
@jdalsem

This comment has been minimized.

Show comment
Hide comment
@jdalsem

jdalsem Oct 17, 2014

Member

We never use https over logon only. Only full https. Using it only on login is just solving it for a single page. There are more pages, like change password, or settings that could benefit from SSL to protect your credentials.

So i agree with Evan to remove this.

Member

jdalsem commented Oct 17, 2014

We never use https over logon only. Only full https. Using it only on login is just solving it for a single page. There are more pages, like change password, or settings that could benefit from SSL to protect your credentials.

So i agree with Evan to remove this.

@beck24

This comment has been minimized.

Show comment
Hide comment
@beck24

beck24 Oct 17, 2014

Member

+1

On Fri, Oct 17, 2014 at 6:32 AM, Jeroen Dalsem notifications@github.com
wrote:

We never use https over logon only. Only full https. Using it only on
login is just solving it for a single page. There are more pages, like
change password, or settings that could benefit from SSL to protect your
credentials.

So i agree with Evan to remove this.


Reply to this email directly or view it on GitHub
#5729 (comment).

Matt Beckett
Clever Name Web Design
1-888-579-2224
Direct Line: (250) 667-0871

Member

beck24 commented Oct 17, 2014

+1

On Fri, Oct 17, 2014 at 6:32 AM, Jeroen Dalsem notifications@github.com
wrote:

We never use https over logon only. Only full https. Using it only on
login is just solving it for a single page. There are more pages, like
change password, or settings that could benefit from SSL to protect your
credentials.

So i agree with Evan to remove this.


Reply to this email directly or view it on GitHub
#5729 (comment).

Matt Beckett
Clever Name Web Design
1-888-579-2224
Direct Line: (250) 667-0871

@ewinslow ewinslow changed the title from Encourage full https more strongly to Drop login-over-https feature Oct 17, 2014

@jdalsem

This comment has been minimized.

Show comment
Hide comment
@jdalsem

jdalsem Oct 20, 2014

Member

This could also fix #866

Member

jdalsem commented Oct 20, 2014

This could also fix #866

@jdalsem

This comment has been minimized.

Show comment
Hide comment
@jdalsem

jdalsem Dec 4, 2014

Member

related #6273

Member

jdalsem commented Dec 4, 2014

related #6273

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow May 17, 2015

Member

2.0 seems like a good time to lose this feature. Doing so encourages security, speed (http2, service worker), and simplicity for us.

Member

ewinslow commented May 17, 2015

2.0 seems like a good time to lose this feature. Doing so encourages security, speed (http2, service worker), and simplicity for us.

@ewinslow ewinslow added this to the Elgg 2.0.x milestone May 17, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue May 17, 2015

fix(https): Drop login-over-https
BREAKING CHANGE:
For the best security and performance, serve all pages over HTTPS
by switching the scheme in your site's wwwroot to `https` at
http://yoursite.tld/admin/settings/advanced

Fixes #5729

@mrclay mrclay closed this in #8318 May 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment