Histórico de mensagens sobre n

Ou só fazer como eu fiz, verificar os pagamentos com cronjob, ou usar um gateway de pagamento que não torture os devs como o MercadoPago. Afinal eu não estou fazendo integração de uma instituição financeira nem nada do tipo.

O IP da Gerencianet que testei está sim coberto por um objeto RPKI, mas que tem zero efeito em redes que não validam.
Backbones Internet variam muito de segurança e qualidade... os que já foram usados para hijack mostram que isso é um problema.
O ponto de mTLS é que você disse que filtro por IP resolve, quando não resolve. Eu mesmo já apontei que não é o único design possível, e que há outras arquiteturas que não mTLS que sobreviveriam a IP hijack.
Mas o mTLS foi o que o instituidor do arranjo escolheu... não quer usar, só não aceitar Pix.

1 e 2) Se a Gerencianet não usa RPKI, não serve pra mexer com dinheiro. Se minha infra não verificam rotas, não serve pra ser minha infra.
3) Exato, então é mais fácil alguém hackear o backbone Internet, do que a AWS ou a Gerencianet? Pq sempre vai existir um vetor de ataque enquanto existirem humanos nesse planeta. Se a discussão se resume em "Ah mTLS é necessário pq existe a possibilidade de ataque X acontecer", daria pra se dizer o mesmo de toda e qualquer prática de segurança por mais infuncional que seja.

1 e 2) Enquanto você discute de quem é o problema, o fraudador embolsou a sua grana e do seu cliente
3) Não, MITM de anúncio assinado você pega qualquer roteador que esteja na Internet, pega os anúncios e repassa. Aí você recebe o tráfego, muda o que você quer muda, devolve o que não vai mudar. Quem foi hackeado aí foi o backbone Internet, não a AWS ou a Gerencianet.

1) Problema de quem anuncia
2) Problema de quem não verifica
3) MITM de anúncios assinados não seria literalmente a definição de hackear?

Não foi a AWS que foi hackeada no IP hijacking da AWS.

Eu sei que existe, o meu empregador que assina os RPKI brasileiros... 😉
Mas se você sabe que existe RPKI, deveria saber também que:
1) Nem todos os blocos IP já estão assinados
2) Nem todos os roteadores já verificam RPKI
3) RPKI endereça apenas hijacking com ASN origem errado, ainda é possível fazer hijack usando MITM de anúncios assinados

Existe um negócio chamado RPKI. Então acho mais fácil hackearem a Gerencianet do que a AWS.

Veja como foi este caso de IP hijacking há alguns anos atrás:
https://www.zdnet.com/article/aws-traffic-hijack-users-sent-to-phishing-site-in-two-hour-cryptocurrency-heist/

IP hijacking não precisa de comprometimento da Gerencianet. Alguém anuncia a rede do AWS onde fica a Gerencianet e desvia o tráfego para o hijack.

Como complemento, ótimo... dá para fazer estas checagens hoje no webhook:
1) O IP é o da lista da Gerencianet
2) O certificado é assinado pela CA da Gerencianet
3) O certificado tem o CN gn-webhook-pix
4) A chave Pix é uma chave para qual você registrou webhook
5) A transação é uma que você criou

mTLS também não é garantia, pq alguém pode hackear a Gerencianet, e roubar os certificados do mTLS, e sair por aí enviando webhooks fraudulentos, se for seguir por essa lógica.

Isso não é garantia, pois existe IP hijacking.

Ou, você além das verificações normais no backend, simplemente coloca um firewall aceitando solicitações somente dos IPs do gateway.

Sobre pedir mTLS, há duas estratégias para garantir integridade: uma é a que você mesmo vê na API de emissões da Gerencianet, onde a notificação só avisa de mudança de estado e você precisa de requisição direta para obter a alteração. A outra é carregar informação na requisição, e aí precisa de mTLS para ter certeza de quem veio. O Banco Central escolheu a 2a., mas ambas são alternativas válidas.

Eu sou também, pq eles fizeram recursos de segurança funcionais, como por exemplo criar um token pro cartão de crédito que não fica salvo no servidor. Isso tudo em documentação oficial.

q inclui um certificado

Eles são, você provavelmente não é, dada a baixa preocupação com segurança.

Sim, eu tenho gateways de pagamento pra cartão de crédito, e eles também não pedem mTLS, e são PCI Compliance.

O Banco Central neste caso é instituidor do arranjo. Visa e Mastercard não são estatais, e ambos especificam tanto funcionalidade quanto segurança, criaram o PCI Security Council para definir segurança. A questão não é ser estatal ou não.
Veja você mesmo a tonelada de requisitos de segurança dos arranjos de cartão:
https://www.pcisecuritystandards.org/