Re: Making www.cpan.org TLS-only
> On Sep 5, 2017, at 11:22 , Leo Lapworth wrote: > > Would (at least for the short term) just adding the HSTS header to every > request be the best solution? Then browsers get told to switch to secure and > other clients can do either. HSTS only works on TLS requests, so you have to get the browser to use that first and then it’ll pay attention to the header (and use TLS across all requests). Ask
Re: Making www.cpan.org TLS-only
On 5 September 2017 at 09:31, Leon Timmermans wrote: > On Tue, Sep 5, 2017 at 6:34 AM, Ask Bjørn Hansen wrote: > >> > Among things that should allow non-TLS: I would include /src/. Also >> the top-level RECENT files, things in /indices/. >> >> +1. >> >> Maybe it makes more sense to reverse the logic and just targeting >> whatever the most popular[1] web pages for browsers and count on HSTS >> having the browsers sort it out; basically an expanded version of what we >> did now with just the home page. > > I see a comment about something having broken cpanminus when someone doesn't have LWP::Protocol::https installed: http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html#comment-form Would (at least for the short term) just adding the HSTS header to every request be the best solution? Then browsers get told to switch to secure and other clients can do either. n.b versions of Opera has some issues with TLS 1.2 not being enabled and getting disabled again https://github.com/metacpan/metacpan-web/issues/1967 Thanks Leo
Re: Making www.cpan.org TLS-only
On Tue, Sep 5, 2017 at 6:34 AM, Ask Bjørn Hansen wrote: > > Among things that should allow non-TLS: I would include /src/. Also the > top-level RECENT files, things in /indices/. > > +1. > > Maybe it makes more sense to reverse the logic and just targeting whatever > the most popular[1] web pages for browsers and count on HSTS having the > browsers sort it out; basically an expanded version of what we did now with > just the home page. That sounds like a more sensible approach to me. Leon
Re: Making www.cpan.org TLS-only
> On Sep 4, 2017, at 11:20, David Golden wrote: > > Are those "OR" conditions? "*.html" OR not in /authors/, etc/? Yeah, that was the idea. Basically make “things a web browser typically visits” have forced TLS (because humans), but have it be optional for things computers typically use. Hopefully that’d encourage use of TLS without breaking too many old tools/systems. > Among things that should allow non-TLS: I would include /src/. Also the > top-level RECENT files, things in /indices/. +1. Maybe it makes more sense to reverse the logic and just targeting whatever the most popular[1] web pages for browsers and count on HSTS having the browsers sort it out; basically an expanded version of what we did now with just the home page. Ask [1] Not that we have logs, but we could figure out to collect those for a little while.
Re: Making www.cpan.org TLS-only
On Thu, Aug 31, 2017 at 9:10 PM, Ask Bjørn Hansen wrote: > Hi everyone, > > We’re considering how/how-much we can make www.cpan.org TLS-only. > http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html > > I expect that we can’t make the whole site TLS-only without breaking some > CPAN clients, so the conservative version is to force TLS for > > - any url ending in *.html > - any url not in matching some variation of > (/authors/ | /MIRRORED.BY | ^/modules/[^/]+ ) > > Does that sound about right? Maybe /src/, too? > > > Are those "OR" conditions? "*.html" OR not in /authors/, etc/? Among things that should allow non-TLS: I would include /src/. Also the top-level RECENT files, things in /indices/. David -- David Golden Twitter/IRC/GitHub: @xdg
Re: Making www.cpan.org TLS-only
On Fri, Sep 01, 2017 at 12:48:02PM -0400, Olaf Alders wrote: > As an (interesting?) aside, the Net::HTTP test suite just broke because of > the 301 from http://www.cpan.org to https://www.cpan.org > https://github.com/libwww-perl/Net-HTTP/issues/53 Obviously that test made > some assumptions which no longer hold up. :) A fix has been released. I > just point it out as an unexpected side effect of making these sorts of > changes. It broke CPANdeps too, which needs to fetch 02packages.details.txt.gz, as you're using some SSL options that its openssl doesn't understand. The long-term fix is for me to upgrade the version of Debian that CPANdeps uses, but in the mean time can that be another file excluded from the re-directs please. -- David Cantrell | Pope | First Church of the Symmetrical Internet I apologize if I offended you personally, I intended to do it professionally. -- Steve Champeon, on the nanog list
Re: Making www.cpan.org TLS-only
On Aug 31, 2017, at 9:10 PM, Ask Bjørn Hansen wrote: > Hi everyone, > > We’re considering how/how-much we can make www.cpan.org TLS-only. > http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html > > I expect that we can’t make the whole site TLS-only without breaking some > CPAN clients, so the conservative version is to force TLS for > > - any url ending in *.html > - any url not in matching some variation of > (/authors/ | /MIRRORED.BY | ^/modules/[^/]+ ) > > Does that sound about right? Maybe /src/, too? > > (Also - we will support TLS for www.cpan.org permanently now, so please > update URLs where possible and appropriate). That file does not prevent someone from taking over the domain and modifying the files. Nor will it notice man-in-the-middle attacks. Without Any request without TLS has no proof of domain control. That, along with encryption, is the driving force behind the current “TLS for everything” movement. Best, David signature.asc Description: Message signed with OpenPGP
Re: Making www.cpan.org TLS-only
> On Sep 1, 2017, at 3:49 AM, Ask Bjørn Hansen wrote: > > The Google change was the impetus to get around to it. > > Clients should use TLS to request content. It limits the trust for > downloading CPAN content roughly to: > > - The author > - PAUSE system maintainers > - perl.org infrastructure maintainers > - Fastly > - Global CA infrastructure > > Without TLS you basically trust anyone with any sort of access to your > internet connection to not muck with the code you receive. > > Obviously the real fix here is that clients need to request via TLS (since I > doubt any clients other than regular browsers support HSTS). As an (interesting?) aside, the Net::HTTP test suite just broke because of the 301 from http://www.cpan.org to https://www.cpan.org https://github.com/libwww-perl/Net-HTTP/issues/53 Obviously that test made some assumptions which no longer hold up. :) A fix has been released. I just point it out as an unexpected side effect of making these sorts of changes. Olaf
Re: Making www.cpan.org TLS-only
> downloading CPAN content roughly to: > internet connection to not muck with the code you receive. > > Obviously the real fix here is that clients need to request via TLS (since I > doubt any clients other than regular browsers support HSTS). I was under the impression that any "code" ( eg: content submitted via pause ) had an existing, long standing additional cryptographic security on top of plain text, namely: - Per author CHECKSUM files - Which are signed by the PAUSE GPG key http://cpan.metacpan.org/authors/id/K/KE/KENTNL/CHECKSUMS And I've been using that feature via my CPAN client for years now. ( I notice occasionally when the checksum files are broken ) I'm fine with allowing there to be additional security mechanisms, its just *requiring* uses engage in security mechanisms when there's no *need* to nor *desire* to on the users behalf I consider potentially harmful. Is there other content coming from the CPAN network that I'm not considering here? -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: Making www.cpan.org TLS-only
The Google change was the impetus to get around to it. Clients should use TLS to request content. It limits the trust for downloading CPAN content roughly to: - The author - PAUSE system maintainers - perl.org infrastructure maintainers - Fastly - Global CA infrastructure Without TLS you basically trust anyone with any sort of access to your internet connection to not muck with the code you receive. Obviously the real fix here is that clients need to request via TLS (since I doubt any clients other than regular browsers support HSTS). Ask
Re: Making www.cpan.org TLS-only
On 1 September 2017 at 13:10, Ask Bjørn Hansen wrote: > Hi everyone, > > We’re considering how/how-much we can make www.cpan.org TLS-only. > http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html > > I expect that we can’t make the whole site TLS-only without breaking some > CPAN clients, so the conservative version is to force TLS for > > - any url ending in *.html > - any url not in matching some variation of > (/authors/ | /MIRRORED.BY | ^/modules/[^/]+ ) > > Does that sound about right? Maybe /src/, too? > > (Also - we will support TLS for www.cpan.org permanently now, so please > update URLs where possible and appropriate). > I'm just side-stepping the "what" momentarily to ascertain the "why". I know plain-text is "insecure", but its not clear currently from this proposal what content needs securing, and what the real vulnerabilities this aims to solve are. There probably are some, but it needs to be much more clear. Specifically, so we know the solution we pick fixes the problem we know is there, and so its obvious that the downsides of the chosen solution are necessary. As it stands, it *looks* like the argument is "we're going to do this because otherwise google might be more shouty". ( I assume it isn't, just from the context I have that's all I've got to go on, so I'm looking for additional context ) > Ask -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: Making www.cpan.org TLS-only
On Freitag, 1. September 2017 08:50:35 CEST Henk P. Penning wrote: >It sounds arbitrary :-) ; Exceptions cause confusion. >Is it too dangerous to just do it and fix what's broken ? >You can always revert quickly. If there have to be exceptions, basing them on the UserAgent would be more precise. Regards, Stefan
Re: Making www.cpan.org TLS-only
On Fri, 1 Sep 2017, Ask Bjørn Hansen wrote: Date: Fri, 1 Sep 2017 03:10:12 +0200 From: Ask Bjørn Hansen To: [email protected] Subject: Making www.cpan.org TLS-only Hi everyone, We’re considering how/how-much we can make www.cpan.org TLS-only. http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html I expect that we can’t make the whole site TLS-only without breaking some CPAN clients, so the conservative version is to force TLS for - any url ending in *.html - any url not in matching some variation of (/authors/ | /MIRRORED.BY | ^/modules/[^/]+ ) If you exclude /MIRRORED.BY, perhaps /indices/mirrors.json should be excluded too ; same stuff, only machine-readable. Does that sound about right? Maybe /src/, too? It sounds arbitrary :-) ; Exceptions cause confusion. Is it too dangerous to just do it and fix what's broken ? You can always revert quickly. Ask Regards, Henk Penning _ Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_ Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \ Budapestlaan 6, 3584CD Utrecht, NLF +31 30 253 4553 \_/ \_/ http://www.staff.science.uu.nl/~penni101/ M [email protected] \_/
Re: Making www.cpan.org TLS-only
Uh, there’s no “SSL” anymore. The newer versions of SSL have been “TLS” since the end of the nineties. https://en.wikipedia.org/wiki/Transport_Layer_Security That being said, the suggested change here is to require HTTPS for www.cpan.org by redirecting all plain-text HTTP requests to the HTTPS version. Ask
Re: Making www.cpan.org TLS-only
On one hand SSL (especially openssl) has received a lot of negative publicity about being insecure, so your proposal has merit. The counter argument is that Perl and CPAN strive to be relevant for ancient, old, young and brand-spanking-new installations. Forcing TLS would likely break some older operating systems' ability to update.
Re: Making www.cpan.org TLS-only
> On Aug 31, 2017, at 19:44, James E Keenan wrote: > > To be honest, I had no idea what 'TLS' meant when I first read this message. > So I can't say anything one way or the other about your proposal. > > I suspect I'm not alone in this. I would encourage you to post in a location > like blogs.perl.org as to what 'TLS' is, so that the census count of the > ignorant can be reduced. I posted on http://log.perl.org/ earlier. Feel free to link to that from blogs.perl.org. Ask
Re: Making www.cpan.org TLS-only
On 08/31/2017 09:10 PM, Ask Bjørn Hansen wrote: Hi everyone, We’re considering how/how-much we can make www.cpan.org TLS-only. http://log.perl.org/2017/08/tls-only-for-wwwcpanorg.html I expect that we can’t make the whole site TLS-only without breaking some CPAN clients, so the conservative version is to force TLS for - any url ending in *.html - any url not in matching some variation of (/authors/ | /MIRRORED.BY | ^/modules/[^/]+ ) Does that sound about right? Maybe /src/, too? (Also - we will support TLS for www.cpan.org permanently now, so please update URLs where possible and appropriate). To be honest, I had no idea what 'TLS' meant when I first read this message. So I can't say anything one way or the other about your proposal. I suspect I'm not alone in this. I would encourage you to post in a location like blogs.perl.org as to what 'TLS' is, so that the census count of the ignorant can be reduced. Thank you very much. Jim Keenan
