[Opensim-dev] external host name

Fri Dec 12 08:39:36 UTC 2008

ugh.  I think I should chime in here and point out that there's at
least one major problem with this view if SSL certificates are in use.

First, the name by which the client accesses the HTTPS server should
be in the subjectAlternativeName of the TLS certificate (though may,
for backward compatibility, show up as part of the Subject's CN field,
if there are no sAN entries of type dNSName in the certificate).  This
is part of the HTTPS protocol (specifically "HTTP over TLS", RFC2818,
section 3.1).

This presents a bit of a problem with the "resolve(hostA) ==
resolve(hostB)" logic suggested.  Places which use commercial TLS
certificates won't have an iPAddress field therein, it'll have dNSName
fields.  This means that the names which are presented to the client
MUST be in the certificate, and due to current TLS certificate
issuance practice MUST be provided to the client as names, not IPs.

I'd rather design for situations which are already known to exist.
(Though I also have to mention that Linden runs its own CA, and so
they can do whatever the hell they want with their grid; there's
nothing preventing anyone else from doing so either, except that those
CA certificates would need to be provided to the users to put into
their Linden viewer folders.)

-Kyle H

On Thu, Dec 11, 2008 at 9:30 PM, Melanie <melanie at t-data.com> wrote:
> Then we should resolve all hostname fields int he LL stack, and feed
> the client IP addresses. That should still allow us flexible handling.
> Most importantly, we should not string-compare hostss. Not if (host
> a == host b) but if (resolve(host a) == resolve(host b))
>
> Melanie
>
>
> Diva Canto wrote:
>> I agree. The problem is that the client doesn't understand that, and
>> this causes problems with caps urls.
>>
>> Melanie wrote:
>>> A host name can also be an IP address. IP addresses and hostnames
>>> are interchangable and we can't assume DNS presence. So, the field
>>> should accept a name or IP, and resolve names, like almost
>>> everything else on the internet does.
>>>
>>> Melanie
>>>
>>>
>>> Cristina Videira Lopes wrote:
>>>
>>>> The thing is that this can potentially create a RegionInfo data
>>>> structure with
>>>>            nRegionInfo.ExternalHostName = regionData.IPADDR;
>>>>
>>>> This is inconsistent with certain queries on the Grid server, like "give
>>>> me all my neighbors" which may send host names.
>>>>
>>>> So, back to the point: someone needs to decide what is it that
>>>> RegionInfo.ExternalHostName  is supposed to hold.
>>>>
>>>> Teravus Ovares wrote:
>>>>
>>>>> RegionUpData is my fault, and spawned from compatibility issues with
>>>>> .NET remoting and Mono remoting with complex types.  It is only used
>>>>> to notify a neighbor region that 'this region is up'
>>>>>
>>>>> Best Regards
>>>>>
>>>>> Teravus
>>>>>
>>>>> On 12/11/08, Cristina Videira Lopes <lopes at ics.uci.edu> wrote:
>>>>>
>>>>>
>>>>>> Things are very messy right now. You can search for "sim_ip", for example,
>>>>>> which is used in chatting with the grid server, and where it is being
>>>>>> converted to an IP address in about half of the cases.
>>>>>>
>>>>>> To compensate, and before I noticed this inconsistency, Homer introduced
>>>>>> another field called "sim_host", so not to mess with what was already there,
>>>>>> that is supposed to carry the external host name, but this only works up to
>>>>>> the point in which RegionInfo data structures are created. At that point, we
>>>>>> need to decide what to place in m_externalHostName, sim_ip or sim_host.
>>>>>> Which means changes in OGS1.
>>>>>>
>>>>>> I also noticed that there is yet another data structure called RegionUpData
>>>>>> that uses IP addresses.
>>>>>>
>>>>>> So, messy. Someone should decide what this field is supposed to be, and make
>>>>>> it a rule.
>>>>>>
>>>>>> Charles Krinke wrote:
>>>>>>
>>>>>> Dear Diva:
>>>>>>
>>>>>> You have a very good point and I would support harmonizing to one notion
>>>>>> even at the expense of breaking some things for a while.
>>>>>>
>>>>>> In fact, if someone can identify what some of those things are, or come up
>>>>>> with a couple of search strings or grep expressions, I would like to look at
>>>>>> the anomalies myself.
>>>>>>
>>>>>> +1 on external_host_name
>>>>>>
>>>>>> Charles
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>>
>>>>>> From: Cristina Videira Lopes <lopes at ics.uci.edu>
>>>>>> To: opensim-dev at lists.berlios.de
>>>>>> Sent: Thursday, December 11, 2008 2:42:05 PM
>>>>>> Subject: [Opensim-dev] external host name
>>>>>>
>>>>>> It turns out that a lot of problems with CAPs have to do with
>>>>>> inconsistencies surrounding the URL of the seed cap. Specifically, in
>>>>>> some cases we're producing URLs with hostnames, other times we're
>>>>>> producing URLs with IP addresses, for example:
>>>>>>
>>>>>> http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/
>>>>>> vs.
>>>>>> MailScanner has detected a possible fraud attempt from "128.200.71.43:9000"
>>>>>> claiming to be MailScanner warning: numerical links are often malicious:
>>>>>> http://128.200.71.43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/
>>>>>>
>>>>>> The client is not smart enough to test if this is the same host, it
>>>>>> assumes it isn't, so it decides someone's trying to game it.
>>>>>>
>>>>>> The inconsistencies are all over the code in OpenSim, and they pertain
>>>>>> to the use of ExternalHostName in several data s! tructures. In some
>>>>>> cases, an explicit conversion to IP addresses is made.
>>>>>>
>>>>>> We should converge to one single thing. And I believe that thing should
>>>>>> be whatever it is given in external_host_name config. Is this right?
>>>>>> However, I am a bit afraid this is going to break 17 different things...
>>>>>>
>>>>>> Crista
>>>>>>
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev at lists.berlios.de
>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>> ________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev
>>>>>
>>>>>
>>>>>> mailing
>>>>>> list
>>>>>>
>>>>>>
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev at lists.berlios.de
>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>