É ruim redirecionar o http para https?


247

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 ...

insira a descrição da imagem aqui


12
[WTF - Não consigo adicionar resposta (embora pareça que eu tenho representante suficiente).] Minha resposta (em parte) seria que às vezes é ruim . Considere passar um COOKIE ou chave de API em um GET sobre HTTP. Se seu site redirecionar solicitações HTTP para solicitações HTTPS, essas chamadas funcionariam, mas a COOKIE ou a chave da API seria transmitida de maneira clara. Algumas APIs desativam o HTTP, uma abordagem mais robusta - nenhum HTTP; portanto, você nem pode fazê-lo funcionar, a menos que você use HTTPS. Exemplo: "Todas as solicitações de API devem ser feitas por HTTPS. As chamadas feitas por HTTP simples falharão" em stripe.com/docs/api?lang=php#authentication
codingoutloud

8
@codingoutloud - a alternativa é que tudo acontece através de HTTP sem HTTPS. Como isso é melhor?
Mark Henderson

3
@BenCrowell, isso ocorre porque um portal cativo se parece muito com um sslstripataque de redirecionamento de estilo (ambos são seqüestradores de solicitação intermediários), para que os navegadores HSTS bloqueiem os dois.
Jeffrey Hantin

3
esteja ciente de que o uso de https significa que tudo o que você incluir também deve ser https ou ele pode não carregar - por exemplo, carregar o jquery using src="://example.com/jquery.js"- observe a falta httpou httpso navegador carrega o apropriado. Eu tive um pesadelo ao tentar carregar algumas coisas incorporadas da Amazon para carregar corretamente, pois a API (carregada via https) produzia links http - o que significa que eles não funcionaram corretamente até que encontrei o parâmetro não documentado para alternar links https
Básico

3
Jason; sua atualização deve ser uma nova pergunta, provavelmente nos Webmasters, pois não está relacionada (tecnicamente) à sua pergunta original. Mas é provável que suas folhas de estilo sejam provenientes de um domínio inseguro.
Mark Henderson

Respostas:


316

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.


3
Obrigado pelas informações, meu chefe está me dizendo o motivo de ele executar apenas https em determinadas páginas do site, é que ele usa muito mais recursos do servidor para executá-lo em todas as páginas. Você sabe alguma coisa sobre isso ou se é verdade?
precisa saber é o seguinte

9
@jasondavis Somente se você não gastar alguns minutos para otimizá-lo .
Michael Hampton

10
"ele usa muito mais recursos do servidor para executá-lo em todas as páginas." As CPUs modernas têm recursos de aceleração de criptografia que tornam o SSL quase gratuito. Não se preocupe com sobrecarga.
Adam Davis

41
@AdamDavis O algoritmo de criptografia pode ser leve, mas a sobrecarga do handshake ainda existe. Além disso, o HTTPS impede que os proxies HTTP armazenem em cache seu conteúdo. Na maioria dos casos, a sobrecarga do HTTPS é mínima e vale a pena, mas tenha cuidado ao generalizar demais.
200_success

6
Ele mata o cache compartilhado, o que é útil para os padrões de uso de alguns sites e geralmente protege pouco (é importante que as pessoas saibam que você visitou o site, mas não os detalhes do que você fez? Essa é a única situação em que o SSL é útil). A principal vantagem do SSL em todos os recursos não é que você precisa "proteger", por exemplo, pessoas que olham "sobre nós", mas que você não pode escorregar e deixar de usá-lo no caso em que deveria.
Jon Hanna

49

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.


SPDY é uma boa sugestão; há ainda parece ser um módulo de adição de suporte SPDY para Apache 2.x .
Calrion

18
O uso de "//seu servidor.com.br/some-uri" em vez de " nome_do_servidor.com/some-uri " resolve o problema (1) porque o navegador seleciona o esquema apropriado (http ou https), dependendo do esquema em que a página foi carregada .
precisa saber é o seguinte

1
@MauganRa A menos que, é claro, seja um link da página do artigo http para a página de login https, por exemplo.
Mołot

4
O Google vê o URL que alguém está visitando através do Referercabeçalho. Por exemplo, este site usa jQuery da CDN do Google e meu navegador envia uma solicitação ao Google toda vez que recarrego o site. Assim, um Referercabeçalho também é enviado ao Google, definido como o URL deste site. Para que o Google possa rastrear os sites que visito durante o período em que meu endereço IP não muda (e se eu usar um serviço do Google durante esse período, o Google também poderá conectar essas informações à minha conta do Google).
27414 Stephan Kulla

1
Para 1) Eu apenas fiz uma pesquisa e substituir em meu banco de dados MySQL http para https ... Estou usando o WordPress para que ela realmente fácil de atualizar centenas de ligações
JasonDavis

38

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.


Mais pessoas precisam prestar atenção a isso também. Outra coisa é que as pessoas assumem que são seguras porque o ponto final é HTTPS, ignorando o fato de que todas as informações enviadas para a página em GETs ou POSTs estão em texto sem formatação.
Velox

3
@Velox - Eu não acho que a implicação de "as pessoas assumam que são seguras porque o ponto final é HTTPS, ignorando o fato de que todas as informações enviadas para a página em GETs ou POSTs estão em texto simples" são bastante precisas. Embora existam algumas dicas, os parâmetros de consulta GET não trafegam durante o transporte por HTTPS. Veja, por exemplo: stackoverflow.com/questions/323200/… as cargas úteis do POST também são protegidas, embora também não sejam vulneráveis ​​aos cabeçalhos de log e referenciador.
Codigooutloud

