Drupal hospedagem com SSL

HTTPS é um protocolo que criptografa as solicitações HTTP e suas respostas. Isso garante que se alguém fosse capaz de comprometer a rede entre o computador eo servidor você está solicitando a partir, eles não seriam capazes de ouvir ou adulterar as comunicações.

Quando você visita um site através de HTTPS, o URL parece com isso: https://drupal.org/user/login. Quando você visita um site através plain HTTP (sem criptografia), parece que isso: drupal.org/user/login.

hospedagem

Por que é importante para você (e quando)

HTTPS é normalmente usado em situações em que um usuário iria enviar informações confidenciais a um website e intercepção de que a informação seria um problema. Geralmente, essas informações incluem:

  • Cartões de crédito
  • biscoitos sensíveis, tais como cookies de sessão PHP
  • Senhas e nomes de usuários
  • informações de identificação (número da Segurança Social, números de identificação estaduais, etc)
  • conteúdo confidencial

Especialmente em situações em que você, como administrador, estão enviando sua senha Drupal ou a senha de FTP para o servidor, você deve usar HTTPS sempre que possível para reduzir o risco de comprometer o seu web site.

HTTPS também pode impedir que bisbilhoteiros de obter a sua chave de sessão autenticada, que é um cookie enviado do seu navegador com cada solicitação para o site, e usá-lo para se passar por você. Por exemplo, um atacante pode obter acesso administrativo ao site se você é um administrador do site acessando o site através de HTTP em vez de HTTPS. Isto é conhecido como seqüestro de sessão e pode ser realizado com ferramentas como o Firesheep.

A segurança é um equilíbrio. Servindo HTTPS custos de tráfego mais em recursos do que solicitações HTTP (tanto para o navegador do servidor e web) e por isso você pode querer usar mista HTTP / HTTPS, onde o proprietário do site pode decidir quais páginas ou os usuários devem usar HTTPS.

