Termos mais procurados:
Vários métodos que não mTLS foram sugeridos para o BACEN, e dá para ver no GitHub do BACEN as discussões sobre isso... o ponto é que definido um padrão, é para ser seguido. O momento de discussões sobre isso existiu, passou, e agora é o de implementar como padronizado.
Da um certo trabalho, pq o mTLS trabalha na camada de infra/webserver, então ativar um gateway, nesse caso, não basta codificar na linguagem escolhida, mas tbm mexer em uma outra camada...
Eu gosto do mTLS, digo da ideia pq ainda não implementei, no webhook, já que um medo q eu sempre tive, era o json vir de uma fonte não confiável, e aí eu tinha que ficar fazendo algumas requests para garantir a autenticidade do json...
Usando por mTLS, fica mais confiável da onde está vindo o json/request do webhook...
Isso é viés de quem depende de ambientes que não suportam mTLS com CA própria de cara. Você quer que o padrão nivele por baixo para o seu conforto ao invés de atender requisitos do maior sistema de transações financeiras já criado.
Oi <@!177276428675448832> tudo bem? 🙂
O campo aceita ambos os valores, true e false.
Adição do header x-skip-mtls-checking no endpoint PUT /v2/webhook/:chave para permitir o cadastro de servidores webhooks sem validação de mTLS durante o consumo.
Regras explicadas:
Se o parâmetro não for enviado, iremos validar mTLS;
Se o parâmetro for enviado e valor igual à true, não validaremos mTLS ;
Se o parâmetro for enviado e valor diferente de true, validaremos mTLS;
Salientamos que a Gerencianet continuara a fornecer a comunicação com mTLS, ou seja, na comunicação da notificação nada mudou. O POST entre Gerencianet e EC continua enviando o certificado.
Para mais detalhes verifique o roadmap no link https://gnetbr.com/rke4baDVyd
Sugestão: alinhar melhor com a equipe as informações a respeito dos [novos] recursos e exigências [removidas] para consumo da API Pix. Por ex: as informações a respeito da necessidade ou não de mTLS no PUT /webhook, bem como no recebimento dos callbacks, estão desencontradas lá no canal <#❖pix>. Tem membros da equipe GN dizendo A e outros membros dizendo B.
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.
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.