@codingoutloud Esse é o meu ponto. Por HTTPS, eles são criptografados, mas na solicitação inicial para a página HTTP, eles não eram.
Velox

1
@Velox - Se todo o site estiver redirecionando para HTTPS, é improvável que quaisquer parâmetros GET sejam enviados antes do início do HTTPS (e tudo permanecerá HTTPS após esse ponto). Ainda existe uma solicitação inicial para a qual os cookies serão enviados, que podem ser corrigidos com o HSTS ... e uma pequena janela de ataque para SSLStrip, que pode ser derrotada pelo JavaScript, mas essa é uma corrida armamentista própria.
Brilliand

@ Brilliand Fair point, mas um ponto fraco na segurança torna a coisa toda fraca. Sempre vale a pena considerar.
Velox

22

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).


Devo acrescentar que o envio do cabeçalho Strict-Transport-Security: max-age=0negará qualquer diretiva anterior; como sempre, isso deve ser enviado por HTTPS para ser aceito, mas é uma maneira útil de cancelar as coisas, se você decidir que também precisa usar HTTP no domínio.
Calrion

5

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.


5

É 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>

4

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.


A entropia não se acostuma ( pelo menos se você estiver defendendo contra atacantes da Terra em vez de praticar vodu ). Ou você começa com entropia insuficiente e não pode fazer nada que exija aleatoriedade, ou começa com entropia suficiente e continua tendo entropia suficiente, independentemente da quantidade de aleatoriedade gerada.
Gilles

Desculpe o que ? Existem várias operações no Linux que insistem em entropia forte derivada de hardware, em vez de entropia provavelmente suficientemente boa baseada em PRNG, e elas podem realmente bloquear se a profundidade do pool for baixa. É certamente possível começar com entropia suficiente em um sistema Linux, mas pelo uso excessivo para drenar o pool, causando o bloqueio de algumas operações.
21414 MadHatter

3

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.


Um problema com soluções como ter uma página de entrada HTTP simples, mesmo que adequadamente separada, é que essa página é deixada aberta para manipulação. Ou seja, não há garantia real de que o link para a versão HTTPS do site seja entregue intacto aos visitantes.
Håkan Lindqvist

3

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.


O que você pode fazer para resolver o sslstrip é usar o HSTS (de preferência, pré-carregue as configurações do HSTS ). Se você aceita solicitações por HTTP simples ou não, na verdade, não importa a esse respeito, um MITM pode responder por HTTP simples (possivelmente proxy para o site HTTPS), mesmo que você aceite apenas solicitações HTTPS.
Håkan Lindqvist

@ HåkanLindqvist Eu realmente ganhei um voto negativo de você? Dei maus conselhos ou bons conselhos em relação à não autenticação através de HTTPS e depois à mudança para HTTP pelo resto da sessão? Forneci maus conselhos em relação aos mitos de desempenho do HTTPS? Além disso, se o cliente tentar conectar-se inicialmente usando HTTPS, o MITM não poderá interceptar e responder sem disparar um alerta no navegador, porque o certificado não corresponderá, a menos que tenha um certificado roubado ou forjado com sucesso. Por outro lado, se o site aceitar uma conexão HTTP, a interceptação será mais fácil. De qualquer forma, o HTTPS eleva a fasquia.
Craig

..e é claro que concordo plenamente com o uso do HSTS.
Craig

Meu problema com a resposta é o primeiro item da lista que afirma tratar do sslstrip enquanto isso não acontece (falando de mitos). O que eu estava tentando entender no meu comentário inicial é que, se você possui um MITM ativo (que é o que você precisa para sslstrip em primeiro lugar), o invasor pode ser essencialmente "o site" da perspectiva do cliente; é o invasor que decide se deseja aceitar conexões HTTP simples do cliente, como o servidor da Web se comporta nesse sentido não afeta o que o invasor pode ou fará.
Håkan Lindqvist

@ HåkanLindqvist Exceto pelo fato de que, se o visitante está tentando se conectar intencionalmente com HTTPS, o invasor não pode atender a essa solicitação sem lançar sinalizadores no navegador, a menos que eles tenham conseguido roubar um certificado de servidor ou de alguma forma forjar com êxito um, o que eles teriam que faça para mudar a conexão para HTTP. HTTPS ainda aumenta a fasquia. Obviamente, se o visitante fizer a tentativa inicial de conexão por HTTP, todas as apostas serão completamente desativadas.
Craig

1

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.


1

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.


O problema com o desempenho do HTTPS é que o estabelecimento de uma nova conexão é mais caro, porque há mais viagens de ida e volta e porque a criptografia / descriptografia assimétrica é muito mais cara que a criptografia / descriptografia simétrica. Depois que o handshake de conexão estabelece uma chave de criptografia simétrica compartilhada, a sobrecarga contínua é praticamente irrelevante (muito pequena). Se você ler o SPDY, verá que o objetivo de todas as coisas sofisticadas que ele faz é essencialmente veicular todo o conteúdo de um URL em uma única conexão, mitigando a sobrecarga do handshake de conexão.
19414 Craig

1

É 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>
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.