Re: Making www.cpan.org TLS-only
> On Sep 5, 2017, at 11:22 , Leo Lapworthwrote: > > 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 Timmermanswrote: > 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 Hansenwrote: > > 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 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 Hansenwrote: > 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
> 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 Hansenwrote: > 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 Fri, 1 Sep 2017, Ask Bjørn Hansen wrote: Date: Fri, 1 Sep 2017 03:10:12 +0200 From: Ask Bjørn Hansen <a...@perl.org> To: cpan-workers@perl.org 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 penn...@uu.nl \_/
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 Keenanwrote: > > 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
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/[^/]+ ) 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). Ask