É ruim redirecionar o http para https?

Acabei de instalar um certificado SSL no meu servidor.

Em seguida, ele configurou um redirecionamento para todo o tráfego no meu domínio na porta 80 para redirecioná-lo para a porta 443.

Em outras palavras, todo o meu http://example.comtráfego agora é redirecionado para a https://example.comversão apropriada da página.

O redirecionamento é feito no meu arquivo Apache Virtual Hosts com algo como isto ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Minha pergunta é: existem desvantagens em usar SSL?

Como este não é um redirecionamento 301, perderei o ranking / ranking dos links nos mecanismos de pesquisa ao mudar para https?

Agradeço a ajuda. Eu sempre quis configurar o SSL em um servidor, apenas para a prática, e finalmente decidi fazê-lo hoje à noite. Parece estar funcionando bem até agora, mas não tenho certeza se é uma boa ideia usá-lo em todas as páginas. Meu site não é eCommerce e não manipula dados confidenciais; é principalmente para a aparência e a emoção de instalá-lo para aprender.

EDIÇÃO ATUALIZADA

Estranhamente, o Bing cria esta captura de tela do meu site agora que está usando HTTPS em todos os lugares ...

O [R]sinalizador por si só é um 302redirecionamento ( Moved Temporarily). Se você realmente deseja que as pessoas usem a versão HTTPS do seu site (dica: deseja), use [R=301]um redirecionamento permanente:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

A 301mantém intactos todos os seus pageranks google-fu e suados . Verifique se mod_rewriteestá ativado:

a2enmod rewrite

Para responder sua pergunta exata:

É ruim redirecionar o http para https?

De jeito nenhum. É muito bom.

Embora eu apóie a idéia de sites apenas com SSL, eu diria que uma desvantagem é a sobrecarga, dependendo do design do site. Quero dizer, por exemplo, se você está exibindo muitas imagens individuais em tags img, isso pode fazer com que seu site seja muito mais lento. Eu aconselho qualquer pessoa que utilize servidores apenas SSL para garantir que eles funcionem no seguinte.

1. Verifique o site inteiro em busca de links internos e verifique se todos estão usando HTTPS se você especificar seu próprio nome de domínio nos links, para não causar seus próprios redirecionamentos.
2. Atualize <meta property="og:url"para usando a versão https do seu domínio.
3. Se você usar <base href=novamente, atualize para usar HTTPS.
4. Instale o protocolo SPDY, se possível
5. Certifique-se de usar sprites de imagem CSS sempre que possível, para reduzir o número de solicitações.
6. Atualize seus sitemaps para indicar o status https, para que as aranhas, ao longo do tempo, aprendam essa alteração.
7. Altere as preferências do mecanismo de pesquisa, como as Ferramentas do Google para webmasters, para preferir HTTPS
8. Sempre que possível, descarregue qualquer mídia estática nos servidores HTTPS CDN.

Se o exposto acima for abordado, duvido que você tenha muitos problemas.

Se você configurou o https, deve usá-lo em qualquer lugar do site. Você evitará o risco de problemas de conteúdo misto e, se você possui as ferramentas necessárias, por que não tornar o site inteiro seguro?

Em relação ao redirecionamento de http para https, a resposta não é tão simples.

Redirecionar tornará muito mais fácil para seus usuários, eles apenas digitam whateversite.com e são redirecionados para https.

Mas. E se o usuário estiver às vezes em uma rede não segura (ou estiver perto de Troy Hunt e seu abacaxi )? Em seguida, o usuário solicitará http://whateversite.com fora do antigo hábito. Isso é http. Isso pode ser comprometido. O redirecionamento pode apontar para https://whateversite.com.some.infrastructure.long.strange.url.hacker.org . Para um usuário comum, isso pareceria bastante legítimo. Mas o tráfego pode ser interceptado.

