mTLS com NGINX no lado do servidor

[flaviolenz]

Uma ajuda pra quem quer habilitar o mTLSm com NGINX como proxy reverso.
Configurei o ICP Brasil como CA, no caso e tudo funcionou.
Nao sei que tipo de certificado os bancos vao usar, mas vc terá que adicionar a CA deles no arquivo das CAs confiaveis.
A identificacao do client, o NGINX pode passar como Header para o Application Server.
Se alguem tiver mais dicas ou encontrar algum problema nessa configuracao, avisa aí!

server {
    listen 443;
    ssl on;
	
    server_name pix.example.com;
    proxy_redirect off;

    ssl_certificate /path/to/your/public-key/pix.example.com.cer
    ssl_certificate_key /path/to/your/private-key/pix.example.com.key;
    ssl_client_certificate /path/to/your/trusted-ca/icp-brasil.crt;

    ssl_verify_client on;
	
	# not really sure about what these should be:
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK';
    ssl_protocols TLSv1.1 TLSv1.2;
    ssl_verify_depth 5;
    keepalive_timeout 10;
    ssl_session_timeout 15m;

	
	# set headers with client identity or whatever Embedded Variables:
	# http://nginx.org/en/docs/http/ngx_http_ssl_module.html
    proxy_set_header X-SSL-I-DN $ssl_client_i_dn;
    proxy_set_header X-SSL-S-DN $ssl_client_s_dn;
    proxy_set_header X-SSL-SERIAL $ssl_client_serial;
	
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto https;
    location / {
	        # whatever your application server is:
            proxy_pass http://127.0.0.1:8080;
        }
}

[rubenskuhl]

• O uso da CA da ICP-Brasil gera complexidade no lado cliente por causa de problemas de interoperabilidade do certificado A-3. Mas como é só o certificado, isso pode ser gerado em outra máquina e levado para a máquina de produção, então não é tão problemático... mas fica meu depoimento de cliente de que não é o que mais gostaria de usar num PSP.
• O TLS 1.1 me parece obsoleto e deveria ser oferecido ou apenas TLS 1.2 ou TLS 1.2 e 1.3, mas não SSL (qualquer versão), TLS 1.0 ou 1.1.
• O uso dos headers internamente sem necessidade do client configurá-los é bem interessante. Talvez outros parâmetros do certificado também valham a pena passar pra frente conforme o uso do PSP.

[renatofrota]

As recomendações que coletei a esse respeito a última vez que configurei um Nginx (há não muito tempo):

ssl_prefer_server_ciphers on;
ssl_ciphers 'TLS13+AESGCM+AES256:TLS13+AESGCM+AES128:TLS13+CHACHA20:EECDH+AESGCM:EECDH+CHACHA20';
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519:P-521:P-384:P-256;

[flaviolenz]

• O uso da CA da ICP-Brasil gera complexidade no lado cliente por causa de problemas de interoperabilidade do certificado A-3.

A1 mesmo, que a maioria dos estabelecimentos pequemos usam.

[rubenskuhl]

• O uso da CA da ICP-Brasil gera complexidade no lado cliente por causa de problemas de interoperabilidade do certificado A-3.

A1 mesmo, que a maioria dos estabelecimentos pequemos usam.

A1 de fato é bem mais palatável em termos operacionais, mas muita gente tem A3 por causa de outras situações que exigem A3 então o A1 poderia ser um custo adicional para quem já tem um A3.

Um detalhe de quando avaliamos certificados ICP para usos não financeiros é que muitas vezes o certificado está na mão do contador e não da TI da empresa... então vale verificar no seu público-alvo isso também se manifesta, ou não.

[flaviolenz]

Eh nao Rubens. Nao faz sentido ter A3, na verdade, exceto se os requisitos de segurança são muito altos (fora da realidade dos pequenos negocios).
Quem emite Nota Eletronica precisa de um certificado, assim como o contador que precisa resolver outras coisas com INSS, FGTS, credenciamentos, etc.
Se for usar A3, vai precisar comprar no minimo 2.
E o A3 eh praticamente useless para sistemas em nuvem.

Costumo dizer que o contador que faz a empresa comprar A3 eh um incompetente. E se, só ele fica com o certificado, pior ainda.

[rubenskuhl]

Não precisa me convencer sobre os problemas de usar A3 em sistemas automatizados... ;-)

[rturk]

@flaviolenz

Nao sei que tipo de certificado os bancos vao usar, mas vc terá que adicionar a CA deles no arquivo das CAs confiaveis.

Isto é justamente uma regra básica e o princípio do mTLs: usar certificados e/ou cadeias privadas que somente sejam de conhecimento entre as partes.

Se for utilizado uma cadeia pública, o princípio de segurança é quebrado, já que se o client certificate for de domínio público o princípio de criptografia é nulo. Já que qualquer um pode obter esta cadeia.

Sua recomendação gera uma falha de segurança, e não atinge o que é esperado para uma conexão mTLS

ssl_client_certificate /path/to/your/trusted-ca/icp-brasil.crt;

Explico: como a cadeia ICP-Brasil é de amplo conhecimento, se um servidor implantar usando uma cadeia pública, qualquer um poderá acessar o servidor.

[flaviolenz]

Vc esta MUITO equivocado.
Minha resposta a voce na issue #216 endereça essas questões.