O que um desenvolvedor PHP precisa saber sobre conexões HTTPS/Secure Socket Layer?

Question

Não sei quase nada quando se trata de como e por que das conexões https.Obviamente, quando estou transmitindo dados seguros, como senhas ou especialmente informações de cartão de crédito, o https é uma ferramenta crítica.O que eu preciso saber sobre isso?Quais são os erros mais comuns que você vê os desenvolvedores cometendo ao implementá-lo em seus projetos?Há momentos em que https é apenas uma má ideia?Obrigado!

Answer 1

Um certificado HTTPS ou Secure Sockets Layer (SSL) é fornecido para um site e normalmente é assinado por uma Autoridade de Certificação (CA), que é efetivamente um terceiro confiável que verifica alguns detalhes básicos sobre o seu site e o certifica para uso em navegadores.Se o seu navegador confiar na CA, ele confiará em quaisquer certificados assinados por essa CA (isso é conhecido como cadeia de confiança).

Cada solicitação HTTP (ou HTTPS) consiste em duas partes:um pedido e uma resposta.Quando você solicita algo por meio de HTTPS, algumas coisas acontecem em segundo plano:

• O cliente (navegador) faz um “handshake”, onde solicita a chave pública e a identificação do servidor.
  • Neste ponto, o navegador pode verificar a validade (o nome do site corresponde?o intervalo de datas é atual?é assinado por uma CA em que confia?).Pode até entrar em contato com a CA e verificar se o certificado é válido.
• O cliente cria um novo segredo pré-mestre, que é criptografado usando a chave pública dos servidores (para que somente o servidor possa descriptografá-lo) e enviado ao servidor
• O servidor e o cliente usam esse segredo pré-mestre para gerar o segredo mestre, que é então usado para criar uma chave de sessão simétrica para a troca de dados real.
• Ambos os lados enviam uma mensagem dizendo que o aperto de mão terminou
• O servidor então processa a solicitação normalmente e criptografa a resposta usando a chave de sessão

Se a conexão for mantida aberta, a mesma chave simétrica será usada para cada um.

Se uma nova conexão for estabelecida e ambos os lados ainda possuírem o segredo mestre, novas chaves de sessão poderão ser geradas em um 'aperto de mão abreviado'.Normalmente, um navegador armazena um segredo mestre até ser fechado, enquanto um servidor o armazena por alguns minutos ou várias horas (dependendo da configuração).

Para mais informações sobre a duração das sessões, consulte Quanto tempo dura uma chave simétrica HTTPS?

Certificados e nomes de host

Os certificados recebem um Nome Comum (CN), que para HTTPS é o nome de domínio.O CN deve corresponder exatamente, por exemplo, um certificado com CN "example.com" NÃO corresponderá ao domínio "www.example.com" e os usuários receberão um aviso em seus navegadores.

Antes SNI, não era possível hospedar vários nomes de domínio em um IP.Porque o certificado é obtido antes mesmo de o cliente enviar a solicitação HTTP real, e a solicitação HTTP contém o Host:linha de cabeçalho que informa ao servidor qual URL usar, não há como o servidor saber qual certificado servir para uma determinada solicitação.O SNI adiciona o nome do host a parte do handshake TLS e, desde que seja compatível com o cliente e o servidor (e em 2015, seja amplamente suportado), o servidor poderá escolher o certificado correto.

Mesmo sem SNI, uma maneira de servir vários nomes de host é com certificados que incluem nomes alternativos de assunto (SANs), que são essencialmente domínios adicionais para os quais o certificado é válido.O Google usa um único certificado para proteger muitos de seus sites, por exemplo.

Outra maneira é usar certificados curinga.É possível obter um certificado como ".example.com", nesse caso "www.example.com" e "foo.example.com" serão válidos para esse certificado.No entanto, observe que "example.com" não corresponde a ".example.com", e nem "foo.bar.example.com".Se você usar "www.example.com" para o seu certificado, você deve redirecionar qualquer pessoa em "Explet.com" para o "www". site.Se eles solicitarem https://example.com, a menos que você o hospede em um IP separado e tenha dois certificados, ocorrerá um erro de certificado.

Claro, você pode misturar curingas e SANs (desde que sua CA permita fazer isso) e obter um certificado para "example.com" e com SANs ".exemplo.com", "exemplo.net" e ".exemplo.net", por exemplo.