Portanto, temos dois requisitos concorrentes aqui: Ser amigável e seguro. Felizmente, existe um remédio chamado cabeçalho HSTS . Com ele, você pode ativar o redirecionamento. O navegador passará para o site seguro, mas, graças ao cabeçalho do HSTS, lembre-se também. Quando o usuário digita whateversite.com sentado nessa rede não segura, o navegador acessa o https imediatamente, sem passar pelo redirecionamento pelo http. A menos que você lide com dados muito confidenciais, acho que é uma troca justa entre segurança e usabilidade para a maioria dos sites. (Quando configurei recentemente um aplicativo que lida com registros médicos, fui https sem redirecionamento). Infelizmente, o Internet Explorer não oferece suporte ao HSTS ( fonte), por isso, se seu público-alvo estiver usando o IE e os dados forem confidenciais, convém desativar os redirecionamentos.

Portanto, se você não estiver direcionando usuários do IE, vá em frente e use o redirecionamento, mas ative também o cabeçalho HSTS.

Não há nada de errado nisso e, de fato, é uma prática recomendada (para sites que devem ser veiculados em uma conexão segura). Na verdade, o que você está fazendo é bem parecido com a configuração que estou usando:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

O 301código de status indica um redirecionamento permanente , instruindo os clientes capazes a usar a URL segura para conexões futuras (por exemplo, atualize o marcador).

Se você estiver veiculando apenas o site por TLS / SSL, recomendo uma diretiva adicional para habilitar o HTTP Strict Transport Security (HSTS) em seu host virtual seguro :

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Esse cabeçalho instrui clientes capazes (a maioria deles atualmente, acredito) que eles devem usar apenas HTTPS com o domínio fornecido ( secure.example.comneste caso) pelos próximos 1234segundos. A ; includeSubdomainsparte é opcional e indica que a diretiva se aplica não apenas ao domínio atual, mas a qualquer um abaixo dele (por exemplo alpha.secure.example.com). Observe que o cabeçalho HSTS é aceito apenas pelos navegadores quando veiculados em uma conexão SSL / TLS!

Para testar a configuração do servidor em relação às melhores práticas atuais, um bom recurso gratuito é o serviço de servidor SSL da Qualys ; Eu pretendia pontuar pelo menos um A- (você não pode obter mais do que isso com o Apache 2.2 devido à falta de suporte para criptografia de curva elíptica).

Uau ! redirecionar HTTP para HTTPS é uma coisa muito boa e não vejo desvantagens disso.

Apenas verifique se seus clientes têm a CA correta para evitar avisos não amigáveis ​​sobre o certificado no navegador.

Além disso, a maneira como você configurou o Apache para redirecionar para HTTPS parece boa.

É ruim redirecionar o http para https?

Não, não mesmo. Na verdade, é uma boa coisa a fazer!

Nos redirecionamentos:

Poderia ser mais eficiente, eliminando completamente as reescritas . Aqui está a minha configuração em uma situação semelhante ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

HTTPS não é exatamente infalível. Obviamente, forçar o HTTPS normalmente é uma coisa boa. Impede que criminosos normais façam algo ruim aos seus usuários.

Mas lembre-se de verificar suas configurações de SSL, como a configuração SSLCiphers. Desative coisas como RC4 crypto, o protocolo SSLv2 e SSLv3. Além disso, você deve descobrir se as bibliotecas do sistema de criptografia do seu sistema suportam TLS1.2 (que é o que você deseja;))

Ative o SSL, é uma coisa boa.

Pessoalmente, sou a favor do uso de SSL para proteger conexões na Web. No entanto, sinto que todas as outras respostas aqui foram perdidas: nem todos os dispositivos e softwares capazes de uma conexão HTTP poderão usar SSL, portanto, eu consideraria fornecer aos usuários uma maneira de evitá-los, se não houver suporte para eles. Também é possível que pessoas em alguns países onde a tecnologia de criptografia seja ilegal não possam acessar seu site. Eu consideraria adicionar uma página de destino não criptografada com um link para forçar a versão insegura do site, mas, a menos que um usuário selecione especificamente isso para fazer o que você disse e encaminhe-a para a versão HTTPS.

Aqui estão alguns dos problemas gerais de pinceladas:

