Re: AIA CA Issuers URL gives 403 (Microsoft)
On Wed, May 13, 2020 at 9:00 PM Matt Palmer via dev-security-policy
wrote:
> On the contrary, unless there's an override of RFC5280 4.2.2.1 in the BRs
> that I can't find, the requirement of universal access does exist. RFC5280
> 4.2.2.1 says, in relevant part:
>
> "Where the information is available via HTTP or FTP, accessLocation MUST be
> a uniformResourceIdentifier and the URI MUST point to either a single DER
> encoded certificate [or a "certs-only" CMS]"
>
> A CA is permitted to carefully weigh "the full implications" before deciding
> to not abide by the SHOULD in BRs 7.1.2.3(c), but if they choose to put
> caIssuers into AIA, it is an "absolute requirement" that the URI provide a
> DER-encoded certificate (or a "certs-only" CMS). A URI that returns a 403
> is not a URI that "point[s] to [...] a single DER encoded certificate".
>
> That sounds to me an *awful* lot like a requirement that the URL be
> accessible and return a DER-encoded certificate (and, by construction, "that
> they’re prohibited from including URLs [I] can’t access").
I'm afraid this grossly misrepresents what URLs are, and RFC 5280. A
URL describes a resource at a location, it does not describe the
potential responses for retrieving that URL. RFC 5280 places a
requirement on the content of the resource at the location, but that
does not mean or constrain the possible responses for that resource.
While it's true a 404 indicates that no such resource exists, and thus
/is/ a violation, a 403 indicating that the resource is forbidden from
access is not, in and of itself, a violation, no different than
responding 301 or 302, or 300 indicating multiple resources.
Put differently, the language you're citing a statement about the
content of the URL when that resource is *successfully* dereferenced,
without an obligation upon that URL to be successfully dereferenced by
the client.
The canonical example is for internally-operated CAs, it's perfectly
fine to put an intranet URL in. In fact, every local CA will do that
(e.g. Active Directory Certificate Services does that by default).
That's the interoperability that 5280 permits, and you can't simply
say those certificates don't conform with the profile.
So no, it's *nothing* like a requirement the URL be accessible, and
that's why I'm wanting to push to see if there's a more compelling
argument here. Right now it just seems an emotional response based on
personal opinion, but not much to support the opinion, and that seems
unfortunate.
> > > 2. wget is a legitimate tool for downloading files, thus blocking the
> > > wget user agent is denying legitimate users access to the resource.
> >
> > This seems to be saying that there can be zero negative side-effects,
> > regardless of the abuse. I don’t find this compelling either.
>
> You appear to be trying to extract a general rule from a specific
> statement.
While cute, your own sentence below shows that you were making a
generalized statement.
1. You cannot deny legitimate users access to the resource.
2. Legitimate users use legitimate tools
3. Wget is a legitimate tool that legitimate users use
Ergo ("thus")
4. You cannot block wget from access to the source
I'm pointing out the flaw here, which is the assumption that wget is a
tool only legitimate users use is a statement without evidence (and
"obviously" false). Yet for the above to hold, despite this, then it's
saying that "You cannot deny legitimate users access to the resource"
is a higher principle and priority than "wget is a tool sometimes used
by illegitimate users", and that's a problematic statement to make.
Which you double down on, below.
> I stated that the apparently-permanent blocking of a general purpose UA from
> being able to access a caIssuers URL was unacceptable. I gave several
> reasons why, in my professional experience dealing with Internet abuse,
> blocking a general purpose UA has both noticeable impact on legitimate
> users, and a very limited impact on attackers.
On its face, the argument remains problematic, because 'legitimate'
tools can and are used for problematic purposes, and suggesting that
some tools ("legitimate ones") cannot be blocked (because they deny
"legitimate users access to the resource") instantly creates and
incentivizes illegitimate tools to disguise themselves as legitimate
tools.
You haven't really addressed this. Yes, I don't disagree that blocking
by UA has side-effects, but in the above argument, you're again
suggesting that there's some rule making about when such side-effects
are acceptable and not acceptable, without actually spelling out what
those are. That's why I pushed in my previous mail, and why I'm still
pushing to see if there's something being overlooked. Below, you set
an entirely unreasonable standard, by suggesting that if, taken as
written, at least two users are affected, the CA must show everything
possible to prevent that. I don't find that compelling, and certainly
not compelling enough to suggest
Re: AIA CA Issuers URL gives 403 (Microsoft)
On Wed, May 13, 2020 at 08:28:03AM -0400, Ryan Sleevi wrote: > On Tue, May 12, 2020 at 11:47 PM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 1. As Hanno said, it's a public resource, and as such it should, in > > general, > > be available to the public. > > This is worded as a statement of fact, but it’s really an opinion, right? It's a statement of fact, in my opinion. > You might think I’m nitpicking, but this is actually extremely relevant > and meaningful. The requirements in 7.1.2 are only a SHOULD level, and do > not currently specify access requirements. Your position seems to be that > they’re better by omitting AIA than including a URL you can’t access, or > that they’re prohibited from including URLs you can’t access, and neither > of those requirements actually exist. On the contrary, unless there's an override of RFC5280 4.2.2.1 in the BRs that I can't find, the requirement of universal access does exist. RFC5280 4.2.2.1 says, in relevant part: "Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate [or a "certs-only" CMS]" A CA is permitted to carefully weigh "the full implications" before deciding to not abide by the SHOULD in BRs 7.1.2.3(c), but if they choose to put caIssuers into AIA, it is an "absolute requirement" that the URI provide a DER-encoded certificate (or a "certs-only" CMS). A URI that returns a 403 is not a URI that "point[s] to [...] a single DER encoded certificate". That sounds to me an *awful* lot like a requirement that the URL be accessible and return a DER-encoded certificate (and, by construction, "that they’re prohibited from including URLs [I] can’t access"). Of course, one could argue that blocking attackers violates this. If you block an attacker, but nobody else hears, does it make a violation? I guess we'll find out when a botnet operator complains to m.d.s.p that they got blocked. > > 2. wget is a legitimate tool for downloading files, thus blocking the > > wget user agent is denying legitimate users access to the resource. > > This seems to be saying that there can be zero negative side-effects, > regardless of the abuse. I don’t find this compelling either. You appear to be trying to extract a general rule from a specific statement. I stated that the apparently-permanent blocking of a general purpose UA from being able to access a caIssuers URL was unacceptable. I gave several reasons why, in my professional experience dealing with Internet abuse, blocking a general purpose UA has both noticeable impact on legitimate users, and a very limited impact on attackers. If you'd like a more general rule to go by, here's my take: if a CA's method of blocking abuse negatively impacts legitimate users, the CA has an obligation to demonstrate that no other method of blocking abuse, one with less negative impact on legitimate users, is capable of reasonably dealing with the threat. I use the present tense in the preceding paragraph, but it's past tense in this particular case -- as far as I can discern, the UA blocking has been removed from the URLs listed in the OP. > If we say it’s ok to not be accessible to any, because it’s not present, > where’s the harm in not being accessible to some, when it is? Conversely, if there's no harm in it not being available to some, where's the harm in it not being available to any? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AIA CA Issuers URL gives 403 (Microsoft)
On Tue, May 12, 2020 at 11:47 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, May 12, 2020 at 11:37:23PM -0400, Ryan Sleevi wrote: > > On Tue, May 12, 2020 at 10:30 PM Matt Palmer via dev-security-policy > > wrote: > > > > > > On Tue, May 12, 2020 at 07:35:50AM +0200, Hanno Böck via > dev-security-policy wrote: > > > > After communicating with Microsoft it turns out this is due to user > > > > agent blocking, the URLs can be accessed, but not with a wget user > > > > agent. > > > > Microsoft informed me that "the wget agent is explicitly being > blocked > > > > as a bot defense measure." > > > > > > > > I leave it up to the community to discuss whether this is acceptable. > > > > > > I'm firmly on the "nope, unacceptable" side of the fence on this one. > > > > Could you share your reasoning? > > Sure, plenty of reasons: > > 1. As Hanno said, it's a public resource, and as such it should, in > general, > be available to the public. This is worded as a statement of fact, but it’s really an opinion, right? You might think I’m nitpicking, but this is actually extremely relevant and meaningful. The requirements in 7.1.2 are only a SHOULD level, and do not currently specify access requirements. Your position seems to be that they’re better by omitting AIA than including a URL you can’t access, or that they’re prohibited from including URLs you can’t access, and neither of those requirements actually exist. 2. wget is a legitimate tool for downloading files, thus blocking the wget > user agent is denying legitimate users access to the resource. This seems to be saying that there can be zero negative side-effects, regardless of the abuse. I don’t find this compelling either. Taken to its logical conclusion, any blocking of any DDOS traffic by IP or form would be problematic, because the traffic “could” be legitimate. There’s understandably a balance, but you’ve seemingly ignored that balance and put the argument as an extreme with zero interest in finding that balance. I think that does more harm to your position, and more broadly, harm to finding that balance. 3. For a miscreant, blocking by user agent is barely a speed bump, as > changing UA to something innocuous / harder to block is de rigeur. So? That’s largely hypothetical. Does it matter if the miscreants they’re concerned about don’t? There’s an argument you’re not making and not articulating, which is to suggest the positive benefits the CA seems from such blocking are outweighed by the negative side-effects, and that the balance isn’t being struck. That would be a compelling argument to try and find what the balance should be. But, as I said, you’re arguing an intractable extreme instead, and that makes it difficult to agree with you. On principle, I’m uneasy with the UA blocking. However, I also have trouble arguing it is or should be forbidden, especially given that taken to the extreme, it would remove important controls for DDoS protection. This is because assumptions here seem to rely on “traffic properties you’re allowed to filter on (and drop)” and “traffic properties you are not allowed to”. I’m hoping those who feel strongly that this is bad can put a more cogent argument forward, especially given that this is, at present, only a SHOULD (ergo, optional). If we say it’s ok to not be accessible to any, because it’s not present, where’s the harm in not being accessible to some, when it is? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AIA CA Issuers URL gives 403 (Microsoft)
On Tue, May 12, 2020 at 11:37:23PM -0400, Ryan Sleevi wrote: > On Tue, May 12, 2020 at 10:30 PM Matt Palmer via dev-security-policy > wrote: > > > > On Tue, May 12, 2020 at 07:35:50AM +0200, Hanno Böck via > > dev-security-policy wrote: > > > After communicating with Microsoft it turns out this is due to user > > > agent blocking, the URLs can be accessed, but not with a wget user > > > agent. > > > Microsoft informed me that "the wget agent is explicitly being blocked > > > as a bot defense measure." > > > > > > I leave it up to the community to discuss whether this is acceptable. > > > > I'm firmly on the "nope, unacceptable" side of the fence on this one. > > Could you share your reasoning? Sure, plenty of reasons: 1. As Hanno said, it's a public resource, and as such it should, in general, be available to the public. 2. wget is a legitimate tool for downloading files, thus blocking the wget user agent is denying legitimate users access to the resource. 3. For a miscreant, blocking by user agent is barely a speed bump, as changing UA to something innocuous / harder to block is de rigeur. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AIA CA Issuers URL gives 403 (Microsoft)
On Tue, May 12, 2020 at 07:35:50AM +0200, Hanno Böck via dev-security-policy wrote: > After communicating with Microsoft it turns out this is due to user > agent blocking, the URLs can be accessed, but not with a wget user > agent. > Microsoft informed me that "the wget agent is explicitly being blocked > as a bot defense measure." > > I leave it up to the community to discuss whether this is acceptable. I'm firmly on the "nope, unacceptable" side of the fence on this one. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AIA CA Issuers URL gives 403 (Microsoft)
Hi, On Mon, 11 May 2020 10:53:26 +0200 Hanno Böck via dev-security-policy wrote: > I did some checks on certificates and their AIA sections and noticed > that several Microsoft certificates were referencing intermediate > certificates in the "CA Issuer" field that give a 403 error. > > http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%201.crt > http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%202.crt > http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%204.crt > http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%205.crt So there's a somewhat unexpected update here: After communicating with Microsoft it turns out this is due to user agent blocking, the URLs can be accessed, but not with a wget user agent. Microsoft informed me that "the wget agent is explicitly being blocked as a bot defense measure." I leave it up to the community to discuss whether this is acceptable. I stronly feel it's not and I feel that this is public information that should be accessible without any hurdles, and there's no need to have any "bot defense" on a static file that should be public information. -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
AIA CA Issuers URL gives 403 (Microsoft)
I did some checks on certificates and their AIA sections and noticed that several Microsoft certificates were referencing intermediate certificates in the "CA Issuer" field that give a 403 error. http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%201.crt http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%202.crt http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%204.crt http://www.microsoft.com/pki/mscorp/Microsoft%20IT%20TLS%20CA%205.crt These are listed in active use on certificates on public hosts (e.g. azure.com, msn.com, skype.com, xbox.com). I have informed Microsoft through the contact mail address in the CCADB. -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
