Histórico de mensagens sobre ssl

EXIBINDO CONVERSAS RECENTES:

Texto: ssl
# pix
Avatar discord do usuario nenno7

nenno7

Ver Respostas

com o exemplo disponibilizado em php do pix, é possível gerar em homologação no localhost? ou somente se estiver em hospedagem com ssl ?

# pix
Avatar discord do usuario ezequielsp

ezequielsp

O certificado .pem gerado com o comando "openssl pkcs12...". pode ser utilizado em outra máquina ou na outra máquina eu preciso subir o p12 e rodar o comando "openssl pkcs12..." novamente?

# pix
Avatar discord do usuario oleoessencial

oleoessencial

Ver Respostas

Tem as duas opções (Se for APache) ## Diretório onde hosts virtuais estão armazenados.

SSLCertificateFile /caminho_certificado/server_ssl.crt.pem
SSLCertificateKeyFile /caminho_certificado/server_ssl.key.pem
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /caminho_certificado/chain-pix-prod.crt

## Se preferir deixar apenas uma rota de sua url para notificações você pode adicionar:

SSLVerifyClient none

SSLVerifyClient require
SSLVerifyDepth 3

# pix
Avatar discord do usuario ezequielsp

ezequielsp

Ver Respostas

pode ser porque estou com SSLVerifyDepth 10 ..

# pix
Avatar discord do usuario anoni_mato

anoni_mato

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 😄

# pix
Avatar discord do usuario anoni_mato

anoni_mato

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" 😉

# pix
Avatar discord do usuario joelemanoel

joelemanoel

Ver Respostas

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.

# pix
Avatar discord do usuario joelemanoel

joelemanoel

<@!671762828046106646> No exemplo de vocês o qual eu citei o SSLVerifyDepth, só foi alterado por parte do exemplo e o outro ainda continua.

# sugestões
Avatar discord do usuario anoni_mato

anoni_mato

Ver Respostas

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.

# pix
Avatar discord do usuario anoni_mato

anoni_mato

Ver Respostas

coloca assim:

if ($ssl_client_verify != "SUCCESS") {
charset utf-8;
more_set_headers Content-Type "text/html";
return 400 "No required SSL certificate was sent";
}

se o membro do seu time não entender... aí ele tem que estudar 🙂

# pix
Avatar discord do usuario rubenskuhl

rubenskuhl

Ver Respostas

Talvez colocar na documentação uma versão recomendada, com ssl_verify_client mandatório e server name único, e uma para isso em path específico com optional e aí checagem só no path do webhook.

# pix
Avatar discord do usuario anoni_mato

anoni_mato

mas acho que vc não entendeu o sentido da coisa, Rafael. se é optional, significa que o nginx não vai barrar sozinho o request. ele vai jogar o resultado do mTLS na variavel $ssl_client_verify. aí você rejeita se o mTLS não foi fechado (se não for SUCCESS, dá um 403). o processo é exatamente o mesmo, só muda que a regra não é absoluta (se o mTLS não for fechado, você ainda pode receber requests em outros locations(!)...

# pix
Avatar discord do usuario rafaelturk8530

rafaelturk8530

se ssl_verify_client: optional

# sugestões
Avatar discord do usuario rafaelturk8530

rafaelturk8530

ssl_verify_client on;

# sugestões
Avatar discord do usuario rafaelturk8530

rafaelturk8530

Ver Respostas

é recomendado usar ssl_verify_client optional; o que é uma possível falha de segurança

# pix
Avatar discord do usuario rafaelturk8530

rafaelturk8530

Caros implantamos com ssl_verify_client: on

# pix
Avatar discord do usuario rafaelturk8530

rafaelturk8530

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

# pix
Avatar discord do usuario rafaelturk8530

rafaelturk8530

Ver Respostas

ssl_verify_client on; ou seja always on sem o IF

# pix
Avatar discord do usuario rafaelturk8530

rafaelturk8530

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

# pix
Avatar discord do usuario rafaelturk8530

rafaelturk8530

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