Formulários

Estritamente falando, se você estiver enviando um formulário, não importa se a página do formulário em si não está criptografada, desde que o URL de envio vá para um URL https://.Na realidade, os usuários foram treinados (pelo menos em teoria) para não enviar páginas a menos que vejam o pequeno "ícone de cadeado", então até o próprio formulário deve ser servido via HTTPS para conseguir isso.

Tráfego e carga do servidor

O tráfego HTTPS é muito maior do que o tráfego HTTP equivalente (devido à criptografia e sobrecarga de certificado) e também sobrecarrega o servidor (criptografando e descriptografando).Se você tiver um servidor muito carregado, pode ser desejável ser muito seletivo sobre qual conteúdo é servido usando HTTPS.

Melhores Práticas

• Se você não estiver usando HTTPS apenas para todo o site, ele deverá redirecionar automaticamente para HTTPS conforme necessário.Sempre que um usuário estiver logado, ele deverá usar HTTPS e, se você estiver usando cookies de sessão, o cookie deverá ter o conjunto de bandeira segura.Isto evita a interceptação do cookie de sessão, o que é especialmente importante dada a popularidade das redes Wi-Fi abertas (não criptografadas).

• Quaisquer recursos na página devem vir do mesmo esquema usado para a página.Se você tentar buscar imagens de http:// quando a página for carregada com HTTPS, o usuário receberá avisos de segurança.Você deve usar URLs totalmente qualificados ou outra maneira fácil é usar URLs absolutos que não incluam o nome do host (por exemplo, src="/images/foo.png") porque funcionam para ambos.

  • Isso inclui recursos externos (por exemplo, Google Analytics)

• Não faça POSTs (envios de formulários) ao mudar de HTTPS para HTTP.A maioria dos navegadores sinalizará isso como um aviso de segurança.

Answer 2

Não vou me aprofundar no SSL em geral, o gregmac fez um ótimo trabalho nisso, veja abaixo ;-).

No entanto, alguns dos erros mais comuns (e críticos) cometidos (não especificamente PHP) em relação ao uso de SSL/TLS:

1. Permitir HTTP quando você deveria aplicar HTTPS
2. Recuperando alguns recursos por HTTP de uma página HTTPS (por exemplo,imagens, IFRAMEs, etc.)

3. Direcionar para a página HTTP a partir da página HTTPS involuntariamente - observe que isso inclui páginas "falsas", como "about: blank" (já vi isso usado como espaços reservados IFRAME), isso exibirá um aviso desnecessário e desagradável.

4. Servidor Web configurado para suportar versões antigas e inseguras de SSL (por exemplo,O SSL V2 é comum, mas terrivelmente quebrado) (ok, esse não é exatamente o problema do programador, mas às vezes ninguém mais lidará com isso ...)

5. O Web Server configurado para oferecer suporte a suítes cifras não seguras (eu vi cifras nulas apenas em uso, que basicamente não fornecem absolutamente nenhuma criptografia) (idem)

6. Certificados autoassinados – evitam que os usuários verifiquem a identidade do site.

7. Solicitar as credenciais do usuário de uma página HTTP, mesmo se estiver enviando para uma página HTTPS.Novamente, isso impede que um usuário valide a identidade do servidor ANTES de fornecer sua senha...Mesmo que a senha seja transmitida criptografada, o usuário não tem como saber se está em um site falso – ou mesmo se ela SERÁ criptografada.

8. Cookie não seguro - cookies relacionados à segurança (como sessionId, token de autenticação, token de acesso, etc.) DEVE ser definido com o conjunto de atributos "seguro".Isso é importante!Se não estiver definido como seguro, o cookie de segurança, por ex.SessionId pode ser transmitido por HTTP (!) - e os invasores podem garantir que isso acontecerá - permitindo assim o sequestro de sessão, etc.Enquanto você está nisso (embora isso não esteja diretamente relacionado), defina também o atributo HttpOnly em seus cookies (ajuda a mitigar alguns XSS).

