Histórico de mensagens sobre mtls em pix

Parceiro, desde domingo passado que recebo este bendito error 403 forbidden , em homologação no retorno do payload . No servidor com leitura de payload no codigo, pensei que era só colocar o mTLS que resolvia 😦

mTLS é mais seguro que validação por IP

Sim mas ai é IP + mTLS, acredito ser bem mais seguro do que somente mTLS.

Ok, estranho, ta igual ao negócio do mTLS ser meio seguro. 😬

Você precisa ter mTLS para validar o retorno.

Vi a conversa a respeito dos ips e pra mim é a melhor segurança junto ao mTLS, a gerencianet divulga o ip dos servidores que fazem as requisições dos webhooks ?

com optional eu estou dizendo "tem casos que exigo mTLS, tem casos que não" e aí eu determino quando é exigido (no location do webhook)

colocar o on só vai antecipar o retorno 400. está generalizando a regra de exigência do mTLS para todo o server {}

se fosse problema "descer" a validação do mTLS pra dentro do location, então eu poderia argumentar que o ssl_verify_client deveria subir pra dentro do http {} no seu caso. e aí vc teria que ter um servidor nginx só pra isso 😄

Rafael, se o seu hostname é webhook.example.com (e ele tem o ssl_verify_client on) enquanto o host example.com não tem nenhuma exigência, eu posso dizer que é "quase mTLS"? Acho que não. Vc vai argumentar "são hosts diferentes, com regras diferentes".

Então se eu tenho um único server {} para o hostname example.com, que aceita requests com/sem mTLS, e valida dentro de um location /webhook, por que o request para /webhook é um "quase mTLS" enquanto o "/" aceita requests sem mTLS? O meu argumento contrário é que "são locations diferentes, com regras diferentes" 😉

O "quase mTLS" foi realmente meio difícil de engolir kkkkk

e concordei com o <@!780500099788701726> em partes (só discordo da parte que ele diz que isso seria "quase mTLS" ou que seria inseguro)

Voltando ao assunto do mTLS em relação ao Nginx. <@!440035527127990273> Não seria legal na documentação da GN estar igual ao do Apache por exemplo? Na documentação do Apache (vide acima), há exemplos tanto para um vHost só para o Webhook como também para um Location só para o Webhook. Assim poderia ser implementado o ssl_verify_client on; e ssl_verify_client optional; a preferir pelo usuário.

e eu vou parar de discutir isso pq ter que aceitar que alguém suporta a existência de um "quase mTLS" não é saudável pra mim. a pessoa precisa entender que 2 requests podem ser enviados para o mesmo server {} e um ter mTLS e o outro não. se ela não entende.. paciência.

sugira pra GN que coloquem uma explicação de como fazer o webhook em server{} exclusivo, então. pode até recomendar. só não podem considerar que é o único setup válido. seria tão burrice que eles inclusive testam se o request passa sem mTLS primeiro, então a exigência de mTLS tá sendo cumprida.

cara.. não terá mTLS nos requests enviados sem o certificado. será mTLS quando tiver o certificado. se pra vc isso é "quase mTLS", questão de interpretação sua. a documentação diz que é e o request não vai chegar onde tem que chegar pq vc barrou, ainda no Nginx. então.... não vamos chegar a lugar nenhum discutindo uma coisa que tá documentada e provada que é mTLS só pq vc acha que não é. 🙂

é quase mTLS

agora isto não é mTLS

Lembrando que hostname exclusivo num ambiente de virtual host é uma recomendação light... não é por exemplo exigir uma VM. Apesar do mTLS praticamente ter isso como consequência.

no formato atual se eu consigo entrar nos servidores de vcs como optional é quase mTLS