On Sun, May 31, 2020 at 2:07 AM Erik Kline <ek.i...@gmail.com> wrote:
> On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef > <rifaat.s.i...@gmail.com> wrote: > > > > Adding SecDir back to this thread. > > > > > > >Martin Thomson <m...@lowentropy.net> Tue, 19 May 2020 01:02 UTCShow > header > > > > > >On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote: > > >> it provides the client of the API > > >> an opportunity to authenticate the server that is hosting the API. > > >> This authentication is aimed at *allowing a user to be reasonably > > >> confident that the entity providing the Captive Portal API has a > > >> valid certificate for the hostname in the URI* > > >[...] > > >> An end user should be able to validate that the name is example.com > and > > >> not any other form of the URI. > > >> It would be much more difficult for the end user to make sense and > > >> validate an IP address. > > > > > >I think that you missed the point of my comments. This validation, > performed by > > >a user, has no meaningful security value. The text you cite says that > the server > > >has a certificate for the name it chooses, which is not the same as > "has a certificate > > >for a name the client expects". The difference is important. > > > > > > > This is not the way I read these statements from section 4.1 titled > Server Authentication. > > > > Here is the use case I have in mind when I read this section: > > If I walk into an airport and I see an ad for a paid Internet service > from example.com, then as an > > end user it is reasonable to expect that I would have some ability to > make sense of the name > > presented to me and make sure it is from example.com if I choose to get > such a service. > > > > If this is not the case, then yo might want to make it clear that this > is not about Server Authentication > > as the title of the section and the text inside that section is > suggesting. > > If we changed the API document's section 4.1 title from "Server > Authentication" to "API Server Authentication", would that be more > clear? > > I reality, users should never see the API URL. The following is a quote from section 4.1 of the API document, which implies otherwise: "The hostname of the API SHOULD be displayed to the user in order to indicate the entity which is providing the API service." Regards, Rifaat > They'll just be > connecting to "Cool Cafe" or "Awesome Bookshop" ESSIDs. If anything > will only be one or both of the "user-portal-url" or "venue-info-url" > URLs that might be visible in the browser that's opened for the user's > interaction. > > -ek > > > Regards, > > Rifaat > > > > > > > > >In a typical web scenario, a person types a string in and (ignore the > case where there > > >is an extra hop via a search engine) that string determines what is > acceptable as a > > >server identity. The exposure to confusables is limited (under a set > of other assumptions, > > >HSTS, etc...). Here, the network has free reign to do as they choose > with homoglyphs and > > >other such nonsense. Any expectation you might have about this really > being a trustworthy > > >entity is meaningless in this context. > > > > > >There are protections against this, but they all lie firmly in the > anti-phishing domain. > > >Most of those rely on having a certificate though, so the requirement > for HTTPS is in > > >service of that, not in terms of ensuring that an untrained human can > make a security > > >critical decision based on poisoned information. > > > > On Mon, May 18, 2020 at 5:08 PM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> > >> Adding Ben. > >> > >> > >> On Sun, May 17, 2020 at 9:26 PM Martin Thomson <m...@lowentropy.net> > wrote: > >>> > >>> Adding more lists.. > >>> > >>> On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote: > >>> > > Here is a quote form the API document: > >>> > > "The hostname of the API SHOULD be displayed to the user in order > to indicate the entity which is providing the API service." > >>> > > > >>> > > This seems to suggest that the user is expected to inspect the > displayed name and make sure it is make sense in the context of whoever is > providing that service. > >>> > >>> I don't think that is the case. If this were a security mechanism, > then it would use "MUST". This is likely for the purpose of enabling some > sort of accountability. In other words, this is to offer maximal > information about what is going on. > >>> > >> Here is the sentence just before the above quote from the API document: > >> > >> it provides the client of the API > >> an opportunity to authenticate the server that is hosting the API. > >> This authentication is aimed at allowing a user to be reasonably > >> confident that the entity providing the Captive Portal API has a > >> valid certificate for the hostname in the URI > >> > >> > >> > >> > >>> > >>> > > Since this would be an easier attack compared to the interception > attack, and IP address is still permitted, then an attacker might force the > use of IP address to make it harder for the user to make sense of the > displayed name. > >>> > >>> I don't think that is materially different than getting a name with > confusable characters (or using the prefix hack, > example.com.<some-guid>.example, > in an attempt to confuse). > >> > >> > >> An end user should be able to validate that the name is example.com > and not any other form of the URI. > >> It would be much more difficult for the end user to make sense and > validate an IP address. > >> > >> Regards, > >> Rifaat > >> > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org > > https://www.ietf.org/mailman/listinfo/captive-portals >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