• MITM / SSLSTRIP : Esta é uma grande ressalva. Se você deseja veicular seu site por HTTPS, desative o HTTP no site . Caso contrário, você deixará seus usuários abertos a vários ataques intermediários, incluindo SSLSTRIP, que interceptará solicitações e as servirá silenciosamente por HTTP, inserindo seu próprio script de malware no fluxo. Se o usuário não perceber, eles acharão que sua sessão é segura quando na verdade não é.

  • O problema com isso, porém, é que, se seu site for público e você desabilitar o HTTP sem a menor cerimônia, poderá perder muitos visitantes. Provavelmente nem lhes ocorrerá tentar o HTTPS se o site não for carregado com HTTP.

• Se o seu site exigir um logon seguro, toda a sessão do usuário deverá ser protegida. Não se autentique pelo HTTPS e, em seguida, redirecione o usuário de volta ao HTTP. Se o fizer, novamente, você estará deixando seus usuários vulneráveis ​​a ataques MITM. Atualmente, a abordagem padrão da autenticação é autenticar uma vez e depois passar um token de autenticação para frente e para trás (em um cookie). Mas se você se autenticar por HTTPS e depois redirecionar para HTTP, um intermediário pode interceptar esse cookie e usar o site como se fosse seu usuário autenticado, ignorando sua segurança.

• Os problemas de "desempenho" do HTTPS são, para todos os fins práticos, limitados ao handshake envolvido na criação de uma nova conexão. Faça o que puder para minimizar a necessidade de várias conexões HTTPS a partir de um URL e você estará a quilômetros de distância. E isso é verdade mesmo que você esteja exibindo seu conteúdo por HTTP. Se você ler o SPDY, perceberá que tudo o que faz é orientado para tentar veicular todo o conteúdo de um único URL em uma única conexão. Sim, o uso de HTTPS afeta o cache. Mas quantos sites são conteúdo estático e armazenável em cache atualmente? É provável que você consiga mais dinheiro usando o armazenamento em cache no servidor da web para minimizar consultas redundantes ao banco de dados, recuperando dados inalterados repetidas vezes e impedindo a execução de caminhos de código caros com mais frequência do que o necessário.

Tecnicamente, essa não é uma resposta à sua pergunta original, mas se você usar a extensão HTTPSEverywhere do Google Chrome (tenho certeza de que existem extensões semelhantes em outros navegadores), a extensão redirecionará automaticamente sites com HTTP para o mesmo site com HTTPS. Uso-o há algum tempo e não tive problemas (exceto, talvez, desaceleração, mas ainda não testei). O HTTPSEverywhere pode ser alterado por certas regras do lado do servidor, mas como não fiz muito nessa área, não tenho certeza dos detalhes exatos.

Voltando à sua pergunta real, se você usa algo como HTTPSEverywhere, há ainda menos incentivo para usar somente HTTP, embora eu imagine que seja difícil definir regras corretas para quando você precisar delas.

a única desvantagem técnica do HTTPS sobre HTTP é que é computacionalmente mais caro processar solicitações HTTPS do que HTTP simples

No entanto, considerando que a maioria dos servidores modernos possui CPUs de alta potência, esse impacto geralmente é desprezível, a menos que você esteja com níveis extremamente altos de tráfego e, nesse ponto, é mais provável que esteja usando balanceadores de carga de qualquer maneira

Com o advento de protocolos como o SPDY, que exigem que o SSL / TLS funcione, isso na verdade neutraliza a sobrecarga computacional acima mencionada, oferecendo melhorias significativas de desempenho em relação a várias solicitações e disponibilizando recursos para o cliente mais rapidamente.

É muito bom redirecionar para https, mas eu li também depende de como você organiza o redirecionamento.

Criar um servidor virtual dedicado para redirecionar as solicitações HTTP recebidas para sua conexão https, conforme sugerido na resposta em security.stackexchange.com, parece muito inteligente e fechará algumas ameaças adicionais à segurança. Uma configuração no Apache seria algo como isto:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>