Stricter HTTPS #267
Stricter HTTPS #267
Conversation
|
Unfortunately we're not there yet. Many systems still are using outdated SSL libraries, often failing https connections. |
|
Users of such systems must be having an increasingly poor experience, as more and more content becomes inaccessible to them. I wonder if we're really doing them a favour by helping them keep their old insecure systems running. In any case, perhaps insecure HTTPS should be made optional? |
|
A huge number of LMS instances is running on NAS devices where the user has little to no control over the update status of the libraries. Optional sounds like a reasonable plan (though I hate to have one more pref...). Maybe a setting in Advanced/Security? Would you mind working on this? |
|
I have added the setting. |
|
@mherger: Did you have any remaining concerns about merging this? |
|
Now that I've started work on LMS 8 it's probably a good moment to give this a try. Please change PR to merge with public/8.0 instead of 7.9 (and update the changelogs accordingly - sorry!) |
Before this commit, we end up trying any failed connection twice, which takes twice as long. Since most failures have nothing to do with SNI, this seems excessinve.
- Many repository hosts (such as SourceForge or GitHub) will redirect to HTTPS if you try HTTP, and this will only become more common over time. - If the failure was nothing to do with HTTPS, we take twice as long with no benfit. - Falling back to HTTP undermines the purpose of HTTPS.
Setting VERIFY_NONE makes us vulnerable to man-in-the-middle attacks, and undermines the purpose of HTTPS.
|
I've rebased against |
|
Let's give this a try - thanks! |
For an explanation of the motivation of these changes, see the individual commits.
I expect that, nowadays, lax handing of TLS is no-longer needed; so many more things in the world require it, so any problems are likely to have been fixed.
I think it’s reasonable to merge this with a view to reverting it if it turns out to cause serious issues for nightly users.