# Security Report Chain: The vulnerability reports we receive

- Link: https://www.agilicus.com/security-vulnerability-reports/
- Published: 2021-04-15T15:35:42+00:00
- Author: Don Bowman

Earlier I [wrote](https://www.agilicus.com/security-txt-how-to-document-receiving-security-vulnerabilities/)
about the Security Report Chain (via [security.txt](https://securitytxt.org/)), 
how one documents their policy on vulnerability reporting. You can see the the Agilicus’
[security.txt](https://www.agilicus.com/security.txt) here, as well as the [policy](https://www.agilicus.com/security-policy.html).
Well, people find them, and, they send you information in the hopes of gigantic 
bug bounties. Let’s talk about the reports.

The Security Report Chain breaks down into 2 categories so far. The first are exceptionally
basic, no research, things like “your web site runs on non-tls”. Well, yes… but 
all it does is “301 redirect https://”, here we have an HSTS record. And, we are
all-in on TLS, being on the [preload](https://www.agilicus.com/we-are-all-in-on-the-tls-the-hsts-preload/)
list. So, uh, thanks for nothing.

Its the second type of Security Report Chain that intrigue me more. They have taken
some time. I think they have some automated tools. And they often say things like:

> I find you have [https://auth.agilicus.com/.well-known/openid-configuration](https://auth.agilicus.com/.well-known/openid-configuration)
> which links to [https://auth.agilicus.com/keys](https://auth.agilicus.com/keys)
> which has a set of authentication keys. These should only be available to authenticated
> users, this is a critical vulnerability.
>  –some hopeful security researcher

So yes, this is true. And, it does take a bit of reading to understand what it is,
and why its not only safe, but desirable. The standard is OpenID Connect, and, it
has a [discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) document(
that first link). In turn, it has a means of discovering the current public keys,
which are rotated hourly. Why do we do that? Well, the standard requires it. But
what is the intent?

The first, the discovery document, this allows zero-configuration software to just
work. A client can read this document, use the configuration, and proceed onwards
with OpenID Connect. Nothing in the document is security sensitive (the alternative
would have been to hard code it in the client). It simply says which URI to talk
to to authenticate, how to obtain tokens, and, how to validate them. Does this belong
in my Security Report Chain

The second, the keys ([JWKS](https://tools.ietf.org/html/rfc7517)) are the public
key. This allows a client which has received a token from the authentication process
to independently verify it. It does not allow you to sign a token, it is not the
private key.

OK, so in this Security Report Chain the reporter has done some scan, has found 
something of interest. Without knowing the standard, they have assumed that encryption
keys should not be available unauthenticated. So they have followed my policy, reported
the “problem”. But, here’s where I’m not sure what to do. They are doing this solely
because they want a bug bounty. I decline to pay such for things which are “as designed,
not a bug”, on principle. Would I be better to pay $5 for their diligence? I sent
them a response (there were more than a few on similar topics) pointing out individual
reading they could do to learn about the standards involved.

Suggestions anyone?