aboutsummaryrefslogtreecommitdiff
path: root/provedor/cert.md
diff options
context:
space:
mode:
Diffstat (limited to 'provedor/cert.md')
-rw-r--r--provedor/cert.md129
1 files changed, 91 insertions, 38 deletions
diff --git a/provedor/cert.md b/provedor/cert.md
index d66061f..10ff30c 100644
--- a/provedor/cert.md
+++ b/provedor/cert.md
@@ -1,69 +1,109 @@
[[!meta title="Gestão de chave e certificado SSL"]]
-O presente processo trata da gestão de chave e certificado SSL para conexões ditas seguras entre servidores do Coletivo.
+O presente processo trata da gestão de chave e certificado SSL para conexões
+ditas seguras entre servidores do Coletivo.
Considerações
-------------
O Coletivo reconhece que
- 1. O protocolo HTTPS possui sérios problemas de design, impedindo por exemplo que diferentes certificados possam ser utilizados num mesmo IP.
-
- 2. A indústria da certificação digital representa um sério risco de segurança e uma [imposição tecnocrata](http://lair.fifthhorseman.net/~dkg/tls-centralization/) à utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e pode a qualquer momento [ser utilizada por governos ou corporações para forjar certificados autenticados](http://web.monkeysphere.info/news/internet_secret_backdoor/) e com isso [grampear](https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack) a conexão entre usuários/as e computadores.
-
- 3. Idealmente, a atitude a ser tomada por um coletivo técnico radical deveria de não utilizar a indústria da certificação como meio de assegurar a identificação de seus serviços e máquinas. Deveria, ao invés disso, utilizar apenas esquemas abertos como
+1. O protocolo HTTPS possui sérios problemas de design, impedindo por exemplo
+ que diferentes certificados possam ser utilizados num mesmo IP.
+
+2. A indústria da certificação digital representa um sério risco de segurança e
+ uma [imposição tecnocrata](http://lair.fifthhorseman.net/~dkg/tls-centralization/) à
+ utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e
+ pode a qualquer momento [ser utilizada por governos ou corporações para forjar
+ certificados autenticados](http://web.monkeysphere.info/news/internet_secret_backdoor/) e
+ com isso [grampear](https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack)
+ a conexão entre usuários/as e computadores.
+
+3. Idealmente, a atitude a ser tomada por um coletivo técnico radical deveria
+de não utilizar a indústria da certificação como meio de assegurar a
+identificação de seus serviços e máquinas. Deveria, ao invés disso, utilizar
+apenas esquemas abertos como
a. Certificadores Comunitários como o [CACert](http://cacert.org).
b. [Monkeysphere](http://web.monkeysphere.info).
- c. A simples verificação da impressão digital dos certificados mediante algum vínculo direto (por exemplo, troca de fingerprints ou validação via OpenPGP) com os/as administradores das máquinas.
-
- 4. No entanto
- a. Nem todos os navegadores acompanham, por padrão, certificados de entidades comunitárias. É o [caso do CACert](https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status).
- b. A adoção de ferramentas livres para HTTPS ainda está muito longe de se tornar comum. No presente, haveria pouca possibilidade de que uma metodologia livre seja eficiente. Ao invés disso, haveria um involuntário incentivo aos/às usuários para que aceitem certificados considerados como inválidos pelos navegadores, o que pode facilitar ainda mais o grampo: se os usuário aceitam qualquer certificado, então não haveria diferença entre eles aceitarem o certificado verdadeiro do falso.
+ c. A simples verificação da impressão digital dos certificados mediante
+ algum vínculo direto (por exemplo, troca de fingerprints ou validação via
+ OpenPGP) com os/as administradores das máquinas.
+
+4. No entanto
+ a. Nem todos os navegadores acompanham, por padrão, certificados de
+ entidades comunitárias. É o
+ [caso do CACert](https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status).
+ b. A adoção de ferramentas livres para HTTPS ainda está muito longe de se
+ tornar comum. No presente, haveria pouca possibilidade de que uma metodologia
+ livre seja eficiente. Ao invés disso, haveria um involuntário incentivo aos/às
+ usuários para que aceitem certificados considerados como inválidos pelos
+ navegadores, o que pode facilitar ainda mais o grampo: se os usuário aceitam
+ qualquer certificado, então não haveria diferença entre eles aceitarem o
+ certificado verdadeiro do falso.
Conclusões
----------
Portanto, o Coletivo conclui que
- 1. No momento, ainda importante ter um certificado assinado pela indústria da certificação, isto é, por uma entidade autorizada pelo cartel do SSL.
- 3. A autoridade certificadora a ser utilizada deve obedecer alguns critérios básicos:
- a. Não é diretamente conectada a uma agência governamental.
- b. Não possui problemas políticos óbvios.
- c. Cujo certificado raíz não está encadeado com certificados que não satisfazem os critérios acima.
- 2. Dada a sua insuficiência, tal certificação corporativa não deve ser o único meio para a validação dos certificados SSL e assim esquemas alternativos como o [Monkeysphere](http://web.monkeysphere.info) devem ser utilizados e encorajados, de modo que haja um aumento da massa crítica necessária para tornar tais métodos mais populares. O mesmo se aplica para a verificação da impressão digital dos certificados.
+1. No momento, ainda importante ter um certificado assinado pela indústria da
+ certificação, isto é, por uma entidade autorizada pelo cartel do SSL.
+3. A autoridade certificadora a ser utilizada deve obedecer alguns critérios básicos:
+ a. Não é diretamente conectada a uma agência governamental.
+ b. Não possui problemas políticos óbvios.
+ c. Cujo certificado raíz não está encadeado com certificados que não satisfazem os critérios acima.
+2. Dada a sua insuficiência, tal certificação corporativa não deve ser o único
+ meio para a validação dos certificados SSL e assim esquemas alternativos como o
+ [Monkeysphere](http://web.monkeysphere.info) devem ser utilizados e
+ encorajados, de modo que haja um aumento da massa crítica necessária para
+ tornar tais métodos mais populares. O mesmo se aplica para a verificação da
+ impressão digital dos certificados.
Utilização de HTTPS
-------------------
-Conforme o documento [Best Practices for Online Service Providers](https://www.eff.org/wp/osp), o Coletivo concorda que conexões HTTPS devem ser utilizadas o máximo possível.
-
- 1. O Coletivo utilizará HTTPS apenas em servidores confiáveis que onde seja possível armazenar as chaves SSL de forma criptografada.
- 2. Utilizar, quando possível, cabeçalhos [HSTS](http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers).
- 2. Considerando que o certificado vale apenas para um único domínio e seus subdomínios (isto é, o domínio principal do Coletivo), o Coletivo utilizará HTTPS por padrão apenas:
- a. Para serviços, sistemas e sítios que utilizem o domínio principal do Coletivo, quando não houver impedimento técnico para tal.
- b. Para outros domínios desde que solicitado pela parte hospedada.
- 3. Considerar a utilização de [entradas CAA no DNS](https://links.fluxo.info/tags/caa).
+Conforme o documento [Best Practices for Online Service
+Providers](https://www.eff.org/wp/osp), o Coletivo concorda que conexões HTTPS
+devem ser utilizadas o máximo possível.
+
+1. O Coletivo utilizará HTTPS apenas em servidores confiáveis que onde seja
+ possível armazenar as chaves SSL de forma criptografada.
+2. Utilizar, quando possível, cabeçalhos
+ [HSTS](http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers).
+2. Considerando que o certificado vale apenas para um único domínio e seus
+ subdomínios (isto é, o domínio principal do Coletivo), o Coletivo utilizará
+ HTTPS por padrão apenas:
+ a. Para serviços, sistemas e sítios que utilizem o domínio principal do
+ Coletivo, quando não houver impedimento técnico para tal.
+ b. Para outros domínios desde que solicitado pela parte hospedada.
+3. Considerar a utilização de [entradas CAA no DNS](https://links.fluxo.info/tags/caa).
Implementação
-------------
A implementação de HTTPS também deve obedecer a uma suite bem estabelecida.
-Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que provém [Perfect Forward Secrecy (PFS)](https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy).
+Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que
+provém [Perfect Forward Secrecy
+(PFS)](https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy).
Outros protocolos
-----------------
-A utilização do SSL também deve se estender a outras plataformas, como por exemplo email (via TLS) desde que possível e que atenda critérios análogos aos anteriores.
+A utilização do SSL também deve se estender a outras plataformas, como por
+exemplo email (via TLS) desde que possível e que atenda critérios análogos aos
+anteriores.
Escolha de autoridade certificadora
-----------------------------------
Dentre as autoridades certificadoras, o Coletivo escolhe a [Gandi](https://gandi.net) por:
- 1. Atender os critérios acima estabelecidos.
- 2. Diferentemente de outras empresas, possui uma preocupação com privacidade e comprometimento com serviços de internet alternativos e independentes.
- 2. [Contribuir com projetos de código aberto](https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports ), vide [lista](http://en.gandi.net/supports/).
+1. Atender os critérios acima estabelecidos.
+2. Diferentemente de outras empresas, possui uma preocupação com privacidade e
+ comprometimento com serviços de internet alternativos e independentes.
+2. [Contribuir com projetos de código aberto](https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports ),
+ vide [lista](http://en.gandi.net/supports/).
No entanto, é importante notar as limitações envolvidas na escolha do Gandi:
@@ -113,11 +153,24 @@ Responsabilização
O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo deve:
- 1. Caso o Coletivo disponha de recursos financeiros, manter certificado SSL assinado para `*.dominio` via [Gandi](https://gandi.net). O Coletivo arcará com os custos. Caso contrário, adotar a certificação [CACert](http://www.cacert.org/) como padrão.
- 2. Manter formas alternativas de certificação via:
- a. [Monkeysphere](http://web.monkeysphere.info).
- b. A simples verificação da impressão digital dos certificados mediante algum vínculo direto (por exemplo, troca de fingerprints ou validação via OpenPGP) com os/as administradores das máquinas.
- c. Manter, na medida do possível, o público informado das mundanças nas chaves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página pública e atualizada sobre os atuais certificados utilizados e também informar grupos e pessoas próximas sobre mudanças em certificados.
- 3. Opcionalmente, manter também a assinatura via [http://www.cacert.org/ CaCert].
- 4. Evitar o vencimento da validade dos certificados, utilizando para isso métodos como o [http://prefetch.net/articles/checkcertificate.html ssl-cert-check], implementado por exemplo no [http://git.sarava.org/?p=puppet-ssl.git;a=summary puppet-ssl].
- 5. Observar a aplicação dos critérios e determinações do presente processo, operando conjuntamente com o GT de [wiki:Camadas Configuração de sistemas padronizada e centralizada].
+1. Caso o Coletivo disponha de recursos financeiros, manter certificado SSL
+ assinado para `*.dominio` via [Gandi](https://gandi.net). O Coletivo arcará com
+ os custos. Caso contrário, adotar a certificação
+ [CACert](http://www.cacert.org/) como padrão.
+2. Manter formas alternativas de certificação via:
+ a. [Monkeysphere](http://web.monkeysphere.info).
+ b. A simples verificação da impressão digital dos certificados mediante
+ algum vínculo direto (por exemplo, troca de fingerprints ou validação via
+ OpenPGP) com os/as administradores das máquinas.
+ c. Manter, na medida do possível, o público informado das mundanças nas
+ haves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página
+ ública e atualizada sobre os atuais certificados utilizados e também informar
+ rupos e pessoas próximas sobre mudanças em certificados.
+3. Opcionalmente, manter também a assinatura via [http://www.cacert.org/ CaCert].
+4. Evitar o vencimento da validade dos certificados, utilizando para isso
+ métodos como o [http://prefetch.net/articles/checkcertificate.html
+ ssl-cert-check], implementado por exemplo no
+ [http://git.fluxo.info/puppet-ssl puppet-ssl].
+5. Observar a aplicação dos critérios e determinações do presente processo,
+ operando conjuntamente com o GT de [wiki:Camadas Configuração de sistemas
+ padronizada e centralizada].