On Mon, Jun 30, 2025 at 3:07 PM Michael Richardson <[email protected]> wrote:
> > Tommy Pauly <[email protected]> wrote: > >> Captive portals that do not follow the requirements of Section 1 of > >> {{?RFC8952}} MAY forcibly redirect HTTPS connections. While this > is a > >> deprecated practice as it breaks TLS in a way that most users can > not > >> deal with, it is still common in many networks. > > > I would question using a normative MAY here; clearly, it’s something > > the network can do and often will do, but it seems like this is more > a > > statement of practice than saying “you MAY do this” as a thing we’d > > recommend. I would probably say “might”. > > I saw that too when editing, and I thought I changed it already. > Nope. Fixed now. > > Any other thoughts? > Forced redirect of TLS by portals usually is detected by a certificate > validation failure. But, in 8995, we defer the verification until later > on. > What I want to know is whether this explanation is reasonably communicated. > What are the security implications of any information leaked via the voucher request? Is it just "oooh look, here's a node that's doing BRSKI" or is there some more traceable client information in there? (Clearly I haven't gone looking to refresh any ANIMA/BRSKI semantics/mechanics).
_______________________________________________ Captive-portals mailing list -- [email protected] To unsubscribe send an email to [email protected]
