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. 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. _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
