On Thu, Aug 30, 2018 at 2:28 PM Ilari Liusvaara <[email protected]> wrote:
> > The main reason to allow redirects within a domain is if there is a > > unilateral redirect from example.com to www.example.com > > <http://www.example.com> , which is of course incredibly common. It > > seems one should be able to validate example.com using that redirect. > > I have no data on potentially exploitable redirects on-domain versus > off-domain, but I can say that even some http://foo.example to > https://foo.example redirects are exploitable (especially with > substring matching, but sometimes even without that). > > The following two types of redirects seem practicularly troublesome: > > - Redirect is from above validation directory (usually via global > redirect of any resource on name). http:// to https:// redirects > and redirects from example.com to www.example.com are usually of > this kind. In contrast, redirects specific to validation directory > are very probably secure. > - Redirects that are not injective (multiple source URLs map to the > same target URL.). These are invariably from above validation > directory redirects. > > Then I saw somebody argue that redirecting .well-known globally > is misconfiguration. And indeed, that place is grab-bag of different > things, some of which prohibit redirects, some which leave things > implicit and some that explicitly follow redirects. > I'm not sure why either of these are particularly troublesome, given the requirements, and giving the use of either the Random Value (which must be random) or it being bound to the request. Is the issue here one of redirects, or the (as practiced by CAs) distinction between "the presence of" versus "the contents shall be". That is, if the CA/Browser Forum required that the contents be explicit (and/or with a mime-type requirement), does that resolve the matter with redirects? (I ask, because that's one of the already identified structural weaknesses of 3.2.2.4.6)
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
