Termos mais procurados:
Pra quem tem dificuldades de implementar os webhooks por falta de suporte em hospedagem compartilhada para configurar mTLS, o Pix.ae agora oferece proxy de callbacks com mTLS.
Pra usar é muito simples: é só prefixar o seu domínio com mtls.pix.ae/. Por exemplo:
Para: https://exemplo.com.br/webhookpix
Use: https://mtls.pix.ae/exemplo.com.br/webhookpix
Obs: no ambiente de homologação, prefixe com mtls-h.pix.ae/
Na realidade no meio da conversa trouxe uma reflexão, que caberia até em off-topic, o que gerou duas linhas de debates. O debate real é sobre a validação no cadastro do Webhook, como está no https://www.notion.so/509e46e40bca45be896f4600f26023ea?v=36eb7c30b76b479c96af9ababe718b69&p=8444fb4eaed2412592510e60a492c924
A validação do mTLS que a parte técnica está pensando, de tempo em tempo, se consolidando, será amplamente debatida aqui no Discord antes, não precisa ser objeto de preocupação.
Lembrando que a fluxo atual, com a segurança adicional de validação será o modelo padrão. As implementações que validam isso no cadastro do Webhook são referências.
a minha pergunta não foi pra cobrar que validem. foi só pra ajudar a fundamentar a tese de que cabe ao PSP oferecer o suporte ao mTLS mas cabe ao EC usar ou não. se não tem como o PSP saber só com um request individual se o EC está exigindo mTLS, acho que bastaria a GN continuar fazendo a validação no momento do cadastro (pro EC saber que tá configurado correto, se quer usar mTLS) e dar a opção de fazer bypass. ou até mesmo inverter o padrão para não exigir o mTLS e só fazer se o teste se o EC passar x-mtls-check: true no PUT
esclarecendo melhor essa pergunta: é possível saber se o EC tá exigindo o mTLS ou se tá ignorando (no próprio callback individual, não em teste prévio)?
e do lado de vocês, é possível "exigir o mTLS" pra decidir se os dados devem ser enviados (no momento do callback em si)?
você quer dizer que cabe ao EC o "require" da validação mTLS e o BACEN não diz explicitamente que o PSP deve validar o PUT?
Se o callback for bastante simplificado, acho que nem precisaria de contrato específico. Se ligar o callback padrão, mTLS full. Se ligar o callback light, não. Mas sim é mais seguro combinar com os russos... digo, com o BACEN, antes.
É que a discussão começou na checagem do teste e foi para o mTLS dos callbacks...
Isso não. Concordo que o regulamento deixa claro o mTLS. O debate precisa ser fomentado.
Sim, mas o ponto era tirar mTLS dos callbacks... aí que ultrapassa o regramento.
mas o risco é do EC. o PSP não deveria ser obrigado a exigir mTLS. deveria ser obrigado a oferecer como opção, apenas
O mTLS tenta mitigar tanto a introdução de informações falsas por um PSP fake, quanto o vazamento de informações que eram de um EC para o outro.
e qual o risco que existe para o PSP em mandar um request pra uma URL sem mTLS que não existe com o mTLS? é o EC que tem que confiar ou não. tinha que ser opção do EC.
a questão do cliente precisar ter mTLS é relativamente fácil de contornar. eu poderia oferecer um serviço que recebe o callback com mTLS e repassa pro EC sem essa exigência, por exemplo 😝
Mas pelo menos será factível. Esse problema de hospedagem compartilhada, de não poder mexer no nginx pois aplicaria-se o mtls em tudo, o cliente não tá tendo pra onde correr...
acho que faz sentido. se for uma renúncia do cliente, a GN nao está deixando de cumprir com a determinação de segurança do BACEN. levem ao Bacen pra ver no que dá.
mas até que o Bacen confirme isso, eu vejo essa possibilidade de bypass (seja no PUT ou no próprio callback) como uma mera facilitação do processo de cadastro do webhook (útil principalmente quando tem um terceiro no processo, além da GN e o EC). não vejo utilidade prática nenhuma enquanto o Bacen exige mTLS nos callbacks
Mas isso acho que só com simplificação mesmo. Se não tem mTLS, teria que vir sem informação quase nenhuma, só um txid para ir lá e dar um GET.
Agora, o ideal mesmo seria o BC flexibilizar o mTLS no callback. Usufrui dessa segurança quem quiser. E aí vejo que entraria perfeitamente no gn/config (caso não haja endpoint específico da spec pra isso)...
Colocando lenha na fogueira, só um parênteses, continuem aí na prosa de vcs pra não embolar os assuntos... Vejo que o debate de flexibilizar o mTLS seria benéfico e cada PSP arbitraria isso junto ao cliente, por exemplo, um contrato adicional de renuncia do mTLS. Nós recomendaríamos então o cliente e vim na Gerencianet a cada Webhook certificar do status, isso é ruim para a infraestrutura, mas tratarmos algum processamento em troca de algum conforto para alguns clientes, pode ser importante para os negócios e plug-ins.
E se o uso de recursos estiver sendo ruim para a Gerencianet, abre-se dialogo com o cliente, situação que ocasionalmente ocorre.
bom, é útil em qualquer um dos dois jeitos. só não entendi o argumento pra ser favorável a ser no PUT e nao no callback.
o argumento a favor de ser no callback é já ficar preparado pra eventual liberação da necessidade do mTLS por parte do BACEN.
outro argumento é permitir que clientes que vão receber callback usando APIs operadas por terceiros (como ERP SaaS) possam adicionar o header quando bem entenderem, sem depender de mudança na API que manda o PUT
