Differences

This shows you the differences between two versions of the page.

--- tips:httpslogin [2015-12-01 11:45] – [30 Nov 15 - do] yarl
+++ tips:httpslogin [2018-09-29 11:31] (current) – [Apache] added example of a simple rule for https for all pages bruno.genere
@@ Line 5: / Line 5: @@
 See https://www.dokuwiki.org/plugin:forcessllogin, doesn't seem to reflect SSL access in URL, i.e. dokuwiki's access denied page won't be opened via https protocol which makes debugging and assuring that you're securely logging in difficult.
 =====Apache=====
 Using Apache's mod_rewrite, DokuWiki logins can be forced to use HTTPS, thus preventing clear text passwords on the wire.
-You may want to read up on [[:rewrite|general rewriting]] first.
+You may also need that all requests (and not only login) use HTTPS. To do so, create an .htaccess file in the root directory of DokuWiki and insert the following code.
+<code apache .htaccess>
+RewriteCond %{HTTPS} !on
+RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L]
+</code>
+If you only want to force some specific URL, read up [[:rewrite|URL rewriting]] first.
 Redirection to a secured connection which is restricted to a certain set of pages (e.g. login pages) requires their recognition based on the URL. Some pages (e.g. "access denied" pages which might be included only in newer versions, e.g. 2014-05-05 "Ponder Stibbons" <ref>https://www.dokuwiki.org/plugin:ondeniedlogin</ref>) don't include such a mark and cannot be distungished from the rest of URLs (which one might want to be accessed without a secure connection in order to save server resources).
@@ Line 121: / Line 127: @@
 </code>
+Thanks.. That saved my day!
@@ Line 159: / Line 165: @@
 ==== 30 Nov 15 - do ====
-Over HTTP, not logged on a inexistant page if you try to view source(do=edit), you'll "do=login" implicitly, over HTTP.
+Over HTTP, not logged on a inexistent page if you try to view source(do=edit), you'll "do=login" implicitly, over HTTP.
-I suggest to switch to https on "do=(login|admin|profile|edit)".
+I suggest to switch to https on "do=(login|admin|profile|edit)".\\
-Also, I'm not sure that this configuration really **needs** secure cookie disabled. Actually, steal a cookie is as easy as steal a cleartext password. Ok, it doesn't last as long but..
+Also, I'm not sure that this configuration really **needs** secure cookie disabled, it needs it **enabled** to me. Actually, steal a cookie is as easy as steal a cleartext password. Ok, it doesn't last as long, and isn't as powerful (or is it)..\\
+Switching back to http, you loose session : abilities to edit, config etc, what's wrong with this? Doing such an action puts you back to https, the cookie is send and you retrieve your session. Maybe some other actions need to switch to https then like media things, etc, I don't know.\\
+These are just suggestions, I do not master neither dokuwiki nor http(s)(server or protocol).
+==== 16 Feb 2016 - Use TLS all the time ====
+We should amend this tip to recommend using TLS for all connections.  Per the "30 Nov 15 - do" comment above, if you send the cookie insecurely for an active session, then it can be trivially stolen as the cookie going across the wire in the clear.  [[https://en.wikipedia.org/wiki/Firesheep|Firesheep]] makes this task automated and trivial to execute.  Further, [[https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Transport_Layer_Security|OWASP]] best practices are to run all secure all the time. Finally, we should recommend the 443 vhost send the [[https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security|HTTP Strict Transport Security (HSTS)]] header too.  This is done with a single line in the 443 vhost (for Apache in this example):
+<code>Header always set Strict-Transport-Security "max-age=63072000; preload"</code>
+One step further would be to strongly recommend that TLS be configured by default.  Though this makes the install more technically challenging, having a default setup of sending login credentials in the clear is a bad idea.