Posts

  • Desligando a tela ao bloquear o Xfce

    Como quem acompanha o blog sabe, utilizo exclusivamente Linux no desktop há quase quatro anos. Optei por muito tempo pelas versão estáveis do Debian (Squeeze/Wheezy na época) no notebook, passando a utilizar o Xubuntu (versões LTS, 12.04 e 14.04, com suporte extendido, mas de apenas três anos invés de cinco, diferente do Ubuntu) no computador de trabalho. Considerando a usabilidade do Xubuntu maior do que a do Debian com Xfce, foi natural que passasse a utilizar o primeiro também no meu notebook pessoal.

    Questiono a usabilidade do Debian porque é necessário configurar manualmente muitas das coisas que já vem habilitadas por padrão no Xubuntu. Coisas que podem parecer bobas, como o “clique com toque” e “clique com o botão direito, com toque de dois dedos” no touchpad fazem muita diferença. E, tendo voltado pro Debian (Jessie, a atual versão estável) recentemente, um destes detalhes voltou a me irritar profundamente: o fato da tela não ser desligada quando bloqueio o sistema (exigindo senha para utilizá-lo novamente).

    Como não poderia deixar de ser, se você procurar por isso encontrará soluções esdrúchulas, como a recomendação de se criar um script que chama o comando de salvar a tela, espera um tempo e chama outro comando para desligá-la depois. E o pior de tudo, é que como se já não bastasse você precisar de um script para fazer isto em pleno ano de 2016, ele simplesmente não funciona! Por algum motivo a tela liga sozinha pouco tempo depois.

    Felizmente, há uma solução simples, ainda que não tão intuitiva, para o problema. Por padrão, o Debian (pelo menos com Xfce) utiliza o XScreenSaver para gerenciamento de proteção de tela, e ele é o responsável por desligá-la após bloquear a sessão. Acessando sua configuração através do menu “Settings -> Screensaver” (ou acessando a opção “Screensaver” do “Settings Manager”), é necessário escolher as seguintes opções:

    • Mode: Blank Screen Only;
    • Lock Screen After: esta opção não é obrigatória e não irá influenciar quando a tela for bloqueada propositalmente, apenas após o computador ter ficado inativo pelo tempo configurado nas opções anteriores.

    E o problema todo está nesta última tela. Note que há a opção Quick Power-off in Blank Only Mode, que é exatamente o que estávamos procurando. Entretanto, a mesma depende da opção Power Management Enabled estar marcada, muito embora ela fique disponível para ser ativada/desativada, estando a opção anterior selecionada ou não! Meu professor de “Interface Homem-Máquina”, Frederico Bida, provavelmente infartaria vendo uma coisa dessas.

    Como pode ser percebido, deixei as demais opções de energia em 1440 minutos (24 horas), simplesmente porque não quero que o XScreenSaver controle quando o computador deve ser suspenso/desligado, já que isto fica a cargo do gerenciador de energia do Xfce. A intenção é que ele se preocupe apenas com o que realmente interessa, que é o fato de desligar corretamente a tela quando a mesma for bloqueada.

  • O lamentável estado dos softwares Freeware

    Sempre fui aficionado em conhecer e experimentar softwares novos. Ainda criança, um dos meus passatempos preferidos era passar o fim de semana (em uma conexão discada de 14.4 Kbps) navegando entre as seções, principalmente de Rede e Internet e Utilitários, do Superdownloads - que pasmem, existe desde 1998. Não demorou para que eu descobrisse em quais condições os softwares eram ali distribuídos: havia versões de demonstração (Demo), assim como as pagas porém gratuitas para testar por tempo limitado (Shareware). Destas, a categoria que mais me atraia era a dos gratuitos sem limitação de tempo ou funcionalidade: os Freeware.

    Foi nesta época que conheci softwares como o mensageiro multi-protocolo Miranda IM (que na época provavelvemente ainda se chamava Miranda ICQ, nome que foi mudado no final de 2002). Ele não é freeware e sim opensource, mas vale a pena citá-lo por conta de um bug extremamente curioso (e irritante) das primeiras versões: às vezes, quando utilizado com o protocolo do MSN (mais tarde chamado de Windows Messenger), ele perdia a habilidade de enviar mensagens mas as continuava recebendo. Se estivesse, por exemplo, discutindo com alguém, a pessoa poderia te xingar repetidamente e te chamar de covarde… E você nada poderia fazer.

    Nestas incursões no mundo dos softwares freeware, conheci muitas alternativas bacanas (todas para Windows), como o Resource Hacker, que permite editar arquivos executáveis, e o Spybot Search & Destroy, removedor de adwares/spywares. Tenho um grande carinho pelos softwares da AnalogX, em especial, por terem criado exemplares pequenos porém de grande utilidade, como o AnalogX Capture, AnalogX Proxy e AnalogX Vocal Remover. O mais importante a ser destacado aqui é que estes softwares citados são exceções, por terem se mantido funcionais e sem pegadinhas através do tempo.

    O grande problema com os softwares freeware, que pode não estar aparente, é seu modelo de negócio. Se é um produto grátis, sem custo para o usuário final, quem banca seu desenvolvimento, distribuição e manutenção? É justamente ao se tentar gerar receita com estes programas, normalmente depois de já serem conhecidos pelo público, é que o processo desanda. O μTorrent, por exemplo, tentou adicionar anúncios e chegou a instalar um minerador de criptomoedas, em uma tentativa desesperada de gerar receita.

    Alguns casos mais graves, como o do BS Player, chegaram a impossibilitar sua utilização caso o usuário removesse os adwares que acompanhavam o instalador. A situação fica ainda mais crítica quando isto se torna tão corriqueiro que as pessoas simplesmente se conformam, como foi o caso de um amigo e colega de trabalho. Ele me disse que usava o KMPlayer, mas que parou quando o instalador passou a adicionar um monte de porcarias indesejadas. E qual foi sua reação? Passar a usar outro player gratuito “enquanto ele não começar a adicionar coisas inúteis ao instalador”.

    A parte reconfortante desta história toda é que há uma alternativa: utilizar software livre. Pode parecer clichê ou “coisa de quem usa Linux”, mas não é. O excelente player de vídeo VLC (o “Chuck Norris” dos media players), por exemplo, roda em praticamente qualquer sistema operacional existente. Sem ter de ficar instalando incontáveis codecs (nenhuma saudade do K-Lite Codec Pack), o VLC toca praticamente qualquer arquivo de mídia existente (inclusive imagens ISOs sem precisar montá-las). E se alguém algum dia tentasse incluir anúncios ou outros softwares inúteis no instalador, com certeza outra pessoa empacotaria e distribuiria uma versão “limpa” do mesmo.

  • Obtendo nota máxima no teste da Qualys SSL Labs

    Buscando por “ssl test” no Google, os dois primeiros resultados encontrados correspondem a duas ferramentas muito úteis. Uma, o SSL Checker da SSL Shopper, fornece informações básicas sobre o certificado. Um certificado da StartSSL que tenha sido gerado com as dicas do último post resulta em uma saída parecida com esta:

    As informações estão dispostas de forma bem didática, mas ainda vale a pena comentar sobre cada item:

    • ssl.myhro.net resolves to 52.2.85.74: primeiro teste, exibindo o IP resolvido. Esta informação é importante para termos certeza que o teste está sendo realizado no servidor correto, o que poderia não acontecer no caso de uma entrada DNS alterada recentemente que ainda estivesse em cache;
    • Server Type: nginx/1.4.6 (Ubuntu): informações sobre o servidor, que no caso é o nginx 1.4.6, versão presente no Ubuntu 14.04;
    • The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed): destaca a importância do encadeamento correto dos certificados, com a presença dos certificados intermediários, também citada no post sobre a StartSSL;
    • The certificate was issued by StartCom: entidade certificadora responsável por emitir e assinar o certificado;
    • The certificate will expire in 365 days: tempo restante (em dias) pelo qual o certificado ainda é válido. É possível adicionar um lembrete de expiração, mas normalmente a empresa responsável pela emissão já irá realizar isto quando o prazo estiver vencendo;
    • The hostname (ssl.myhro.net) is correctly listed in the certificate: informa que o hostname está presente no certificado, o que significa que um browser não irá acusar a divergência de hostnames entre o certificado e a página de fato acessada.

    Por fim, há uma representação gráfica da relação entre os certificados, com mais algumas informações quanto ao período de validade, algoritmo de assinatura, etc. O mais importante a se destacar neste momento é que, embora seja uma boa notícia o fato do certificado não ter apresentado problema nesta validação básica, isto não significa que o site por trás dele está realmente seguro. É preciso, portanto, realizar uma análise mais detalhada, como a oferecida pelo SSL Server Test da Qualys SSL Labs.

    O resultado obtido com a configuração padrão do nginx no Ubuntu 14.04 é o seguinte:

    Dois problemas comprometeram a nota do teste: a qualidade da troca de chaves utilizando o protocolo Diffie-Hellman e a vunerabilidade à falha de segurança do SSL 3.0 conhecida como POODLE. Felizmente, estas duas fraquezas são simples de serem resolvidas e o próprio teste aponta para documentações relevantes sobre os problemas.

    Diffie-Hellman

    O guia de implantação do Diffie-Hellman para TLS traz uma descrição detalhada e até um pouco paranóica (especificando todas as cifras suportadas, o que não é necessário) sobre como reforçar a segurança da troca de chaves. Resumidamente, é preciso realizar dois passos. O primeiro é gerar um grupo de parâmetros DH com tamanho de 2048 bits:

    openssl dhparam -out dhparams.pem 2048
    

    E em seguida adicionar estas duas linhas ao arquivo de configuração do nginx (seja globalmente ou por virtual host):

    ssl_dhparam /etc/nginx/ssl/dhparams.pem;
    ssl_prefer_server_ciphers on;
    

    … Após ter movido o arquivo gerado para o diretório /etc/nginx/ssl/.

    O resultado ainda continua com classificação C, por causa do POODLE, mas não há mais menção ao problema com o protocolo Diffie-Hellman. A nota no quesito “Protocol Support” subiu de 70 para 90:

    POODLE

    Resolver a questão do POODLE é mais fácil ainda, já que basta desabilitar o suporte ao SSL 3.0 no nginx. Por mais estranho que pareça, a configuração padrão do Ubuntu 14.04 adiciona a opção SSLv3 ao parâmetro ssl_protocols. Isto provavelmente se deve ao fato desta versão ter sido lançada em torno de 6 meses antes da descoberta da vulnerabilidade. Para reverter esta configuração, a seguinte linha deve estar presente na configuração do nginx:

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    

    Esta linha força o nginx a suportar apenas protocolo TLS (Transport Layer Security) (e não SSL (Secure Sockets Layer)), em suas versões de 1.0 a 1.2. Agora, a classificação do teste passa a ser A e a nota do “Protocol Support” atinge 95:

    Mesmo assim, ainda há uma pequena melhoria a ser realizada.

    HSTS

    O HSTS (HTTP Strict Transport Security) é um header adicionado à resposta de uma requisição HTTP que informa ao cliente que todas as conexões a este servidor, dali em diante, devem ser realizadas via HTTPS. O processo para habilitá-lo no nginx consiste em adicionar a seguinte linha ao seu arquivo de configuração:

    add_header Strict-Transport-Security "max-age=31536000";
    

    E com isto a classificação sobe para A+, ainda que as notas individuais de cada quesito não mudem:

    Arquivo de configuração do nginx

    O arquivo de configuração do virtual host do nginx resultante das modificações realizadas durante os testes é este:

    # HTTPS redirect
    #
    server {
        listen 80;
        server_name ssl.myhro.net;
        return 301 https://ssl.myhro.net$request_uri;
    }
    
    # HTTPS server
    #
    server {
        listen 443 ssl;
        server_name ssl.myhro.net;
        add_header Strict-Transport-Security "max-age=31536000";
    
        root /usr/share/nginx/html;
        index index.html index.htm;
    
        ssl on;
        ssl_certificate /etc/nginx/ssl/cert.pem;
        ssl_certificate_key /etc/nginx/ssl/cert.key;
        ssl_dhparam /etc/nginx/ssl/dhparams.pem;
    
        ssl_session_timeout 5m;
    
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
    
        location / {
            try_files $uri $uri/ =404;
        }
    }
    

    Vale ressaltar que foi adicionado o redirecionamento HTTP -> HTTPS, um comportamento que não é realizado por padrão, mas que é interessantíssimo caso seu interesse realmente seja servir conteúdo de forma segura. Desta forma, todos os visitantes acessarão o site via HTTPS automaticamente.

  • StartSSL: certificados gratuitos e suas peculiaridades

    A StartCom é uma empresa israelense, fundada em 1999 e sediada em Eilat, que dentre suas atividades trabalha com certificados SSL/TLS sob a marca StartSSL. Ela não seria muito diferente de qualquer outra empresa que comercializa produtos parecidos se não tivesse um diferencial: seu certificado SSL “Class 1” é oferecido gratuitamente, desde que sua finalidade seja voltada para uso pessoal. Não é necessário nada mais além de validar seu e-mail, ao criar uma conta com eles, e seu domínio (o que também é feito por e-mail), ao emitir um certificado. O primeiro passo, especificamente, é feito de uma maneira não muito convencional.

    Logo de imediato é possível perceber o quanto o processo de registro é diferente: não há a criação de um usuário e senha. Ao se cadastrar, é enviado um e-mail com um código que deve ser colado na tela pós-cadastro do site deles. Não há sequer um link que o leve à mesma janela de confirmação, que não pode ser fechada enquanto este código não for submetido. Após confirmado, será exibida uma mensagem dizendo que a conta será validada manualmente antes que possa ser efetivamente utilizada. Não levei isso muito a sério, pois uma vez efetuei o registro entre 6 e 7 da manhã (horário de Israel) e mesmo assim validaram a conta em pouco mais do que 5 minutos.

    Quando confirmarem a requisição de criação da conta, um segundo e-mail será enviado. Desta vez haverá um link que o levará para o processo registro propriamente dito, que consiste basicamente em gerar um certificado S/MIME de autenticação do cliente. O processo é realizado de forma automática através de um wizardContinue/Install/Finish” e ao final você estará automaticamente logado no sistema. Neste momento, no gerenciador de certificados do navegador (no Firefox: Preferences -> Advanced -> Certificates -> View Certificates) haverá um certificado emitido pela StartCom Ltd. que o identifica como cliente.

    Este certificado, composto também por sua chave privada, identifica e autoriza o navegador a se logar no painel de controle da StartSSL. É muito importante que você não o perca de forma alguma, pois do contrário a única forma de se autenticar novamente será criar uma nova conta e entrar em contato com o suporte, tentando convencê-los a associá-la com a conta antiga, conforme recomenda o FAQ. Utilize o recurso de Backup/Export do gerenciador de certificados do navegador e armazene uma cópia, protegida por senha, em um local seguro.

    Terminado o processo de registro, é necessário validar a propriedade de um domínio antes de emitir um certificado. Os passos são muito simples, consistindo em informar o domínio e um e-mail associado ao mesmo, como os genéricos “[email protected]” e “[email protected]”, ou algum outro endereço encontrado em seu WHOIS. Um código será enviado por e-mail e, confirmando-o, a validação será efetuada. A partir deste ponto, por até 30 dias será possível emitir certificados para este domínio sem precisar validá-lo novamente.

    Passadas estas etapas, é possível enfim emitir o certificado SSL desejado. Acessando a opção Certificates Wizard -> Web Server SSL/TLS Certificate do painel, é possível realizar todo o processo de geração através da interface web. Caso você seja um sysadminold school”, preferirá pular a opção de geração de chave privada, gerando esta e um CSR (Certificate Signing Request) com o OpenSSL através do terminal, o que pode ser feito em um só comando:

    openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr
    

    Respondendo as perguntas, serão gerados dois arquivos: o server.key, correspondente a chave privada do certificado, e o server.csr, que como a própria sigla diz, é a requisição de assinatura de um certificado. Este último é o único que precisa ser enviado para qualquer empresa que trabalhe com geração de certificados. A chave é realmente privada e sem ela o servidor web não poderá utilizar o certificado a ser assinado. Somente quem possuir ambos os arquivos poderá servir conexões HTTPS a partir do domínio.

    Continuando o wizard, será perguntado qual o subdomínio a ser utilizado. O certificado irá valer tanto para este subdomínio quanto para o domínio em si. Isto é, um certificado criado para o “www.example.com” também vale para “example.com”. Ao final destas etapas, estarão disponíveis três certificados que precisarão serem concatenados em um só arquivo. São eles:

    • O certificado do domínio/subdomínio em si;
    • O certificado intermediário;
    • O certificado raiz.

    Esta relação é o que fornece a validade ao certificado do final. De cima pra baixo, cada certificado possui uma assinatura do próximo elo da corrente. É por conta disto que cada sistema operacional ou navegador não precisa conhecer todos os certificados SSL existentes, basta que estes sejam assinados por outro certificado previamente conhecido e confiado como válido. Vale ressaltar ainda que a ordem dos certificados no arquivo que combina todos eles tem de ser a mesma da lista acima.

    Como não poderia deixar de ser, o certificado gratuito da StartSSL possui algumas limitações:

    • A duração máxima do certificado é de um ano (embora seja possível emitir um novo a qualquer momento);
    • O certificado vale para apenas um domínio/subdomínio: nada de wildcards ou múltiplos subdomínios (isto pode ser resolvido emitindo-se mais de um certificado);
    • Embora realmente seja um produto grátis, há um valor a ser pago (US$ 24.90) caso seja necessário revogar o certificado, como no caso de uma chave privada comprometida;
    • O uso do certificado para fins comerciais é vetado.

    Para a grande maioria dos casos de uso, nenhuma destas limitações é realmente crítica a ponto de inviabilizar sua utilização. O comportamento mais incômodo da empresa é mesmo a janela de manutenção, onde toda madrugada de sexta para sábado o site fica indisponível:

    Weekend Maintenance

    Some of our services are offline and under maintenance during the night hours on weekends until 7:00 AM GMT in the morning. We apologize for the temporary inconvenience and thank you for your understanding.

    Estando ciente destes detalhes e tomando cuidado para não perder o certificado do cliente necessário para acessar o painel de controle, a StartSSL oferece um produto diferenciado e que realmente funciona, sem custo algum. É uma boa alternativa enquanto o projeto Let’s Encrypt, que também irá oferecer certificados gratuitos, não é lançado. Há ainda a opção de certificados wildcard ou EV (Extended Validation, aqueles cujo nome da empresa aparece em destaque na barra de endereços) pagos, caso estes sejam uma necessidade.

  • Myhro Blog agora via Jekyll

    Há pouco mais de dois anos e meio, em Janeiro de 2013, o Myhro Blog havia sido migrado do Wordpress para o Octopress. Fiquei bastante satisfeito com a migração e empolgado com a ideia de não mais depender de um banco de dados para armazenar todas as postagens, utilizando Git para versionar o conteúdo. Com a própria mudança no processo, ficou muito mais natural escrever e publicar tudo a partir do terminal, sem precisar acessar uma interface web para isto. Entretanto, paraiva sobre mim uma preocupação: o Octopress era uma bomba-relógio.

    Que fique claro que não irei de forma alguma falar mal do Octopress, que me serviu tão bem por tanto tempo. Serei eternamente grato ao Brandon Mathis por tê-lo criado. O problema é que hoje o Octopress se encontra em um estado conhecido como erosão (ou apodrecimento) de software. A última versão estável (2.0) foi lançada em Julho de 2011 e embora a nova versão (3.0) esteja sendo desenvolvida, não sabemos quando será lançada. A última notícia a respeito da mesma é de Janeiro deste ano.

    O maior problema em tentar utilizar uma versão de um software com mais de 4 anos de idade e tantas dependências é simples: não é mais possível utilizá-la. Mesmo reinstalando a gem do Octopress, com todas as suas bibliotecas em suas devidas versões (graças ao Gemfile.lock), apareciam erros que impediam o blog de ser “compilado” (processo de gerar as páginas HTML a partir dos documentos escritos em Markdown). Isto acontece, por exemplo, por mudanças externas, como o fato das bibliotecas instaladas no sistema quais as gems dependem para serem compiladas estarem em versões diferentes de quando estas foram desenvolvidas.

    A situação chegou a um ponto onde eu só podia publicar novos posts no blog ou modificar qualquer configuração do Octopress no meu notebook. Qualquer outro computador, seja minha estação de trabalho no escritório ou o servidor remoto que utilizo para desenvolvimento, não servia para este propósito. A gota d’água foi quando precisei alterar as configurações do plugin de pesquisa no Google (que estava gerando erros de HTTPS por submeter conteúdo de forma não-segura) e não consegui.

    Deste momento em diante tive de decidir o que fazer, se tentaria utilizar a versão 3.0 ainda não lançada ou se abandonaria o Octopress em busca de outra solução. Ao perceber que a nova versão havia se tornado um wrapper ainda mais fino em torno do Jekyll, mas com mais problemas por se tratar de uma versão em desenvolvimento, não tive dúvidas e migrei logo para este último. Há de se ressaltar que algumas funcionalidades foram perdidas (e talvez ainda consiga restaurá-las com um pouquinho de tempo e paciência) no processo:

    • A barra “recent posts”, no canto superior direito, não existe mais. Isto não é uma perda tão grande, já que esta basicamente me servia para notar quais são os cinco posts exibidos na página principal;
    • As “categorias” ainda existem, mas não há as páginas de listagem de cada uma, segregando o arquivo de posts antigos em partes menores;
    • Os links entre posts também foram perdidos. É bacana a ideia de navegar entre “anterior” e “próximo” a partir de um post, mas ainda não verifiquei como resolver isto.

    A parte de “unir o útil ao agradável” fica por conta do GitHub Pages. Já o estava utilizando desde Junho de 2014, quando percebi que o esforço em manter um servidor para hospedar um site estático não valia a pena. Acontece que o deploy do Octopress por lá é meio que uma gambiarra. Os posts são gerados em uma pasta não commitada do repositório, mas que na verdade é outro repositório, e só então enviados para o GitHub. Com o Jekyll não preciso me preocupar com isto, visto que o GitHub Pages tem suporte nativo à plataforma.

Subscribe via RSS