Histórico de mensagens em pix

ou seja.. foi feito tudo bonitinho.. mas alguém pode ignorar isto

se o nginx está configurado como ssl_verify_client optional; é OPTIONAL.

🙂

Agora pensem como Hackers.. vcs tem todo o tempo do mundo..

Mas nem fechar TLS é mais recusa do que fechar TLS e dar 403 no HTTP.

Pra ficar ainda mais TOP, é só colocar uma camera para o seu sistema ler o BRCode do Cliente no celular dele e abrir a porta sem precisar digitar 🙂

Sim eu entendi..

A primeira necessariamente tem de dar 403 as proximas não.

"A Gerencianet irá fazer 2 requisições para o seu domínio(servidor).

1ª Requisição: Vamos certificar que seu servidor esteja exigindo uma chave pública da Gerencianet. Isso será feito ao enviar uma requisição sem certificado e seu servidor não deverá aceitar a requisição. Uma vez respondido com a recusa será enviado a 2º requisição.

2ª Requisição: Enviaremos a notificação junto com a nossa chave pública, o seu servidor que deve conter a chave pública disponibilizada deverá realizar o "Hand-Shake" e assim a comunicação ser estabelecida."

<@!780500321994539068> acho que sim.

ssl_verify_client on; ou seja always on sem o IF

Eu acho que recusar o TLS na falta de client-certificate é melhor mesmo... mas se fechar o TLS tomar um HTTP 403 poderia ser também, mas o melhor é nem deixar fechar para nem receber informação que potencialmente não se quisesse receber.

SE eu puder recomendar minha solução seria.

if ($ssl_client_verify != SUCCESS) {
return 403;
}

consigo imaginar que isto é o motivo de ter

Caso contrário implementamos o certificado, handshake mas um bad actor poderia ignorar toda esta sequencia, já que está optional e não on ?

Conseguem elaborar o porque disto?

Se formos seguir a recomendação de mTLS à risca ssl_verify_client teria que ser on; ou seja Always on?

Caros amigos da GN estou curioso porque a recomendação de usar ssl_verify_client optional;

O PIX realmente abre muitas portas rs 😉