Difference between revisions of "HTTPS-only and HSTS"

From EPrints Documentation
Jump to: navigation, search
(→‎Add 301 redirects to secure port from HTTP (port 80))
m (→‎Add the HSTS header)
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
{{manual}}
 +
 
[[Category:Authentication]]
 
[[Category:Authentication]]
  
 
== HTTPS with EPrints ==
 
== HTTPS with EPrints ==
  
−
See the following page for [[How_to_use_EPrints_with_HTTPS]]. 
+
See the pages in [[:Category:Authentication|Category Authentication]] for how to setup up HTTPS on EPrints, for example:
  
−
This page describes how to configure EPrints so that all content, not just login pages, is served over HTTPS.
+
*[[How_to_use_EPrints_with_HTTPS|How to use EPrints with HTTPS]]
 +
*[[Setting_up_HTTPS_using_Let%27s_Encrypt|Setting up HTTPS using Let's Encrypt]]
 +
 
 +
The following is a description of how to configure EPrints so that all content, not just login pages, is served over HTTPS.
  
 
== Google Best Practices for HTTPS==
 
== Google Best Practices for HTTPS==
  
−
That following are the best practice specified by Google (https://support.google.com/webmasters/answer/6073543?hl=en&ref_topic=6001951)
+
The following are the best practices specified by [https://support.google.com/webmasters/answer/6073543?hl=en&ref_topic=6001951 Google]
  
 
* HSTS Headers on HTTPS
 
* HSTS Headers on HTTPS
Line 18: Line 23:
 
== HSTS ==
 
== HSTS ==
  
−
To summarize how HSTS works, if a browser (Chrome, Firefix, IE) sees the HSTS header in the HTTPS response, and there are no certificate errors or mixed content warnings or anything (if it is green), then the next time a user of that browser requests the HTTP page of that site, the browser will modify the request to a HTTPS request and will not issue the HTTP request.  The browser will remember that setting for as long as you specify “max-age” to be.  This means that even with HSTS, it is still possible to request and receive content over HTTP.  To close that down, a server redirect is necessary, so those browsers that haven’t seen the HSTS header in the past that happen to try to go to HTTP will get that initial redirect to HTTPS.
+
To summarize how HSTS works, if a browser (Chrome, Firefix, IE) sees the HSTS header in the HTTPS response, and there are no certificate errors or mixed content warnings or anything (if it is green), then the next time a user of that browser requests the HTTP page of that site, the browser will modify the request from an HTTP to a HTTPS request.  The browser will remember that setting for as long as you specify <tt>max-age</tt> to be.  This means that even with HSTS, it is still possible to request and receive content over HTTP.  To close that down, a server redirect is necessary, so those browsers that haven’t seen the HSTS header in the past that happen to try to go to HTTP will get that initial redirect to HTTPS.
  
 
== Implementing HTTPS-only with HSTS on an EPrints repository ==
 
== Implementing HTTPS-only with HSTS on an EPrints repository ==
  
−
=== Changes to /cfg.d/10_core.pl ===
+
=== Changes to archive's cfg.d/10_core.pl ===
 +
 
 +
Initialize the following variables to be the https URL (i.e., https://<nowiki>YOUR-REPOSITORY-DOMAIN</nowiki>)
  
−
Initialize the following variables to be the https URL (i.e., https://YOUR-REPOSITORY-DOMAIN)
 
 
<source lang="perl">
 
<source lang="perl">
 
  $c->{host} = "YOUR-REPOSITORY-DOMAIN";  
 
  $c->{host} = "YOUR-REPOSITORY-DOMAIN";  
Line 32: Line 38:
 
</source>
 
</source>
  
−
=== Changes to /cfg/lang/en/templates/default.xml, and /cfg/lang/en/static .XPAGE files ===
+
=== Changes to archive's <tt>cfg/lang/LANGID/templates/default.xml</tt>, and <tt>/cfg/lang/LANGID/static/*.XPAGE</tt> files ===
  
−
Remove any hard coded links to HTTP
+
* Remove any hard coded links to HTTP
−
If you have Google Search included as an XPAGE file, call on the Google API (and any other APIs) using HTTPS.
+
* If you have Google Search included as an XPAGE file, call on the Google API (and any other APIs) using HTTPS.
  
−
=== Changes to apache conf files ===
+
=== Changes to Apache config files ===
  
 
==== Add the HSTS header ====
 
==== Add the HSTS header ====
  
−
Add a new include apache-ssl CONF file to the folder /REPOID/cfg/ that has the HSTS header.  The max-age variable is a time in seconds for how long the HSTS settings should be remembered by the browser.  15780000 is six months, which is a long time, you may want to set it to a shorter time while testing.
+
Edit [[Template:Securevhost.conf|EPRINTS_PATH/archives/REPOID/ssl/securevhost.conf]] and add the following HSTS header after ther <tt>ServerName</tt> line.  The max-age variable is a time in seconds for how long the HSTS settings should be remembered by the browser.  15780000 is six months, which is a long time, you may want to set it to a shorter time while testing.
  
 +
<syntaxhighlight lang="apache">
 
  Header set Strict-Transport-Security "max-age=15780000"
 
  Header set Strict-Transport-Security "max-age=15780000"
 +
</syntaxhighlight>
  
−
Include this file from the core apache conf file for the secure port (443) in /etc/
+
Include this file from the core apache conf file for the secure port (443) in <tt>/etc/</tt>
−
 
 
−
A new file is required because [[API:bin/generate apacheconf]] overwrites any of the conf files that were already being included.
 
  
 
==== Add 301 redirects to secure port from HTTP (port 80) ====
 
==== Add 301 redirects to secure port from HTTP (port 80) ====
  
−
The generate_apacheconf would ideally have some new flags, something like “--sslonly” and “--hsts” , which would generate the correct apache config files for a repository that follows the Google best practice of HTTPS-only with HSTS, but it does not. Thus, one way to introduce the redirect is to overwrite one of the files that are generated by /bin/generate_apacheconf, /cfg/apache/REPOID.conf.  This means that you will have to re-apply this redirect (by overwriting the conf file again with the redirect) if/when you need to re-run generate_apacheconf.
+
By making the above changes to the archive's <tt>cfg.d/10_core.pl</tt>, if you use [https://github.com/eprints/eprints/commit/c29574dbdcd49c67f3aea522998960f2eb19f544 this patch] or are running [https://github.com/eprints/eprints the latest revision of EPrints on GitHub], <tt>/bin/generate_apacheconf</tt> will generate an <tt>/cfg/apache/REPOID.conf</tt>, which automatically redirects HTTP to HTTPS. Otherwise, this can be achieved by modifying <tt>/cfg/apache/REPOID.conf</tt> to the following, substituting your domain as appropriate:
−
 
 
−
Modify the default port 80 response of Apache to redirect to the secure port, by modifying /cfg/apache/REPOID.conf to:
 
  
−
<source language="xml">
+
<source lang="xml">
 
<VirtualHost *:80>
 
<VirtualHost *:80>
 
RedirectPermanent / https://YOUR-REPOSITORY-DOMAIN/   
 
RedirectPermanent / https://YOUR-REPOSITORY-DOMAIN/   
 
</VirtualHost>
 
</VirtualHost>
 
</source>
 
</source>

Latest revision as of 11:06, 21 May 2021

Manual Sections

HTTPS with EPrints

See the pages in Category Authentication for how to setup up HTTPS on EPrints, for example:

The following is a description of how to configure EPrints so that all content, not just login pages, is served over HTTPS.

Google Best Practices for HTTPS

The following are the best practices specified by Google

  • HSTS Headers on HTTPS
  • No “Mixed Content” warnings/errors
  • Links point to HTTPS locations
  • 301 Redirects from HTTP to HTTPS

HSTS

To summarize how HSTS works, if a browser (Chrome, Firefix, IE) sees the HSTS header in the HTTPS response, and there are no certificate errors or mixed content warnings or anything (if it is green), then the next time a user of that browser requests the HTTP page of that site, the browser will modify the request from an HTTP to a HTTPS request. The browser will remember that setting for as long as you specify max-age to be. This means that even with HSTS, it is still possible to request and receive content over HTTP. To close that down, a server redirect is necessary, so those browsers that haven’t seen the HSTS header in the past that happen to try to go to HTTP will get that initial redirect to HTTPS.

Implementing HTTPS-only with HSTS on an EPrints repository

Changes to archive's cfg.d/10_core.pl

Initialize the following variables to be the https URL (i.e., https://YOUR-REPOSITORY-DOMAIN) 

 $c->{host} = "YOUR-REPOSITORY-DOMAIN"; 
 $c->{http_url} = 'https://YOUR-REPOSITORY-DOMAIN';
 $c->{http_cgiurl} = 'https://YOUR-REPOSITORY-DOMAIN/cgi';
 $c->{base_url} = "https://$c->{host}";

Changes to archive's cfg/lang/LANGID/templates/default.xml, and /cfg/lang/LANGID/static/*.XPAGE files

  • Remove any hard coded links to HTTP
  • If you have Google Search included as an XPAGE file, call on the Google API (and any other APIs) using HTTPS.

Changes to Apache config files

Add the HSTS header

Edit EPRINTS_PATH/archives/REPOID/ssl/securevhost.conf and add the following HSTS header after ther ServerName line. The max-age variable is a time in seconds for how long the HSTS settings should be remembered by the browser. 15780000 is six months, which is a long time, you may want to set it to a shorter time while testing. 

 Header set Strict-Transport-Security "max-age=15780000"

Include this file from the core apache conf file for the secure port (443) in /etc/

Add 301 redirects to secure port from HTTP (port 80)

By making the above changes to the archive's cfg.d/10_core.pl, if you use this patch or are running the latest revision of EPrints on GitHub, /bin/generate_apacheconf will generate an /cfg/apache/REPOID.conf, which automatically redirects HTTP to HTTPS. Otherwise, this can be achieved by modifying /cfg/apache/REPOID.conf to the following, substituting your domain as appropriate: 

<VirtualHost *:80>
RedirectPermanent / https://YOUR-REPOSITORY-DOMAIN/  
</VirtualHost>
Retrieved from ‘https://wiki.eprints.org/w/index.php?title=HTTPS-only_and_HSTS&oldid=13783’