Re: Making www.cpan.org TLS-only

[Ask Bjørn Hansen]

> 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

[Leo Lapworth]

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

[Leon Timmermans]

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

[David Cantrell]

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

[David E. Wheeler]

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

[Kent Fredric]

> 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

[Ask Bjørn Hansen]

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

[Kent Fredric]

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

[Henk P. Penning]

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

[Ask Bjørn Hansen]

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

[Tim Orling]

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

[Ask Bjørn Hansen]

> 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

[James E Keenan]

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

[Ask Bjørn Hansen]

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