[cabfpub] [Ext] .well-known and re-directs

[Phillip Hallam-Baker]

I think that I broadly agree with Ryan on this but with possibly different argument.

For me, the key issue is whether the validation mechanism provides evidence that the request comes from the intended party. The burden of proof for any validation mechanism is on the proposer. For HTTP validation to a specific URI in .well-known space, the evidence is reasonably good. .well-known is generally a protected area in most web server deployments.

There is however one possible exception. While I have seen controls on putting material in the .well-known, I have also seen web server configurations that allow the ‘not found’ capability to be hooked fairly easily. 

Being on a plane and not able to get to my windows box, I can’t test it right now, but Windows 7-10 has an embedded Web server that allows applications to hook parts of the URI space. This is used by applications such as Skype.

It seems to me that this might well create a hole and that the burden of proof is on anyone suggesting redirects should be allowed to prove they are safe.


> On Jul 21, 2017, at 11:04 AM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> Hi Jeremy,
> 
> Apologies for the delay in responding. Would this be a correct summary
> of the confusion:
> 
> In HTTP, it is a Request/Response protocol. A request is made for a
> given resource, and a response is provided. Some responses include the
> resource directly requested (e.g. the 200/2xx series), other responses
> may indicate the resource has moved (e.g. 304) or is not available
> (e.g. 404 or 500). These are valid responses, but they indicate
> they're not the resource requested.
> 
> The question is whether or not a CA is expected to perform a single
> Request/Response in the of retrieving a resource (namely, "the content
> of a file or on a web page"), or whether it is allowed to adhere to
> the HTTP semantics that indicate how multiple Requests can be made to
> ultimately satisfy a resource fetch.
> 
> Personally, I'm strongly of the opinion that the Required Website
> Content should be obtained via a single Request/Response workflow.
> This aligns with at least some of the audit reports I've seen, where
> various auditors (whether security or BR) have interpreted this
> section as being restrictive to a single Request/Response flow, and
> appropriately flagged when a CA follows redirects. This suggests that
> there's at least some agreement on this view.
> 
> That said, I can also understand and appreciate a view that, by
> specifying "content of a file or on a web page", we may have
> inadvertently allowed for an interpretation that allows for multiple
> Requests/Responses.
> 
> When considering the reasonableness of either approach, it does seem
> important to consider this: Would we consider it reasonable for a CA
> to issue Range Requests for the file or a web page? This is where
> multiple requests can be made that, in their sum totality, encompass
> the fullness of the file or the web page. Would we allow for partial
> range requests (e.g. the CA only requesting say, the first 32 bytes).
> Would we expect CAs to detect situations of truncation (e.g. the
> content received does not align with the Content-Length) and either
> recover from it, reject it, or accept it as valid?
> 
> I'm certainly curious others' take, but from an overall security
> perspective (and aligning with the security audits of CAs that I've
> seen), there seems to be a general belief that a single
> Request/Response pair is all that is permitted.
> 
> Jacob has taken the view on the rewrite of the scheme, but without
> modifying the domain. If a server redirected to ftp://, would we still
> consider that Required Website Content? If it redirected to ldap://,
> would we still consider that Required Website content?
> 
> That said, I haven't heard any arguments that "on the Authorization
> Domain" encompasses anything other than the domain itself. At best, a
> modification of scheme (and thus, transitively, a modification of the
> port used - which needs to be congruent with Authorized Ports) may be
> worth discussing, but I would not want to see any scoping beyond that.
> 
> In these situations, it seems most advisable to take the restrictive
> approach - to disable redirects. The website authentication mechanism
> is already substantially less secure than some of our other methods,
> and the less we can do to increase that attack surface, the better.
> 
> On Fri, Jul 21, 2017 at 10:49 AM, Jeremy Rowley via Public
> <public at cabforum.org> wrote:
>> Is the lack of additional response agreement that “on the Authorization
>> Domain” encompasses both the authorization domain names and redirects from
>> an authorization domain name?
>> 
>> 
>> 
>> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
>> via Public
>> Sent: Thursday, July 20, 2017 8:37 AM
>> To: Jacob Hoffman-Andrews <jsha at letsencrypt.org>; Paul Hoffman
>> <paul.hoffman at icann.org>; CA/Browser Forum Public Discussion List
>> <public at cabforum.org>
>> Subject: Re: [cabfpub] [Ext] .well-known and re-directs
>> 
>> 
>> 
>> The BR language states the well-known directory must be “on the
>> Authorization Domain Name”.  Whether a re-direct is “on the Authorization
>> Domain Name” is questionable.  If following redirects is permitted, the
>> language should be updated accordingly.
>> 
>> 
>> 
>> Jeremy
>> 
>> 
>> 
>> 
>> 
>> From: Jacob Hoffman-Andrews [mailto:jsha at letsencrypt.org]
>> Sent: Wednesday, July 19, 2017 2:54 PM
>> To: Paul Hoffman <paul.hoffman at icann.org>; CA/Browser Forum Public
>> Discussion List <public at cabforum.org>
>> Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
>> Subject: Re: [cabfpub] [Ext] .well-known and re-directs
>> 
>> 
>> 
>> I disagree with Paul's interpretation. At Let's Encrypt we have always
>> followed HTTP redirects, and consider it an important part of validating by
>> HTTP. Consider, for instance, a web site that redirects all "http:" URLs to
>> "https:" URLs. If that site were required to inhibit redirects for
>> validation requests, that would be harmful to the site's security.
>> 
>> 
>> 
>> My interpretation is that RFC 5785 (Well-Known URIs) doesn't need to
>> specifically mention redirects, any more than it needs to mention Host
>> headers, status codes, or any of the other implementation details of HTTP.
>> According to RFC 7231 (HTTP Semantics and Content):
>> 
>> 
>> 
>>> The 3xx (Redirection) class of status code indicates that further
>> 
>>> action needs to be taken by the user agent in order to fulfill the
>> 
>>> request.  If a Location header field (Section 7.1.2) is provided, the
>> 
>>> user agent MAY automatically redirect its request to the URI
>> 
>>> referenced by the Location field value, even if the specific status
>> 
>>> code is not understood.
>> 
>> 
>> 
>> If it was the intent of RFC 5785 or the Baseline Requirements to rule out
>> certain HTTP semantics, that would need to be made explicit. And I think an
>> amendment ruling out redirects would be a mistake. For reference, here's the
>> relevant BR text:
>> 
>> 3.2.2.4.6 Agreed-Upon Change to Website
>> 
>> Confirming the Applicant’s control over the requested FQDN by confirming one
>> of the following under the “/.well-known/pki-validation” directory, or
>> another path registered with IANA for the purpose of Domain Validation, on
>> the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS
>> over an Authorized Port:
>> 
>> The presence of Required Website Content contained in the content of a file
>> or on a web page in the form of a meta tag. The entire Required Website
>> Content MUST NOT appear in the request used to retrieve the file or web
>> page, or
>> The presence of the Request Token or Request Value contained in the content
>> of a file or on a webpage in the form of a meta tag where the Request Token
>> or Random Value MUST NOT appear in the request.
>> 
>> If a Random Value is used, the CA or Delegated Third Party SHALL provide a
>> Random Value unique to the certificate request and SHALL not use the Random
>> Value after the longer of (i) 30 days or (ii) if the Applicant submitted the
>> certificate request, the timeframe permitted for reuse of validated
>> information relevant to the certificate (such as in Section 3.3.1 of these
>> Guidelines or Section 11.14.3 of the EV Guidelines).
>> 
>> 
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public