[
https://issues.apache.org/jira/browse/LUCENE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040508#comment-17040508
]
Uwe Schindler commented on LUCENE-9227:
---------------------------------------
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