9. Certificados excessivamente permissivos – digamos que você tenha vários subdomínios, mas nem todos estão no mesmo nível de confiança.Por exemplo, você tem www.seudominio.com, dowload.seudominio.com e publicaccess.seudominio.com.Então você pode pensar em usar um certificado curinga....MAS você também tem secure.yourdomain.com ou finance.yourdomain.com - mesmo em um servidor diferente.publicaccess.seudominio.com poderá então personificar secure.seudominio.com....Embora possa haver casos em que isso seja aceitável, normalmente você deseja alguma separação de privilégios...

Isso é tudo que consigo lembrar agora, posso reeditá-lo mais tarde...

Quanto a quando é uma MÁ ideia usar SSL/TLS - se você tiver informações públicas que NÃO se destinam a um público específico (seja um único usuário ou membros registrados) E você não tem certeza de que eles as recuperem especificamente de a fonte adequada (por ex.os valores dos tickers da bolsa DEVEM vir de uma fonte autenticada...) - então não há razão real para incorrer na sobrecarga (e não apenas no desempenho...dev/teste/cert/etc).

No entanto, se você tiver recursos compartilhados (por exemplo,mesmo servidor) entre o seu site e outro site MAIS SENSÍVEL, então o site mais sensível deverá definir as regras aqui.

Além disso, senhas (e outras credenciais), informações de cartão de crédito, etc. devem SEMPRE ser via SSL/TLS.

Answer 3

Certifique-se de que, quando estiver em uma página HTTPS, todos os elementos da página venham de um endereço HTTPS.Isto significa que os elementos devem ter caminhos relativos (por exemplo"/images/banner.jpg") para que o protocolo seja herdado ou que você precise fazer uma verificação em cada página para encontrar o protocolo e usá-lo para todos os elementos.

Observação:Isso inclui todos os recursos externos (como arquivos javascript do Google Analytics)!

A única desvantagem que consigo pensar é que isso adiciona tempo de processamento (quase insignificante) para o navegador e seu servidor.Eu sugeriria criptografar apenas as transferências necessárias.

Answer 4

Eu diria que os erros mais comuns ao trabalhar com um site habilitado para SSL são

1. O site redireciona erroneamente os usuários para http de uma página como https
2. O site não muda automaticamente para https quando necessário
3. Imagens e outros ativos em uma página https estão sendo carregados via http, o que acionará um alerta de segurança no navegador.Certifique-se de que todos os ativos estejam usando URIs totalmente qualificados que especifiquem https.
4. O certificado de segurança funciona apenas para um subdomínio (como www), mas na verdade seu site usa vários subdomínios.Certifique-se de obter um certificado curinga se precisar dele.

Answer 5

Eu sugeriria a qualquer momento qualquer os dados do usuário são armazenados em um banco de dados e comunicados, use https.Considere esse requisito mesmo que os dados do usuário sejam mundanos, porque muitos desses detalhes mundanos são usados ​​por esse usuário para se identificar em outros sites.Considere todas as perguntas de segurança aleatórias que seu banco lhe faz (como em que rua você mora?).Isso pode ser obtido facilmente nos campos de endereço.Nesse caso, os dados não são o que você considera uma senha, mas poderiam muito bem ser.Além disso, você nunca pode prever quais dados do usuário serão usados ​​para uma questão de segurança em outro lugar.Você também pode esperar que, com a inteligência do usuário médio da web (pense na sua avó), esse pequeno pedaço de informação possa fazer parte da senha desse usuário em outro lugar.

Um ponteiro se você usar https

faça com que se o usuário digitarhttp://www.website-that-needs-https.com/etc/yadda.phpeles serão redirecionados automaticamente parahttps://www.website-that-needs-https.com/etc/yadda.php(implicação pessoal)

No entanto, se você estiver apenas criando uma página da Web em HTML simples, isso será essencialmente uma transmissão unidirecional de informações do servidor para o usuário, não se preocupe com isso.

Answer 6

Tudo muito boa dica aqui...mas eu só quero acrescentar algo ..
Já vi alguns sites que oferecem uma página de login http e só redirecionam você para https depois de postar seu nome de usuário/senha.Isso significa que o nome de usuário é transmitido de forma clara antes que a conexão https seja estabelecida.

Resumindo, faça a página onde você faz login via SSL, em vez de postar em uma página SSL.

Answer 7

Eu descobri que tentando <link> para uma folha de estilo inexistente também causou avisos de segurança.Quando usei o caminho correto, o ícone de cadeado apareceu.