[LON-CAPA-admin] Help understanding hosting other domains' users on our access servers

[Mike Budzik]

Thanks for the quick response.  We'll look into these items.

Mike B
On Oct 5, 2015 6:52 PM, "Stuart Raeburn" <raeburn at msu.edu> wrote:

> Mike,
>
> What traffic goes across the other ports that LON-CAPA uses (e.g. 5663) and
>> is that encrypted?  Is this FERPA covered data being transmitted without
>> encryption?
>>
>
> My suggestion would be to run the request_ssl_key.sh script (in
> /home/httpd/lonCerts) on your library server and each of your access
> servers  so you can use SSL encryption for internal LON-CAPA traffic via
> port 5663 when your servers connect to other servers in the network, which
> have also installed LON-CAPA SSL certs (and had them signed by the LON-CAPA
> Certificate Authority).
>
> Please read the instructions in the "Internal LON-CAPA SSL" part of
> section 2.21 "Encrypting server traffic with SSL" in the domain
> coordination manual --
> https://loncapa.purdue.edu/adm/help/domain.manual.pdf -- for more
> information.
>
> Despite the fact that this infrastructure has been a part of LON-CAPA
> since version 1.3.0 (December 2004) the number of domains using internal
> SSL is still a minority.
>
> Note: you could also change the settings for the PerlVars:
>
> loncAllowInsecure
> londAllowInsecure
>
> in /etc/httpd/conf/loncapa.conf from 1 to 0 to prevent LON-CAPA internal
> connections to/from the purdue servers to other LON-CAPA servers in the
> network, which have not yet installed LON-CAPA SSL certs.
>
> However, I do not believe any other domains have so far chosen to do that.
>
> If purdue were to do that, it would be appropriate first to give other
> domains in the network which are currently sharing their resources with you
> a chance to install internal LON-CAPA SSL keys/certs on their own servers,
> if they have not yet done that.
>
> Even without LON-CAPA internal SSL enabled, a number of internal LON-CAPA
> transactions are encrypted. To see which those are you can grep for the
> string: encrypt: within /home/httpd/lib/perl/Apache/lonnet.pm
>
> Any idea how someone from Binghamton used our server despite our access
>> nodes configured as they are?
>>
>
> If someone from the binghamton domain has a co-author role in an Authoring
> Space in the purdue domain then that user would be allowed to have a user
> session hosted on the purdue library server.  However, I think it unlikely
> that such a co-author role exists.
>
> So my guess would be that this may have been possible because of a
> discrepancy between the "internet domain" listed in the
> /home/httpd/lonTabs/hosts.tab file present on one of the binghamton
> LON-CAPA servers, and the "internet domain" retrieved for the same LON-CAPA
> host from the authoritative "LON-CAPA DNS" servers at MSU, UIUC, and SFU.
>
> This particular situation at binghamton was discussed on this list
> recently, see:
> http://mail.lon-capa.org/pipermail/lon-capa-admin/2015-September/003100.html
>
> It has been my personal experience that ever since a purdue domain
> coordinator modified your domain configuration this summer to deny hosting
> of user sessions from other domains, I have been unable to transfer my own
> LON-CAPA user session (msu domain) to any of the purdue servers.
>
>
> Stuart Raeburn
> LON-CAPA Academic Consortium
>
> Quoting Mike Budzik <mikeb at purdue.edu>:
>
> For hosting other domains' users, we have our access nodes set to deny all
>> except the following (and none of the following are checked).  However,
>> today we noticed session data files in /home/httpd/perl/tmp on one of our
>> access nodes that are named with another domain.
>>
>> USERNAME1_binghamton_4231791afc6bb5593binghamtona6.db
>> USERNAME1_binghamton_4231791afc6bb5593binghamtona6.db.lock
>> USERNAME1_binghamton_4231791afc6bb5593binghamtona6_parms.db
>> USERNAME1_binghamton_4231791afc6bb5593binghamtona6.state
>> USERNAME1_binghamton_4231791afc6bb5593binghamtona6_symb.db
>>
>> USERNAME2_binghamton_4231791afc6bb5593binghamtona6.db
>> USERNAME2_binghamton_4231791afc6bb5593binghamtona6.db.lock
>> USERNAME2_binghamton_4231791afc6bb5593binghamtona6_parms.db
>> USERNAME2_binghamton_4231791afc6bb5593binghamtona6.state
>> USERNAME2_binghamton_4231791afc6bb5593binghamtona6_symb.db
>>
>> In the access log I think it looks like the users posted answers to some
>> problems.  For example:
>> POST /res/binghamton/gonzales/Postlab/analysisOfBottledWaterV3.problem
>> HTTP/1.1" 200 44989 "
>>
>> https://loncapa03.purdue.edu/res/binghamton/gonzales/Postlab/analysisOfBottledWaterV3.problem
>>
>> POST /res/binghamton/gonzales/Postlab/SimultaneousAnalysis.problem
>> HTTP/1.1" 200 56842 "
>>
>> https://loncapa02.purdue.edu/res/binghamton/gonzales/Postlab/SimultaneousAnalysis.problem
>>
>> Any idea how someone from Binghamton used our server despite our access
>> nodes configured as they are?
>>
>> Our organization is very sensitive to FERPA issues, so I'm pretty curious
>> about it.  In this case, based on the access log I could not guess which
>> course the user is in.  However, if the course had been named with a
>> course
>> number/name, that would mean I could discover some roster data which is
>> covered by FERPA.  What if the user used our access server to view their
>> grades?
>>
>> What traffic goes across the other ports that LON-CAPA uses (e.g. 5663)
>> and
>> is that encrypted?  Is this FERPA covered data being transmitted without
>> encryption?
>>
>> Thanks,
>> Mike B
>>
>
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.lon-capa.org/pipermail/lon-capa-admin/attachments/20151005/0221b372/attachment-0001.html>