Login form SSL is confusing

[Denis-de-Bernardy]

With ssl_admin off, and ssl_login on, the login form sends a secure POST request. But end-users can be confused into thinking that they're about to send a non-secure post unless they view the page's source code.

The attached patch enforces SSL on the form as well, to avoid this confusion.

Brought this up in IRC, and it gets +1 from Viper007Bond and DD32 as well.

[Denis-de-Bernardy]

mm, needs a bit more work, actually. it ends up returning the dashboard in ssl when logging in.

[Denis-de-Bernardy]

the issue is this, in site_url:

$scheme = ( is_ssl() ? 'https' : 'http' );

the entire check might need to look like the following:

if ( 'login_post' == $scheme )
	$scheme = ( force_ssl_login() || force_ssl_admin() ) ? 'https' : 'http';
elseif ( 'login' == $scheme )
	$scheme = ( force_ssl_login() || force_ssl_admin() ) ? 'https' : 'http';
elseif ( ('admin' == $scheme) )
	$scheme = force_ssl_admin() ? 'https' : 'http';
else
	$scheme = is_ssl() ? 'https' : 'http';

but we might then end up needing an extra scheme for #10268 and the likes of #10253.

[Denis-de-Bernardy]

see also #9008

[ryan]

The current behavior is on purpose and patterned after gmail where you have the option of using SSL or not by using either https or http. If we redirect logins to https the user will end up dumped in an SSL admin session after login even though they requested http. I think if someone is concerned with this they should just force ssl admin.

[Denis-de-Bernardy]

well, I figured the same, but ssl is a tad bit slow (a lot slower even)...

[willnorris]

I agree with ryan's point that if this is the desired behavior, then you should set FORCE_SSL_ADMIN. Google has ​published research about the actual CPU, memory, and network overhead that SSL introduces, and it's really not an issue with modern servers. I'm sure the numbers are even lower now, since this research is three years old.

closing as wontfix... feel free to reopen if you still believe this is an issue.

[willnorris]

after talking with @nacin tonight, he pointed out that this is more than just confusing, it has some actual security implications. It's part of a handful of similar bugs that are slated to get fixed in 3.7, so reopening.

[johnbillion]

#22283 was marked as a duplicate.

[johnbillion]

No patch and needs some more discussion. Also see discussion on #22283. We should try to get this into 3.8.

[Denis-de-Bernardy]

Replying to willnorris:

after talking with @nacin tonight, he pointed out that this is more than just confusing, it has some actual security implications. It's part of a handful of similar bugs that are slated to get fixed in 3.7, so reopening.

Along similar lines, there's #10268.

[samuelsidler]

Still no patch, not going to make 3.8.

[nacin]

Time to retire login SSL. Admin or GTFO. Upcoming commit forces SSL in the admin if you had FORCE_SSL_LOGIN set.

The alternative is to let it rot / discourage its use / issue a deprecation notice. But if someone wants FORCE_SSL_LOGIN they probably care about security more than the potential for trouble. The current security is smoke and mirrors, while a lot of that trouble (like mixed content issues) do plan to be fixed in 4.0.

[nacin]

In 28609:

Forcing SSL logins now forces SSL for the entire admin, with no middle ground.

fixes #10267.

[iandunn]

I ran into a problem after updating an MU installation to 4.0-beta1. I'm not sure how common the site's configuration is, or if it's even considered a supported use case, but I figured I'd mention it just to be safe.

Configuration:

• Main site does have an SSL certificate
• Sub-sites do not have SSL certificates
• wp-config.php enables FORCE_SSL_LOGIN
• Logging in on the sub-sites is redirected to the main site ​via an mu-plugin

r28609 causes two problems with this setup:

1. wp-login.php redirects the user to the sub-site's HTTPS login URL, and their browser shows them a certificate error.
2. The auth cookie scheme changes from auth to secure_auth, and the user gets stuck in a loop when they login.

The step-by-step process looks like this:

• User attempts to visit ​http://sub-site.example.org/wp-admin
• User is redirected to ​https://sub-site.example.org/wp-admin, and their browser displays a warning because there isn't a valid certificate
• If they proceed anyway, they're redirected to ​https://example.org/wp-login.php
• User submits correct username/password, is given secure auth cookies and redirected to ​http://sub-site.example.org/wp-admin
• Cookies aren't valid for ​http://sub-site.example.org/wp-admin because they're secure_auth instead of auth
• User is redirected back to ​https://example.org/wp-login.php and is stuck in a loop

If backwards compatibility isn't going to be maintained in this case, then the problems can be fixed on the site's end by making these adjustments:

1. Redirecting to ​https://sub-site.example.org/wp-admin can be avoided by disabling FORCE_SSL_LOGIN on the sub-sites. This is really how it should have been configured all along, but before r28609 there wasn't any obvious consequence to setting it incorrectly.

if ( 'example.org' == $_SERVER['HTTP_HOST'] ) {
        define( 'FORCE_SSL_LOGIN', true );
} else {
        define( 'FORCE_SSL_LOGIN', false );
}

2. The login redirection loop can be avoided by using the auth scheme when redirecting to a site without a certificate:

if ( ! empty( $_REQUEST['redirect_to'] ) && 'http://' == substr( urldecode( $_REQUEST['redirect_to'] ), 0, 7 ) ) {
        add_filter( 'secure_signon_cookie',    '__return_false' );
        add_filter( 'secure_auth_cookie',      '__return_false' );
        add_filter( 'secure_logged_in_cookie', '__return_false' );
}

[jeremyfelt]

It looks like ​https://wordpress.org/plugins/ssl-subdomain-for-multisite/ does something similar. Not sure if that's likely to be used on many installations. In my multi-network configuration I set FORCE_SSL_LOGIN and FORCE_SSL_ADMIN in sunrise for domains that are deemed SSL ready, similar to iandunn's example (1) above. This works really well, though I don't rely on a global auth point. It also haunts me whenever a domain lives in un-SSL-ready territory for more than a few hours. :)

I think nacin sums it up in comment:20. Providing SSL login without SSL admin areas is a false sense of security.

[DrewAPicture]

Closing as fixed after [28609].