Termos mais procurados:
Bom dia, <@!229769812740407296>! A exigência do mTLS hoje veio do próprio BACEN e para adequar as normas e requerimentos da API Pix realizamos tal exigência no cadastro do webhook. Você pode utilizar também o endpoint GET /v2/pix para consultar os Pix recebidos, no entanto, recomendamos que se atente a boas práticas de consumo e evite fazer um pooling de forma exacerbada, pois a nossa equipe de infraestrutura acompanha este tipo de consulta e pode levar a restrições no IP nestes casos.
Concordo em discordar
A questão de padrão afeta todo mundo independente de volume.
Por isso nossa divergência de opiniões, ambientes diferentes, necessidades diferentes.
Eu faço muito menos kk
Nós só temos 1 gateway no momento, a Gerencianet. O sistema está preparado para múltiplos, mas não estamos usando esse recurso no momento. Talvez quem faça milhões de transações por dia precise, nós só fazemos milhares de transações por dia.
Verdade, tá certo, você tem uma necessidade pelo padrão, eu já não tenho, pois não vou ter mais de 1 ou 2 gateway nesse sistema que estou desenvolvendo.
Fato é que não obedecer ao padrão da API Pix era desqualificação imediata na seleção de PSPs que fizemos. E que hoje usamos Gerencianet, mas como é um padrão, temos liberdade para mudar se quisermos. Quem usa os não padrão, tem um custo de mudança elevado.
Exatamente, e predomina o padrão que as pessoas mais utilizarem
aushuashashu
Dizer que um padrão só é o correto é padrãofobia
MercadoPago segue padrões, só que os deles kk
Sim, é mTLS também, mas o ponto era a dificuldade em ter que configurar um endpoint pra um webhook conectar e exigir mTLS, não o recurso sozinho em si.
Mesmo com cronjob você está usando mTLS... tanto que você apresenta um client-certificate. Só é mais fácil de implementar do que a checagem server-side, mas é mTLS também.
E usar um gateway de pagamento que não segue padrões é pedir para se tornar escravo.
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.
