Serviço em linguagem Dart: nome de domínio, SSL

Nome do domínio

A última vez que acabamos em que no container docker lançou um servidor web NGINX, distribuindo arquivo index.html estático. Desta vez, vamos expandir a funcionalidade do servidor da web adicionando criptografia de dados e redirecionamentos forçados de http para https.







Para fazer isso, você precisa resolver um problema organizacional: o fato é que o certificado de criptografia só pode ser obtido para um nome de domínio ou um grupo de nomes. Por esse motivo, vamos a qualquer um dos registradores de nomes de domínio e escolhemos um nome que corresponda à marca (propósito, slogan, etc.) sem esquecer o propósito dos nomes de domínio de nível superior . No meu caso, dartservice.ru é perfeito . Durante o processo de registro, você deve preencher o formulário de informações do proprietário incluindo nome, endereço postal e e-mail. Então você precisa ir ao gerenciamento de registros DNS no painel de controle do registrador e fazer três registros:

• Pelo menos dois registros NS. Esses são os nomes dos servidores de nomes de domínio do registrador e seus nomes são fornecidos pelo registrador ao adquirir um nome de domínio.
• Uma gravação. É um registro direto da relação entre o nome de domínio e o endereço IP do servidor.

No meu caso, os registros DNS têm a seguinte aparência:







Tendo feito isso, você não deve esperar resultados imediatos. A troca de informações entre os servidores DNS geralmente leva de 1 a 12 horas para a zona RU. Então ... adicione outro teste ao projeto /test/http/client.http

SSL

Em geral, é claro, SSL é um nome desatualizado. As novas versões do protocolo são chamadas de TLS 1.0 ... 1.3, mas o mecanismo permanece o mesmo - criptografia de dados durante a transição entre o protocolo da camada de aplicação (no nosso caso, HTTP) e o protocolo da camada de transporte (TCP / IP). Na verdade, você precisa de:

• Obtenha um certificado de criptografia de uma autoridade de certificação especial, confirmando a propriedade do domínio correspondente.
• NGINX.
• .
• , http https.

No momento, é geralmente aceito o uso de certificados gratuitos emitidos automaticamente pelo serviço Let's encrypt . Uma das limitações de tais certificados é o período de validade. Apenas 90 dias. Depois disso, o certificado deve ser obtido novamente. Para a obtenção automática (sem intervenção humana) de certificados, foram desenvolvidos o protocolo e aplicativos ACME que realizam periodicamente ações para confirmar a propriedade do domínio. Vamos criptografar recomendações usando o aplicativo certbot . Ele é escrito em python e requer seu próprio repositório e o python3 para ser instalado. Portanto, usaremos um contêiner docker com certbot instalado a partir do registro DockerHub . Vamos selecionar a versão estável mais recente do certbot / certbot: v1.5.0...



Agora vamos descobrir o mecanismo para obter um certificado usando o protocolo ACME:

• No primeiro lançamento, o Certbot gera uma chave privada e pública e, em seguida, cria uma conta de administrador de domínio no serviço Let's encrypt, transferindo a chave pública e as informações de domínio.
• Depois disso, vamos criptografar envia uma mensagem, que certbot deve assinar com uma chave privada e devolvê-la.
• O ertbot deve colocar no servidor um arquivo especial disponível para leitura em dartservice.ru/.well-known/acme-challenge para confirmar a propriedade deste domínio.
• Certbot redige um pedido de certificado , envia-o para Let's encrypt e recebe um certificado para o domínio em troca.

Vamos adicionar o contêiner do aplicativo ao nosso script docker-compose.yaml :







Novo parâmetro aqui comand : aqui está o comando que será executado após o contêiner iniciar. Neste caso, certifique-se apenas (obtenha um certificado). A obtenção do certificado ocorre online, ou seja, é necessário responder de forma consistente a várias perguntas. Passar sinalizadores após o comando permite que você faça isso sem intervenção humana: --webroot (método de confirmação) --webroot-path = / usr / share / nginx / html / letsencrypt (caminho onde os arquivos de confirmação de propriedade de domínio serão colocados) --email admin @ email.com (e-mail do administrador de domínio) - concordar(aceitamos os termos do contrato de licença) --no-eff-email (não relatar e-mail para desenvolvedores certbot) -d dartservice.ru (lista de domínios).



Vamos configurar o contêiner NGINX: As







