Spurious requests, certificate auditors?

Question

In the last few days I've seen lots of POST requests to many of the domains I own hitting the following paths:

/ct/v1/sct-gossip
/ct/v1/sct-feedback
/.well-known/ct/v1/sct-feedback
/.well-known/ct/v1/sth-pollination
/.well-known/ct/v1/collected-sct-feedback
/.well-known/ct/v1/sct-gossip
/topleveldir/subdir/research-feedback

Is this someone trying to do something dubious?

I found the following document which suggests this might be something to do with certificate auditors although I am not sure what! All of my websites are fronted by Cloudflare which provides the SSL certs so I would really expect Cloudflare to handle any such requests.

https://datatracker.ietf.org/doc/html/draft-ietf-trans-gossip-00

Any thoughts would be appreciated :-)

user_917502 · Answer

After investigations, the requests comes from https://net.in.tum.de/projects/gino/index.html#internet-wide-scans

They are conducting Internet measurements to find Certificate Transparency Gossip Endpoints.

You can ask them to blacklist your domain/IP just by sending an email to scans@net.in.tum.de

Regards

user_8719415 · Answer

This is a knwon security protocol for certificate chains.

user_8721807 · Answer

https://ct.grahamedgecombe.com/

has: Signed Tree Head gossip

Two API endpoints are provided for exchanging STH gossip:

/ct/v1/sth-gossip, which implements draft-linus-trans-gossip-ct-01.
/.well-known/ct/v1/sth-pollination, which implements draft-ietf-trans-gossip-00.

Both return all the STHs observed over the last hour, so there is little point in querying them more than once every 30 minutes. If you use one of these endpoints, I'd appreciate being able to fetch gossip from your monitor in return. In particular, the /ct/v1/sth-gossip endpoint doesn't support exchanging gossip in both directions. Get in touch with me if you want to organise this. Signed Certificate Timestamp gossip

An experimental API endpoint is provided for submitting SCT gossip:

/ct/v1/sct-feedback, which implements draft-ietf-trans-gossip-00.

The monitor checks that the corresponding entries are included in the log after the log's Maximum Merge Delay has elapsed. Although the results of this check are stored in the database, they are not currently displayed in the web interface.

user_5847124 · Answer

TLDR; - very likely malicious traffic or check that the ips fall within the range posted by @QuentinL.D

The .well-known urls are likely attempts to exploit some possible from https://www.letsencrypt.org. Or more likely misconfigured web servers. I say possible b/c i have not heard of any issues with letsencrypt, if you're not using letsencrypt then i would consider this malicious traffic. A normal request from letsencrypt/certbot[1] would look similar to:

127.0.0.1 - - [03/Oct/2017:22:21:02 +0000] "GET /.well-known/acme-challenge/2VJSAGWTQ3l14rkSa7MTbVYKiwPEXvrx2T1BdQpOVhc HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" "-"

Note that mine states 127.0.0.1 b/c i route these requests with haproxy locally to a distinct port/backend and not to the web servers in the cluster.

1 - https://github.com/certbot/certbot

I too see these in my web server logs, which will never host a letsencrypt .well-known folder, which is why i (briefly) explained my setup above

I realize this is not an exact answer to your question, but hopefully this helps.

EDIT: The IPs hitting these urls are within the rage posted by @QuentinL.D, didn't notice that comment first, thanks for the link.

Spurious requests, certificate auditors?

4 Answers