[jira] [Comment Edited] (LUCENE-9227) Make page ready for pure HTTPS

["Uwe Schindler (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040508#comment-17040508 ] 

Uwe Schindler edited comment on LUCENE-9227 at 2/19/20 11:22 PM:
-----------------------------------------------------------------

Hi,

thanks for the quick answer. I was hoping that you can just install LetsEncrypt on the server to make it encrypted. To me it looks like the service is no longer fully maintained, so maybe you just have no time to take care of it.

The problem is as we want to switch the Lucene webpage to fully be HTTPS (like most websites nowadays), anybody who selects the LucidFind option would get a security warning in Firefox Browsers and a warning in Chrome after a query is entered. Currently the search engine is randomly preselected. I'd remove the randomization and just keep the OSC one the default. People who select the LucidFind one would get a security warning, but they have to explicitly select it.

Regarding GDPR: The discussion about sending "user entered" form data using unencrypted form submission is still is a hot issue in the EU. Contact forms have to be encrypted (if you don't do that you quickly get sued by competitors); but with other forms like search forms, lawyers are still discussing. But on the other hand a website that uses HTTPS with HSTS headers (to teach browser to switch to HTTPS forever) then sending user data unencrypted over the wire is a bit strange.

So I would for now set the default without randomness to OSC and yours is only used if explicitely selected.

After that I would proceed with enabling HTTPS Perm Redirect and starting with a HSTS header of short lifetime (1 hours). If all wents fine, I will raise the HSTS header to 30 days. If still we get no complaints, I will change it to one year (the default recommended). After that every browser will keep the information that lucene.apache.org has to be accessed encrypted (this is important to prevent anybody to intercept the connection while it was not upgraded to HTTPS yet). So everything except very first access is then secured. Users coming back later will always use HTTPS automatically without explicitely entering the full URL with HTTPS.

Any comments? If anybody has another Lucene-Centric search (e.g. [~mikemccand] Lucene Search) speak up, we can include it into the search box.

I'd proceed with this on the weekend, implementing HTTPS with increasing HSTS header lifetimes as described before.


was (Author: thetaphi):
Hi,

thanks for the quick answer. I was hoping that you can just install LetsEncrypt on the server to make it encrypted. To me it looks like the service is no longer fully maintained, so maybe you just have no time to take care of it.

The problem is as we want to switch the Lucene webpage to fully be HTTPS (like most websites nowadays), anybody who selects the LucidFind option would get a security warning in Firefox Browsers and a warnings in Chrome if a query is entered. Currently the serach engine is randomly preselected. I'd remove the randomization and just keep the OSC one the default. People who select the LucidFind one would get a security warning, but they have to explicitly select it.

Regarding GDPR: The discussion about sending "user entered" using unencrypted form submission is still is a hot issue in the EU. Contact forms have to be encrypted (if you don't do that you quickly get sued by competitors); but with other forms like search forms, lawyers are still discussing. But on the other hand a website that uses HTTPS with HSTS headers (to teach browser to switch to HTTPS forever) then sending user data unencrypted over the wire is a bit strange.

So I would for now set the default without randomness to OSC and yours is only used if explicitely selected.

After that I would proceed with enabling HTTPS Perm Redirect and starting with a HSTS header of short lifetime (1 hours). If all wents fine I will raise the HSTS header to 30 days. If still we get no complaints I will change it to one year (the default recommended). After that every browser will keep the information that lucene.apache.org has to be accessed encrypted (this is important to prevent anybody to intercept the connection while it was not upgraded to HTTPS yet). So everything except first acces is then secured. Users coming back later will always use HTTPS also without explicitely entering the full URL with HTTPS.

Any comments? If anybody has another Lucene-Centric search (e.g. [~mikemccand] Lucene Search) speak up, we can include it into the search box.

I'd proceed with this on the weekend, implementing HTTPS with increaing HSTS headers as described before.

> Make page ready for pure HTTPS
> ------------------------------
>
>                 Key: LUCENE-9227
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9227
>             Project: Lucene - Core
>          Issue Type: Sub-task
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>            Priority: Blocker
>
> The web page can currently be visited using HTTPS but this brings warning:
> - Both search providers create a form that passes USER ENTERED INPUT using no encryption. This is not allowed due to GDPR. We have to fix this asap. It looks like [~otis] search is working with HTTPS (if we change domain name), but the Lucidworks does not
> - There were some CSS files loaded with HTTP (fonts from Google - this was fixed)
> Once those 2 problems are fixed (I grepped for HTTP and still found many links with HTTP, but looks like no images or scripts or css anymore), I'd like to add a permanent redirect http://lucene.apache.org/ -> https://lucene.apache.org to the htaccess template file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org