mudanças aqui são para abrir a porta https (443) e montar as pastas com o certificado SSL e os arquivos de confirmação de propriedade do domínio.



Um parâmetro importante é a pasta de chaves Diffie-Hellman. Resumindo: esta chave é necessária para a troca segura de chaves de criptografia entre o servidor e o cliente ao estabelecer uma conexão. Mais detalhes aqui .



Vamos gerar essa chave, mas enfrentaremos o seguinte problema: a chave é criada pelo programa openssl, é um utilitário de console Linux que dificilmente aparecerá em nossa máquina Windows. A solução mais simples é executar nosso script, ir para o console do contêiner da web e criar uma chave lá, passando a pasta do host montada para o contêiner no caminho de saída do arquivo:



Execute o script:

docker-compose up -d

Solicitamos uma lista de contêineres em execução:

docker-compose ps

Abra o console do contêiner:

docker exec -it srv_web_1 bash

Começamos a gerar a chave na pasta de configuração NGINX (que, como lembramos, é montada a partir do host):

openssl dhparam -out /etc/nginx/conf.d/dhparams.pem 2048

Mova a chave para ./dhparams/dhparam-2048.pem



Saia do console do contêiner Ctrl-D , pare o script:

docker-compose down

Agora vamos mudar a configuração do NGINX ./conf.d/defaulf.conf :







Adicione um novo local ^ ~ /.well-known/acme-challenge para servir arquivos estáticos da pasta / usr / share / nginx / html / letsencrypt . É aqui que os arquivos de confirmação do certbot serão colocados. Vamos configurar um redirecionamento para todas as outras solicitações para https.



Tudo está pronto para o primeiro certificado SSL.



Vamos copiar nosso projeto para o VPS em uma nova pasta / opt / srv_1 / com o comando:

scp -r ./* root@91.230.60.120:/opt/srv_1/

Vamos conectar do VScode via SSH ao VPS.



Vamos para a pasta do servidor em execução:

cd /opt/srv_0/

e pare o script:

docker-compose down

Agora vá para a nova pasta do servidor cd / opt / srv_1 / e execute o script:

docker-compose up

No console, vemos que o certbot criou um arquivo de confirmação zeS4O87S6AfRQ3Kj4MaBlBFZx3AIiWdPn61DwogDMK4 e relatou isso ao serviço Let's encrypt, que, por sua vez, solicitou esse arquivo de quatro endereços IP diferentes e emitiu um certificado. O certificado na forma de uma cadeia completa e uma chave privada foram salvos na pasta correspondente. O certificado é válido por 90 dias (até 05.10.2020).



É hora de criar um segundo local para uma conexão segura na configuração NGINX no servidor ./conf.d/defaulf.conf :







Reinicie o script

docker-compose restart

Vamos ver como o navegador reage ao nosso certificado: O







Google Chrome está feliz com nosso certificado. Agora a tarefa é mais complicada - vamos testar a segurança e disponibilidade para diferentes navegadores de nossa conexão SSL https://www.ssllabs.com/ssltest/ . Insira o endereço e obteremos o resultado:







está tudo bem com o certificado e a troca de chave (graças a Diffie-Hellman), mas o robô de teste baixou a marca ("B" é "4" em nossa opinião) por suportar os protocolos TLS1.0 e TLS1.1 desatualizados ... Não é difícil desabilitá-los na configuração NGINX, no entanto, olhando mais a fundo o relatório de teste, vemos que, por exemplo, os navegadores de alguns dispositivos móveis neste caso não conseguirão se conectar:











Existem várias tarefas de serviço a serem executadas.



O número de tentativas de obter um certificado para um domínio não deve exceder 5 em 7 dias. Depois disso, o serviço Let's encrypt pode nos bloquear. No entanto, execute o script durante o desenvolvimento sempre que o certbot tentar fazer isso, portanto, no script docker-compose.dev.yaml, altere o parâmetro de comando do contêiner do certbot :







O sinalizador --dry-run é um teste executado sem obter um certificado.



Vamos escrever um teste: github de







código-fonte .

Conclusão

Portanto, nesta etapa, protegemos as comunicações entre o servidor e os aplicativos cliente e ensinamos os navegadores a "confiar" em nosso domínio.



No próximo artigo, vamos escrever uma página da web flutuante com uma contagem regressiva para o lançamento de nosso serviço, coletá-la e colocá-la em nosso servidor.