Products.cmfplone: PLIP: Be able to require SSL

[tkimnguyen]

Proposer : Kim Nguyen

Seconder: Nathan Van Gheem

Abstract

Friends don't let friends run public sites without SSL!

This implementation would provide a new configuration field in the Security control panel to control forcing SSL urls.

The config option would be a dropdown with 3 options.

Force SSL:

• No
• Forms
• Full

When "Forms" selected, POST form requests would be rewritten to be SSL.

When "Full" selected, all traffic would be forced to be SSL.

These settings would NOT apply to access to the site directly on a port(if you're port forwarding or managing from the zope root).

Motivation

Security. Easily for users to force SSL on the application than them having to implement proxy rules.

Assumptions

Proposal & Implementation

The new configuration field will be provided in Products.CMFPlone.

The implementation of these settings will be done in the plone.protect package. "Full" mode would do a redirect to SSL. "Forms" would rewrite POST form requests to SSL actions.

Deliverables

Tested PRs for Products.CMFPlone and plone.protect.

Risks

Low risk but there is potential for users to lock themselves out of their site if they don't actually have SSL enabled.

[vangheem]

Could be part of plone.protect implementation since we already do _authenticator token magic there.

[gforcada]

:+1:

[tisto]

@vangheem please use the "5.1" milestone instead of the "5.1" label.

[vangheem]

Of course, thanks.

[tkimnguyen]

As part of this, it would be great to show a hint like a lock icon to reassure the user that the login form (and login portlet) is secured with SSL (I don't know if there are other POSTs this would apply to as well)., e.g. in https://github.com/uwosh/uwosh.securelogin/blob/master/uwosh/securelogin/skins/uwosh_securelogin_custom_templates/login_form.cpt#L219 and https://github.com/uwosh/uwosh.secureloginportlet/blob/master/uwosh/secureloginportlet/secureloginportlet/secureloginportlet.pt#L104

[jensens]

@tkimnguyen @vangheem this one is an old one. It is information complete and ready for voting. Are still you planning to implement this? If yes we will add this to our voting process at next FWT meeting.

[tomgross]

What's the benefit of this?
IMO This just adds complexity with a limited outcome. I think most people use a webserver like httpd or nginx in front of Plone anyways where SSL can be configured easily (Letsencrypt!)
It reminds me on the gzip flag of plone.app.caching which was removed later.

[Rudd-O]

URLs generated by Plone depend on the frontend's request and, to my understanding, if the frontend receives an SSL request, when Plone responds to it, the response makes sure that all links work properly over SSL as well (primarily by not mandating a protocol on the links in the response content themselves).

HTTP header configuration is usually something that is taken care of by the frontend because Plone has no such affordance. This PLIP also doesn't propose a mechanism to control HSTS anyway.

I think this should be left to the frontend, with (perhaps) a very limited builtin implementation of SSL that uses self-signed certs for developer purposes, in anticipation of the upcoming browser switch to consider HTTP an insecure protocol..

[tkimnguyen]

It's happened enough to me to find myself logging into a site then realizing it wasn't using HTTPS. It could be that at some point most browsers warn about this, but in the meantime I think it serves our "most secure CMS" brand to ensure that we are covering all the bases in our default install.

[hvelarde]

this is interesting; I didn't knew Zope supported HTTPS OOTB…

[tomgross]

I'd rather invest the energy in make Plone happen on WSGI (which is probably the default of Zope 4 anyways) and delegate this issue to the webserver or some middleware.

[jensens]

@tkimnguyen @vangheem the @plone/framework-team needs more information on the implementation details

[seanupton]

Some thoughts:

(1) Forced redirect for login form and disabling login form over http is reasonable, but complex. This can only be done in login form (page or portlet). You cannot prevent the unencrypted POST before sensitive stuff goes over the wire -- not simply or reliably.

(2) You really need to tell users in the UI what you are doing if you are doing part HTTPS instead of HTTPS everywhere: "We use HTTPS encrypted connections for all logins".

(3) You need to be able to have forms redirect back to the unencrypted site, which is complex and view-specific unless passing redirect target (e.g. came_from) in every POST request and intercepting that in a post-traversal hook.

_The complexity of UX and implementation detail means this needs careful consideration._

Simpler alternatives?

• Promoting best practices, in software: It might be simpler to have an opt-in item ship a "Strict transport security" emblem (make an SVG icon of a lock superimposed on a sledgehammer) on a site which has such headers. A JS pattern could be written using an XMLHttpRequest.getAllResponseHeaders(), and display of these "pat yourself on the back" emblems could be wrapped in a footer viewlet.
• Warning notice (in notification area) on login form and any HTML form, including portlet, (via JS) that has a password-typed input, where window.location.protocol !== 'https:'

[tisto]

Last activity in 2016. Time to close this PLIP?