Splitting this off into a separate issue as a followup from both:

#1577: Mapping privilege separation on non-SSL/SSL

#607008: Fix bugs in https support and force using https for authorize.php if available

We're now exceptionally close to having Drupal more secure by using https for important things when available. Sadly, all the plumbing is in place (or getting fixed), but we stopped short of the checkbox to actually protect the login forms. :( I can't believe we're going to go another major release relying on contrib to solve what is so obviously a core problem.

A) At the very least we need a checkbox somewhere that sets $form['#https'] = TRUE for all login forms (user_login, user_login_block, etc).

B) We should consider a setting for making all POST actions secure.

C) We should have a setting for making all of admin/* secure.

D) We should have a text area for other URLs to make secure, which supports wildcards (like the block visibility text areas).

E) We should have a little AJAX magic in install.php to test if https works, and if so, to default (A) to TRUE, and set this slightly weird global variable 'https' to TRUE so that everything else works.

Given that Update manager is prompting you for your SSH password over http unless we give people a way to turn this on, I'm calling this a release-blocking critical task...

Comments

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Issue tags: +Security improvements, +Update manager

Adding a few more relevant tags...

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Assigned: Unassigned » Dave Reid
mfb’s picture

mfb
they or he
CreditAttribution: mfb commented

subscribing

xmacinfo’s picture

xmacinfo
he/him
Primary language French
Location Canada
CreditAttribution: xmacinfo commented

I'd love to see all of this. But given the timeframe, how about doing only A)?

yoroy’s picture

yoroy CreditAttribution: yoroy commented

I'd love to see all of this. But given the timeframe, how about doing only A)? ;-)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Version: 7.x-dev » 8.x-dev

No one worked on this prior to alpha 1. Better luck next release, I guess. :(

YK85’s picture

YK85 CreditAttribution: YK85 commented

Hello,
I was wondering if Secure Pages module (http://drupal.org/project/securepages) will be needed in Drupal 7 with this feature in core? Or will it need to be ported as the UI is being developed in D8?
Thanks!

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

I'm pretty sure either "8.x" or "Release blocker" are wrong for this issue?!

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Issue tags: -Release blocker

*sigh*

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented

Next year in Jerusalem, I guess. Tracking.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Assigned: Dave Reid » Unassigned
catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Priority: Critical » Major

Downgrading all D8 criticals to major per http://drupal.org/node/45111

Tebb’s picture

Tebb CreditAttribution: Tebb commented

Following.

yoroy’s picture

yoroy CreditAttribution: yoroy commented

I looked around in admin for a sensible place. If there would be more security-related options than a single checkbox it could have its own 'Security' section in the 'System' category. Without adding a new category, "admin/config/system/site-information" looks like the least crappy option. Thoughts?

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Category: task » feature

Sounds like a feature request to me. Major "tasks" are now preventing adding new features to Drupal core per the new policy at http://drupal.org/node/1201874. There are a lot of other worthy features out there that can't move forward while we're over our threshold.

mfb’s picture

mfb
they or he
CreditAttribution: mfb commented

I'm also not sure this is even "major" priority. I'd suggest further improvements to the API before moving on to the UI.

Cases in point: Secure pages module doesn't have a stable Drupal 7 release yet due to core bugs, and Secure login module had to re-implement the core API with $conf['https'] at its default value (FALSE) so as to avoid this setting's mandatory creation of insecure authenticated sessions when users login securely.

$conf['https'] could be renamed to $conf['https_session_insecure'] or something, as it's really not needed or wanted by all HTTPS sites, even those that do have both HTTP and HTTPS sites (the use case for $conf['https'] = FALSE is sites that support anonymous sessions on the HTTP site but require all authenticated sessions to use the HTTPS site).

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
CreditAttribution: jhedstrom commented
Issue summary: View changes
Status: Active » Closed (won't fix)

I think this is now "won't fix" based on #2342593: Remove mixed SSL support from core.

mfb’s picture

mfb
they or he
CreditAttribution: mfb commented

FYI Secure login module for Drupal 8 is pretty much ready for release. As in Drupal 7, by default it secures all user-related forms (e.g. login forms), provides a UI to secure arbitrary other forms, and by default redirects all pages containing secure forms to the HTTPS site.