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. 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
