Histórico de mensagens sobre mtls em sugestões

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

eu acho que faz mais sentido o nome ser x-mtls-bypass. se o padrão é checar, o bypass é que deve ser sinalizado (e setado true) e não usar um valor "false" pra negar o que é padrão

Integrador precisa validar por exemplo se o webhook é de test ou transacional para enviar o x-mtls-check da forma correta.

O BACEN parece bem propenso a continuar com mTLS no webhook na v2. Porém, parece haver espaço para na v3 simplificar as webhook para notificação apenas, e aí em algo que só tenha notificação, se quem mandou o aviso foi o PSP ou o Gasparzinho, dá na mesma.

e se o BACEN resolver tornar o mTLS opcional (vai que....) o lado que recebe o callback vai poder dar o bypass de forma mais fácil do que alterando o script que consome a API

isso dá mais flexibilidade pra um integrador que recebe os webhooks de ligar/desligar o mTLS bypass sem interferência no script que tá fazendo o envio do PUT

hoje:
- GN envia "callback" simulado sem certificado (se for aceito pelo integrador, é uma falha; dá "break" aqui)
- GN envia "callback" simulado com certificado (que deve retornar 200)

poderia ficar assim:
- GN envia "callback" simuilado sem certificado:
--> se receber de volta 200 + um header x-mtls-bypass: true, tá ok e dá break;
--> se receber de volta 200 sem o header, é falha e dá break;
--> se receber de volta 4xx, segue adiante
- GN envia "callback" simulado com certificado (que deve retornar 200)

Pelo que entendi o fluxo seria:
PUT /webhook
Headers:["x-mtls-check": false]
----
Webhook de teste é enviado sem certificado e configurado normalmente.
---
Webhook normal é enviado com o certificado.

assim poderia ao menos testar se responde 200 sem o mTLS

a proposta da GN é passar o header x-mtls-check: false na hora de fazer o PUT /webhook. esse header poderia ser enviado pelo servidor/script que recebe os callbacks

Eu não entendi o raciocínio. Se na hora da notificação eu tenho que validar o mTLS de qualquer forma, melhor que a validação aconteça no cadastro da URL, mesmo, como está hoje. É um benefício gigante eu não precisar gerar o acionamento de webhooks pra saber se a configuração tá correta!

Espera-se que sim. Ele vai conseguir cadastrar a URL. Quando for notificado, nós enviaremos o certificado. Isso abre caminhos para que o integador decida como validar que a requisição que está chegando é realmente da Gerencianet. Talvez ele não possa alterar uma configuração do nginx por estar sendo compartilhado com outras aplicações, porém talvez ele possa "ensinar" o nginx a repassar essa informação pra dentro da aplicação e validar manualmente via código.

A ideia da validação durante o PUT é pra ajudar a validar o ambiente mTLS, não seria, digamos, mandatória.

Desabilitar o check mas ainda exigir mTLS nas efetivas notificações ajuda em algo o integrador com problemas em ambientes compartilhados ?

<@!793123559874494465> poderia dissertar melhor sobre isso: "- Permitir o cadastro da URL no PUT /webhooks sem validação ativa do mTLS no momento do consumo;"?

a falha de segurança não existe se a GN valida que apenas requests com mTLS serão respondidos, Rafael. entendo que você queira sugerir um exemplo onde o ssl_verify_client seja on, mas isso só é possível em server {} exclusivo para webhooks. o exemplo dado é para um server {} onde requests de webhook (mTLS) e outros requests coexistem, e não há nada de inseguro nisso, especialmente depois de passar por validação.