Como ativar o suporte HTTPS em Drupal

  1. Obtenha um certificado. Muitos provedores de hospedagem configurá-los para você - automaticamente ou por uma taxa. Você também pode usar Vamos Criptografar que é gratuito, automático e abrir a Autoridade de Certificação. Se você quiser garantir um local de teste, você poderia, em vez gerar um certificado auto-assinado.
  2. Configurar seu servidor web. Alguns links úteis:
    • instruções Apache.
    • instruções nginx
    • instruções Ubuntu

    As possibilidades são, o serviço de hospedagem pode fazer isso para você, se você estiver usando compartilhada ou hospedagem gerenciada.

    Nota: URLs limpas Se você estiver usando Apache para HTTP e HTTPS:

    Você provavelmente terá dois baldes VirtualHost diferentes.

    1. Um balde para a porta: 80 http
    2. Um balde para a porta: 443 https

    Cada um desses recipientes VirtualHost ou baldes exigem que uma directiva específica Apache ser adicionado dentro deles se você estiver usando URLs limpas. Isso ocorre porque Drupal faz uso extensivo de .htaccess e mod_rewrite para fornecer URLs amigáveis.

    Drupal hospedagem com site SSL via HTTP, em vez

    Verifique se você tem o seguinte dentro da directiva, que é uma criança sob o recipiente VirtualHost: Ver Apache Documentação para AllowOverride

    Isso significa que seu .htaccess tem precedência e que a configuração do Apache irá permitir que ele seja executado como seria de esperar para Drupal.

    Solução de problemas:
    Se você habilitado HTTPS e só funciona na página inicial e seus sub links estão quebrados, é porque o VirtualHost: balde 443 precisa AllowOverride All ativada para URLs podem ser reescritos, enquanto no modo HTTPS.

    No Drupal 7, se você quiser apoiar de modo misto HTTPS e sessões HTTP, abrir sites / default / settings.php e adicionar $ conf [ 'https'] = true ;. Isso permite que você use a mesma sessão sobre HTTP e HTTPS - mas com dois biscoitos, onde o cookie HTTPS é enviado através de HTTPS somente. Você vai precisar usar módulos contribuíram como securepages para fazer algo útil com este modo, como envio de formulários por HTTPS. Enquanto o HTTP do cookie ainda é vulnerável a todos os ataques habituais. Um cookie de sessão insegura sequestrado só pode ser usado para ganhar acesso autenticado para o site HTTP, e não será válida no site HTTPS. Se isto é um problema ou não depende das necessidades do seu site e as várias configurações do módulo. Por exemplo, se todas as formas está pronto para ir através de HTTPS e os visitantes podem ver as mesmas informações que usuários logados, este não é um problema.

    Note-se que em Drupal 8, suporte de modo misto foi removido # 2342593: Remover suporte SSL mista do núcleo.

    Para uma maior segurança, enviar todo o tráfego autenticado através de HTTPS e usar HTTP para sessões anônimas. No Drupal 8, instale o módulo de login seguro que resolve os avisos de conteúdo misto. No Drupal 7, deixe $ conf [ 'https'] com o valor padrão (FALSE) e instalar Login Seguro. Drupal 7 e 8 permitem automaticamente a configuração session.cookie_secure PHP em sites HTTPS, o que faz com SSL somente cookies de sessão seguras para ser emitido para o navegador. No Drupal 6, veja módulos 443 de sessão e Login Seguro contribuiu.

    Para melhor segurança possível, configurar o site para usar somente HTTPS e responder a todas as solicitações HTTP com um redirecionamento para seu site HTTPS. Drupal 7 de $ conf [ 'https'] pode ser deixado em seu valor padrão (FALSE) em sites puros-HTTPS. Mesmo assim, HTTPS é vulnerável a ataques man-in-the-middle se a conexão começa como uma conexão HTTP antes de ser redirecionado para HTTPS. Use o módulo HSTS ou módulo Kit de Segurança. ou definir o cabeçalho-transporte e segurança rigorosas em seu servidor, e adicionar o seu domínio à lista de pré-carga HSTS browser. para ajudar a impedir que usuários acessem o site sem HTTPS.

    Você pode querer redirecionar todo o tráfego de example.com e www.example.com para https://example.com. Você pode fazer isso adicionando o código abaixo ao seu arquivo de configuração do servidor, ou seja, as definições VirtualHost:

    O uso de RewriteRule seria apropriado se você não tem acesso ao arquivo de configuração do servidor principal, e são obrigados a executar esta tarefa em um arquivo .htaccess em vez disso:

    Há comentários existentes em .htaccess que explicam como redirecionar example.com para www.example.com (e vice-versa), mas este código aqui redireciona tanto daqueles a https://example.com.

    bjdeliduka comentou 27 de fevereiro de 2015 às 21:25

    Como o assunto diz. As alegrias.

    Um cliente meu tem inúmeros clientes com Drupal 7 sites. Estamos nos movendo todos eles para trás CloudFlare (www.cloudflare.com) que eles oferecem Certs GRÁTIS SSL, cache web e ddos ​​protecção / mitigação. Em seguida, firewall os servidores para aceitar apenas conexões a partir da CF caches e certifique-se de que o servidor HTTP real não está listado no DNS (cliente / navegadores devem se conectar aos servidores CF que, então, buscar páginas do servidor real). O Drupal Server (Apache 2.4 no CentOS) também usar SSL para criptografar a conexão entre o CF eo servidor (pode muito bem manter tudo fora de texto simples)

    Enquanto os olhares acima e se sente como uma grande solução para segurar todas as ligações são criptografados que encontrou um problema com algumas páginas que têm IFRAMES que carregam conteúdo criptografado. (Web browsers lançar um erro quando isso ocorre e muitas vezes se recusam a carregar o conteúdo sem intervenção do usuário).

    Opções incluídas 1) a criação de um proxy e criptografar o conteúdo inseguro. Embora tecnicamente possível, dá ao usuário a impressão de que a sessão é segura enquanto alguns do conteúdo é em texto simples (embora não de / para o cliente). 2) deixar cair o conteúdo até que esteja disponível através de uma conexão segura (cliente / cliente não gostou desta opção) 3) páginas de força que contêm este conteúdo para ser conexões não criptografadas (http), enquanto o resto do site é criptografado.

    Nós escolhemos a opção 3.

    Os locais tinham sido previamente configurado para redirecionar as conexões com https usando uma regra de reescrita no arquivo .htaccess (provavelmente irá mover-los em arquivos de configuração vhost por motivos de desempenho, mas somente se nós podemos concordar sobre como desativar os arquivos .htaccess) Como tal todos os http conexão torna-se uma conexão HTTPS.

    Normalmente, um RewriteRule poderia ser criada no formulário:

    para pegar conexões para a página com o iframe inseguro. (Reescrever correspondentes para http e não correspondentes a https)

    tentar isso com url do limpa habilitado e você nunca obter a página não criptografada porque cada solicitação de página submetido a Drupal faz um passe final através do mecanismo de reescrita em /index.php.

    Eu tenho certeza da razão exata, mas secure_pages não foram considerados uma opção viável.

    A solução resultado final é uma série de linhas / rewritecond 13 RewriteRule que pode eficazmente substituir o módulo secure_pages para forçar todos menos um (1 ou mais) páginas para conexões https poucos escolhidos.

    / A página raiz do site de streaming-página e são HTTP o resto do site é HTTPS. Páginas adicionais podem ser excluídos HTTPS adicionando gostos adicionais sob a linha / Transmissão-página seguinte é formato.

    O único lado conhecido afetar deste código é que a edição de páginas não criptografadas é mais complicado como o admin_menu cai nas páginas não criptografadas. Versão 1.1 inclui um método de desativação lado do http de um navegador clientes (resultando nos erros do navegador que os desenvolvedores vão lidar com como necessário ao editar as páginas) Eu também vou procurar um instruções mais detalhadas em colocar isso em arquivos .htaccess e remover o código indesejado / desnecessários para coisas como www. decapagem (ou pré-pendente) etc.

    selinav comentou 25 de abril, 2017 às 09:51

    Bairnsfather comentou 26 de abril de 2017 em 17:29

    Eu tenho sido muito feliz com https://www.drupal.org/project/securepages por um longo tempo. Basta carregar a página de configuração e colocar um asterisco no campo para que páginas você quer seguro, ou seja, tudo. Eu acho que o aviso na parte superior da página do projeto é obsoleto; Eu usei o módulo sem manchas ou modificar meu .htaccess para os últimos lançamentos 7.x. Verifique se o seu settings.php e certifique-se a variável base_url contém https, e não http.

    [Editar] Mas por favor não tome isso como a última palavra sobre o momento melhor método para redirecionar todo o tráfego para https estes dias. Com base na leitura recente, parece HSTS é onde as coisas estão indo.

    Bairnsfather comentou 9 de maio de 2017 às 17:30

    Aqui está o que eu fiz que parece funcionar para D7 D8 (especificamente como de 7,54 8.3.1 no Apache 2.4.5 com PHP 5.6.30) usando o arquivo .htaccess estoque apenas com as modificações mencionadas abaixo. Em termos simples, a linha-Transport-Security Rigoroso Não será inicialmente redirecionar o tráfego de http para https. (Essa linha não é visto em solicitações HTTP e navegadores mais antigos não entendem isso.) Assim, o interesse em redirecionamento com um RewriteRule; no entanto, que deixa em aberto a possibilidade de um ataque MITM. Mas a esperança é com DNSSEC e um navegador moderno que entende HSTS, em menos de um segundo o seu browser vai se lembrar (para segundos max-idade) para só recursos solicitação HTTPS, mesmo se o seu site ou outro site tem um link http / recurso em isto. Em outras palavras, uma vez seu navegador moderno carrega uma página via https do seu site, o navegador aprende que deve ser estrita e só fazer solicitações HTTPS, mesmo que ele encontre uma http recurso ou link especificando.

    Primeiro, certifique-se de ter o seu servidor disponível via https e seu certificado inclui todos os subdomínios que você usa. Max-idade é em segundos, personalizá-lo para suas necessidades, e não deixe de ler (pelo menos) https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security (ligação RFC abaixo).

    Abaixo das linhas:

    Em seguida, coloque um # na frente das três linhas abaixo para comentá-las; já não se aplica, uma vez que apenas obrigou todo o tráfego para https. As seguintes linhas já estão no arquivo .htaccess e logo abaixo o que você colou no.

    Observe também os https://www.drupal.org/project/hsts módulo HSTS tem versões para D7 D8. Que é bom se você executar vários locais e nem todos os domínios têm um certificado.

    Você pode testar as coisas, abrindo o aplicativo de terminal e enrolar -I seu domínio de várias maneiras para inspecionar o cabeçalho.

    Assista esse video!

    Artigos relacionados

    7 41 drupal hospedagem2013/07/23 13:22 EST Obrigado pela pergunta! Sim, você pode usar um certificado SSL compartilhado. O certificado SSL compartilhado é pré-definido, então não há nenhuma configuração feita no lado do servidor. Por favor...
    página html Intro wordpress hospedagemNo WordPress, você pode colocar o conteúdo em seu site ou como um "post" ou uma "página". Quando você está escrevendo uma entrada regular de blog, você escreve um post. Posts, em uma configuração padrão, aparecem em sentido inverso ...
    Facetada pesquisa apache Solr drupal hospedagemNota: extra agradecimento especial a Doug Vann para fornecer motivação para finalmente publicar este post! No início de 2016, quando o Search API e módulos relacionados com o Solr para Drupal 8 estavam em alfa cedo ...
    Campo ferramentas Drupal hospedagemIntrodução Uma implementação de uma pesquisa eficaz é uma das tarefas mais difíceis em desenvolvimento, mas também é uma chave para o sucesso de diversos sites e aplicações. Uma busca rápida e ...
    Webfm módulo drupal hospedagemEstou criando um arquivo de site que permitirá aos usuários fazer upload de vários tipos diferentes de conteúdo de mídia, incluindo vídeo, áudio, imagens, documentos e textos. Eu quero torná-lo fácil para os usuários ...