Por que alguém compraria um certificado SSL?
A principal razão para usar um certificado SSL é criptografar o tráfego entre seu servidor da web e o cliente com uma chave “confiável” verificada por um terceiro independente. Toda a comunicação entre o servidor e o cliente será criptografada para proteger a integridade dos dados. O certificado SSL, quando adquirido de uma Autoridade Certificadora “Compatível com o WebTrust”, pode ser verificado independentemente pelo cliente através dos servidores da CA. A validação de terceiros é o objetivo principal de uma autoridade de certificação. Ele permite que o cliente tenha uma certa confiança inicial com o nome de domínio do servidor. Entenda que o certificado realmente não criptografa os dados, é apenas para que um cliente possa perguntar a um terceiro se o seu domínio é “confiável”.
Se você decidir assinar seu próprio certificado SSL e não usar uma Autoridade de Certificação independente, os clientes receberão um erro sempre que se conectarem ao seu site. O erro explicará que o certificado SSL não pode ser verificado e o site pode não ser confiável. Pior ainda, as versões mais recentes do Firefox e do Opera agora exibirão uma página de aviso e não permitirão que o usuário continue, a menos que escolha.
O que você pode e não pode esperar de um certificado SSL https?
Um certificado comprado de uma Autoridade de Certificação confiável significa simplesmente que um cliente pode verificar a validade do certificado por meio de terceiros. Isso não significa que os dados da página da Web estejam criptografados com segurança, não significa que os dados no site sejam válidos e não significa que os dados não possam ser comprometidos nas máquinas cliente ou do servidor.
Um certificado SSL diz simplesmente que a pessoa ou pessoas que compraram o certificado é a mesma pessoa ou pessoas que possuem o domínio. Esta é a verificação mais simples feita pela Autoridade de Certificação quando uma solicitação de certificado (compra) é feita. Os certificados mais caros exigem que a empresa que solicita o certificado verifique suas credenciais legais. Isso pode significar que eles precisam comprovar a localização física, seu status comercial etc. e as informações de contato para a Autoridade de Certificação e cumprir uma investigação. Esse processo de verificação ampliado é caro e pode levar semanas para ser concluído.
Por que comprar um certificado SSL de uma autoridade de certificação autorizada?
Uma Autoridade de Certificação (CA) é o terceiro que o navegador do cliente remoto usará para verificar seu certificado SSL. Um exemplo de uma CA é uma empresa como a Verisign ou GeoTrust.
Ao se conectar, o cliente negociará (fase de handshake) com seu servidor da Web e seu servidor enviará a chave SSL pública para o cliente. O cliente então se conectará de forma independente à CA para verificar a autenticidade do certificado. Uma vez verificado, o cliente negociará com seu servidor da Web para estabelecer uma conexão segura usando a criptografia SSL. Só então o cliente exibirá o símbolo de “bloqueio” na barra de URL do navegador, indicando que uma conexão segura foi feita.
Ao adquirir um certificado, é de vital importância certificar-se de que a empresa da qual você está comprando é “WebTrust Compliant” e seus servidores estão listados no Módulo de Verificação para cada navegador da web.
O que é “WebTrust Compliant”?
O Programa WebTrust é um programa internacional de comércio eletrônico desenvolvido e gerenciado em conjunto pelo Instituto Americano de Contadores Públicos Certificados e pelo Instituto Canadense de Contadores Avaliados. Você deve questionar todos e quaisquer fornecedores de certificados SSL que não exibam o selo WebTrust. A maioria dos provedores de certificados principais possui seu próprio certificado raiz. Você deve verificar se a CA que você vai usar tem seus próprios servidores para fins de velocidade. Cada cliente que se conecta aos seus servidores se conectará aos servidores da sua CA.
O WebTrust é um processo de auditoria independente executado sob diretrizes do AICPA (American Institute of Certified Public Accountants) projetado para atender às preocupações dos clientes sobre privacidade, segurança e práticas de negócios e significa que a autoridade de certificação atende aos padrões independentes para emissão e gerenciamento de certificados digitais.
O WebTrust é uma revisão abrangente e completa por especialistas independentes qualificados que atende ou excede os padrões de consenso da indústria dos EUA para privacidade estabelecidos pela Online Privacy Alliance. O programa também atende substancialmente às normas da União Européia e do Canadá. O WebTrust inclui privacidade e segurança, mas também inclui confidencialidade, integridade de transações, divulgação de práticas de negócios.
Para manter a conformidade, a AC é obrigada a passar por um programa de escrutínio contínuo com revisões formais pelo menos uma vez a cada 6 (seis) meses. A conformidade com a WebTrust é publicamente representada pelo selo de garantia WebTrust, reconhecido internacionalmente, que é exibido em nossos sites.
Os Certificados de Validação Estendida (EV) são muito mais seguros?
Infelizmente, não. Tem havido algumas preocupações ultimamente de que os certificados EV, apesar de sua autenticação aprimorada, verificações de antecedentes da empresa e custo significativamente mais alto, não impedirão ataques de phishing. Os certificados EV realmente não significam mais segurança criptografada do que os certificados validados pelo domínio. Qualquer elemento criminoso pode enviar a papelada e pagar algumas centenas de dólares por mês por um certificado de “barra verde”. Mas os usuários não percebem essa barra verde?
Em 2006, pesquisadores da Universidade de Stanford e da Microsoft conduziram um estudo de usabilidade da tela “URL verde” no Internet Explorer 7. O estudo mediu a capacidade do usuário de distinguir sites reais de sites fraudulentos quando apresentou vários tipos de ataques de phishing. Eles descobriram que não havia diferença significativa entre os usuários que viram indicadores de validação estendidos e aqueles que não viram.
Pior ainda, quando os usuários recebiam treinamento com o arquivo de ajuda do Internet Explorer 7, eles eram mais propensos a julgar Todos os sites legítimos, independentemente de serem fraudulentos ou não.
É mais provável que os usuários que realmente notaram o URL verde aprendam que o marcador não é confiável e começam a ignorá-lo. A maioria dos usuários nem presta atenção aos avisos do navegador; clicando nos botões “OK” ou “Próximo” às cegas.
Que tipo de criptografia deve ser usado?
Breve História do 3DES e AES
O passe único DES foi desenvolvido pela primeira vez em 1977. O DES realiza a manipulação de bits em caixas de substituição e permutação em cada um dos 16 ciclos. O DES criptografa dados em tamanhos de bloco de 64 bits que efetivamente usam uma chave de 56 bits. O espaço da chave de 56 bits equivale a aproximadamente 72 quadrilhões de possibilidades. Mesmo que isso pareça um monte de permutações, os computadores de hoje são poderosos e baratos o suficiente para quebrar essa cifra em minutos.
Como o DES estava amplamente disponível, a solução rápida na época era introduzir o 3DES, que era “seguro o suficiente” para a maioria das finalidades. 3DES é a construção simples da aplicação de DES três vezes em seqüência usando três chaves diferentes (K1, K2 e K3) e tem um comprimento de chave efetivo de 168 bits. A Wikipedia no DES tem mais exemplos.
Há dez anos, uma versão modificada do algoritmo Rijndael foi selecionada como AES (Advanced Encryption Standard) para substituir o 3DES. A combinação de segurança, desempenho, eficiência, implementabilidade e flexibilidade do Rijndaels o tornou uma seleção apropriada para o Advanced Encryption Standard (AES).
Por design, DES e, portanto, 3DES / TDES, sofrem de desempenho lento em software, mesmo em processadores modernos, o AES tende a ser cerca de seis vezes mais rápido. Por design, o AES é mais rápido através de software e eficiente em hardware. Ele funciona rápido mesmo em dispositivos pequenos, como smart phones, smart cards, etc. O AES oferece mais segurança que o 3DES devido aos tamanhos maiores de blocos e chaves mais longas. AES usa tamanho de bloco fixo de 128 bits e funciona com chaves de 128, 192 e 256 bits. A Wikipedia no AES tem exemplos e gráficos lógicos.
De acordo com o NIST, o AES é o substituto do 3DES e ambos os cifradores coexistirão até o ano 2030, permitindo a transição gradual para o AES. Embora o AES tenha a vantagem teórica sobre o 3DES em termos de velocidade e eficiência, algumas implementações de hardware do 3DES podem ser mais rápidas quando o suporte para o 3DES está maduro.
Usando o AES para a chave SSL e permitindo tanto o AES quanto o 3DES para o handshake
AES é o tipo de criptografia mais forte e queremos usá-lo para criar nosso certificado SSL. Mas, você pode precisar permitir 3DES, bem como handshake AES, para que navegadores mais antigos, como o Internet Explorer 6 e BOTS, como o MSNbot, possam se conectar.
Como solicitar um certificado SSL de uma autoridade de certificação (CA)
Quando você escolhe uma autoridade de certificação e passa pelo processo de compra, ela eventualmente pedirá uma Solicitação de Assinatura de Certificado (CSR) . Essa é uma chave SSL pública que você fornecerá a eles, eles assinarão e enviarão uma cópia para você usar em seu servidor.
Para criar uma chave CSR no Linux ou BSD para o Apache, o Lighttpd ou o Nginx usam o binário do OpenSSL. A seguir, será feita uma chave AES de 256 bits usando um comprimento de chave de 4096 bits (RSA / 4096 bits). Uma chave de 4096 bits é obrigatória pelo FIPS 140-2 . Essa é a chave mais forte com a criptografia mais forte suportada por 99% dos navegadores e BOTs de pesquisa. Quando a chave privada é feita, ela pedirá uma frase secreta. Digite qualquer string, sentença ou fase que você deseja que seja maior que 8 caracteres (quanto maior, melhor e espaços são aceitos). A frase secreta será como uma senha e você precisará digitá-la para iniciar qualquer servidor da Web usando a chave SSL. Você tem a opção de apenas digitar e não inserir uma frase secreta, mas isso não é considerado uma boa segurança.
root @ mach $ openssl genrsa -aes256 4096> server.key
Gerando chave privada RSA, módulo de 4096 bits
……………. ++++++ … muitas linhas são impressas quando a chave é gerada …
……………. ++++++
e é 65537 (0x10001)
Digite a frase secreta:
Verificando – Digite a frase secreta:
Agora que a chave privada é feita, precisamos criar uma chave pública de CSR. Esta é a chave que forneceremos à autoridade de certificação para sua verificação e assinatura. Quando você fizer a chave do CSR, você terá algumas perguntas para responder. É uma boa ideia preencher essas informações com veracidade, porque a Autoridade de Certificação as verificará com suas descobertas. Se as informações não coincidirem, elas podem negar sua solicitação. Depende da sua AC, mas a maior parte do tempo a informação inserida neste arquivo CSR não será tornada pública.
A seguinte janela rolável tem um exemplo das perguntas que você fará. O “Nome da Unidade Organizacional”, “Endereço de E-mail”, “senha do desafio” e “nome da empresa opcional” não são absolutamente necessários e podem ser deixados de fora se você escolher.
A questão mais importante é o nome comum e ele deve ser igual ao nome do domínio que o seu servidor da Web executa. Quando os clientes remotos se conectarem ao seu nome de domínio, digamos “www.mydomain.com”, eles verificarão se o domínio ao qual eles se conectam é igual ao Nome Comum na chave CSR. Se os dois não corresponderem ao cliente, produzirá um erro para o usuário.
root @ mach $ openssl req -sha256 -new -key server.key -out server.csr
Digite a senha para server.key:
Você está prestes a receber informações que serão incorporadas no seu pedido de certificado.
O que você está prestes a entrar é o que é chamado de Nome Distinto ou DN.
Existem alguns campos, mas você pode deixar alguns em branco
Para alguns campos, haverá um valor padrão,
Se você digitar ‘.’, O campo será deixado em branco.
—–
Nome do país (código de 2 letras) []: País
Nome do Estado ou Província (nome completo) []: Estado
Nome da localidade (por exemplo, cidade) []: Cidade
Nome da organização (por exemplo, empresa) []: Empresa
Nome da Unidade Organizacional (por exemplo, seção) []:
Nome comum (por exemplo, nome completo do host) []: www.mydomain.com
Endereço de e-mail []:
Por favor insira os seguintes atributos ‘extras’
para ser enviado com o seu pedido de certificado Uma senha de desafio []:
Um nome de empresa opcional []:
Se você olhar em seu diretório atual, deverá ver o server.key e o server.csr . Agora precisamos enviar o server.csr para a Autoridade de Certificação. Cada empresa é diferente, mas a maioria permitirá que você copie / cole o conteúdo do server.csr em uma caixa de aplicativo de página da web. A saída da sua chave CSR deve ser parecida com o formato a seguir, mas a sua será mais longa. Este é apenas um exemplo abreviado:
----- INÍCIO DO PEDIDO DE CERTIFICADO ----- MIIBkTCB + wIBADBSMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUQxDTALBgNVBAcT BENpdHkxEDAOBgNVBAoTB0NvbXBhbnkxFTATBgNVBAMTDG15ZG9tYWluLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyMUWNj9T4fyPhls573vU7 / RO5e2O ZZpDuBqXqicUNUxYJWPkjkEhM28z + rSZJt0KuvuNdfMPAcaZSHH / IVWfd36CIwOz dbdG8dQja1lhQN91mceTCtXCi9MkojpKmNeo8jFnoqEMEV3KL3 / 6upFfLQWQsF5I bLDUrPfrrKRlvHUCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBAGXeAT / niVJfgxFH 7zC10k6hCaiGlOlFCTONaKAN71P4qg4fJ7VxAAFaob1shOxV6vPjd9Q85rPV5qxU orQ + ytxYdO8YbAwTBEMAGQcQM1 + lSyeXZNyBnTigkqtaXNDkZRZETgQFuXa19ykn nUx + yXPT6gMoK / 2MuH4RIir44DIM ----- PEDIDO DE CERTIFICADO FINAL -----
Depois que você enviar sua chave pública de CSR para a empresa da CA, ela deverá enviar dois arquivos para você; provavelmente por e-mail ou para download através do site da CA. Esses dois arquivos serão o arquivo “crt” de seu domínio e um arquivo “crt” incluído da autoridade de certificação. O arquivo crt do seu domínio será o certificado assinado apenas para o seu nome de domínio. O arquivo crt incluído será para todos os servidores de certificados de verificação da CA.
Neste ponto, a geração dos certificados é feita. Lembre-se de guardá-los, não os perca e não permita que ninguém os tenha. Agora você precisa decidir qual servidor da Web usará e como configurar o SSL para trabalhar com esse servidor. Dê uma olhada em nossa home page para links para configurar muitos dos servidores web mais populares como o Nginx.
Os tópicos a seguir abrangem os detalhes técnicos do SSL
Entendendo o processo de handshake SSL
Quando um cliente se conecta ao servidor, há um handshake criptografado. Durante esse período, os dois sistemas usam uma codificação inicial para negociar com segurança o uso posterior de seu certificado SSL. Você deve certificar-se de usar as cifras mais compatíveis, assim como as mais fortes, disponíveis para o seu servidor para a maioria dos clientes que irão se conectar. AES é a melhor cifra, mas os clientes mais antigos, como o IE6 e os BOTs, como o MSN, ainda não entendem esse aperto de mão da cifra. Portanto, para permitir que 99% de compatibilidade dos clientes possam se conectar ao seu servidor, certifique-se de usar as cifras de handshake 3DES e AES. A maioria dos servidores da web sabe disso como o nível de codificação “ALTO”.
Como o handshake SSL funciona
O handshake é o processo chave para um cliente e um servidor trocarem informações de autenticação e criptografia em SSL ou TLS. Essencialmente, o SSL consiste em duas fases correspondentes a dois sub-protocolos. O protocolo SSL Handshake Protocol rege a primeira fase para estabelecer comunicação segura. Subseqüentemente, todas as mensagens são criptografadas e trocadas usando o protocolo de registro SSL .
- Estabeleça a identidade do servidor conectando-se ao domínio.
- Desenvolva uma chave de criptografia compartilhada que possa ser usada para trocar mensagens, chamada de chave de sessão. Lembre-se que o MSNBot só entende handshakes 3DES neste momento. O Googlebot e o Yahoo fazem handshakes AES sem problemas.
- Cliente: Olá, aqui está uma lista de algoritmos de criptografia que eu conheço.
- Servidor: Olá, aqui está o algoritmo que escolhi da sua lista. Além disso, aqui está meu certificado e chave pública. Se o servidor não aceitar nenhum dos algoritmos do cliente (talvez eles sejam muito fracos), o servidor enviará um erro 400 e fechará a conexão.
- O cliente examina o certificado e garante que ele seja assinado por uma autoridade de certificação (CA) conhecida.
- Cliente: OK, aqui está o segredo pré-mestre criptografado com sua chave pública.
- Agora, o cliente e o servidor podem usar o segredo pré-mestre para calcular a chave de sessão: a chave de criptografia para as mensagens subsequentes. Normalmente, o servidor e o cliente continuam usando essa chave de sessão até o tráfego parar. Neste ponto, a chave irá expirar em 300 segundos (5 minutos). Qualquer tráfego solicitado após o tempo limite renegociará automaticamente outra chave de sessão.
- Cliente: [criptografado] Estou acabado com o aperto de mão.
- Servidor: Entendi. Espere uma resposta criptografada.
- Servidor: [criptografado] Estou acabado com o aperto de mão.
- Todas as mensagens subsequentes são criptografadas com a chave criptografada SSL do servidor.
O handshake: Listar cifras da versão do protocolo SSLv3 e chaves de 128 bits ou superiores (HIGH:! ADH:! MD5).
Para descobrir quais códigos sua máquina suportará, você pode consultar o OpenSSL usando o argumento ciphers. É altamente recomendável usar a versão 3 do SSL, pois a versão 2 tem vulnerabilidades. Finalmente, você pode solicitar todas as cifras que usam cifras de significado de força de codificação HIGH de 128 bits ou mais, mas sem DH ou MD5 anônimo.
root @ mach $ openssl cifras -ssl3 -v 'ALTA:! ADH:! MD5: @STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx = DH Au = RSA Enc = AES (256) Mac = SHA1 DHE-DSS-AES256-SHA SSLv3 Kx = DH Au = DSS Enc = AES (256) Mac = SHA1 AES256-SHA SSLv3 Kx = RSA Au = RSA Enc = AES (256) Mac = SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx = DH Au = RSA Enc = 3DES (168) Mac = SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx = DH Au = DSS Enc = 3DES (168) Mac = SHA1 DES-CBC3-SHA SSLv3 Kx = Au RSA = RSA Enc = 3DES (168) Mac = SHA1 DHE-RSA-AES128-SHA SSLv3 Kx = DH Au = RSA Enc = AES (128) Mac = SHA1 DHE-DSS-AES128-SHA SSLv3 Kx = DH Au = DSS Enc = AES (128) Mac = SHA1 AES128-SHA SSLv3 Kx = RSA Au = RSA Enc = AES (128) Mac = SHA1
Cada coluna no comando "openssl ciphers" significa:
- Nome de criptografia oficial
- SSLv3 é o tipo de soquete seguro (o TLSv1 usa os mesmos SSTs)
- Kx = troca de chaves (DH é diffie-hellman)
- Au = autenticação
- Enc = criptografia com tamanho de bit
- Mac = algoritmo de criptografia mac
A string “@STRENGTH” é usada para ordenar a lista de cifras atual na ordem do tamanho da chave do algoritmo de criptografia (256, 168, 128), desde a mais longa na parte superior até a mais curta na parte inferior. Na verdade, o AES 256 é mais forte do que o AES 128bit, que é significativamente mais seguro que o 3DES 168bit.
As cifras padrão do SSL no Apache, Lighttpd, Nginx são fracas
Certifique-se de especificar as criptografias de SSL que seu servidor da web usará em sua configuração para pelo menos o nível “ALTO:! ADH”. Isso significa chaves AES e DES acima de 128 bits, mas não chaves anônimas DH. A maioria dos servidores da Web tenta ser tão compatível quanto possível por padrão e aceita chaves DES de 40, 56 e 80 bits. Estes são incrivelmente fracos e são rotulados como aceitáveis de acordo com as leis de controle de exportação dos EUA. É altamente recomendável negar cifras fracas aceitando apenas handshakes 3DES / TDES e AES ssl cifra de pelo menos 128 bits e acima. Depois que o GoogleBot e o MSNbot começarem a aceitar handshakes AFS do PFS, poderemos limitar nossas cifras ssl apenas a “AES”. De acordo com o NIST, o 3DES deve ser desativado até 2030.
O que o SSL criptografa?
O caminho e a string de consulta são criptografados em uma solicitação HTTPS “get” (onde as respostas de campo de formulário ou variáveis de programa são marcadas no final do URL). Esses campos são removidos da URL ao criar as informações de roteamento no processo de empacotamento HTTPS pelo navegador e são incluídas no bloco de dados criptografados. Os dados da página (formulário, texto e string de consulta) são passados no bloco criptografado depois que os métodos de criptografia são determinados e o handshake é concluído.
Um problema relacionado que surge frequentemente é se os dados do formulário são transmitidos ou não com criptografia se um formulário em branco for exibido sem HTTPS. Se o formulário “action” estiver configurado para usar HTTPS, o handshake SSL ocorrerá antes que os dados sejam enviados. Se o formulário original é exibido ou não usando HTTPS, isso tem pouco a ver com o envio do formulário, a menos que a ação do formulário use um caminho relativo. Nesse caso, o padrão será usar o protocolo usado para exibir o formulário. Isso se aplica tanto à solicitação quanto à resposta.
Considerações sobre desempenho de SSL
As considerações de largura de banda do servidor não são um problema para a maioria das pequenas e médias empresas. Transações SSL aumentarão em cerca de 1 kilobyte por ação do cliente e cerca de 5 kilobytes na primeira vez que um cliente negociar a conexão SSL com o servidor.
Processador do Servidor uso do é aumentado com conexões SSL, mas isso deve ser apenas uma preocupação em servidores que executam centenas de transações por minuto. Uma pequena empresa com 50 transações por minuto usando criptografia AES256 pode ser facilmente executada em um servidor de 2 GHz com uma carga média de 20.
O uso de RAM do servidor não é afetado seriamente como criptografia SSL. O único RAM usado é salvar as informações da sessão negociada cliente / servidor por um padrão de 300 segundos. A menos que você tenha centenas de conexões por minuto, uma máquina com 2 GB de memória RAM deve funcionar bem.
Definir os cabeçalhos Expirar e Cache no servidor da Web para páginas criptografadas por SSL permitirá que um cliente armazene em cache as páginas somente na RAM. Por motivos de segurança, as páginas enviadas criptografadas para um navegador do cliente NÃO serão armazenadas em cache no disco. Esta é uma diretiva de segurança / privacidade definida no navegador do cliente e não pode ser alterada por um servidor da web. Você pode notar se você olhar para as “informações da página” através de um navegador que o campo “Expires” está em branco. Isso ocorre simplesmente porque o cliente não salvará uma cópia da página no disco. Uma cópia da página permanecerá na RAM dos clientes até que expire, seja limpa por considerações de espaço ou quando o navegador estiver fechado; que vem primeiro. Se você gostaria de verificar os cabeçalhos na linha de comando, você pode usar o binário “curl -I –compressed https: // localhost”.
Os bots como o GoogleBot, o MSNbot e o Yahoo Slurp indexam páginas criptografadas por SSL?
Sim. Os bots mais populares indexarão páginas criptografadas por SSL se tiverem permissão em seu arquivo robots.txt. Por exemplo, digite “site: calomel.org” em uma pesquisa do Google e você verá que eles já sabem sobre nossas páginas HTTPS.
O que você deve lembrar é que todos os bots lerão páginas criptografadas AES criptografadas usando a chave SSL AES256 bits, mas o Google e o MSN NÃO NEGARÃO usando um handshake AES. É importante certificar-se de que o seu servidor web permite tanto o AES como o GoggleBot, o MSN bot e o IE6 podem se conectar. Isso é conseguido com a permissão de criptografias de grau “HIGH:! ADH” através do seu servidor web.
Se eu usar SSL nas minhas páginas, seremos maiores do que as páginas não-SSL do PageRank? Até agora, NÃO há provas conclusivas de que um site SSL obterá uma classificação mais alta na classificação de pesquisa do Google / MSN / Yahoo em comparação com o mesmo site que não está criptografado. Na verdade, parece não haver resultado positivo ou negativo se você tiver suas páginas criptografadas ou não. Isso ocorre porque a qualidade dos dados no site não é validada pelo SSL, apenas que o certificado é verificado independentemente. O fator mais importante no PageRank do Google, por exemplo, é a quantidade de sites de alta qualidade com links para seu site. A ideia é que, se um site como o Digg ou CNN link para o seu site, em seguida, o seu page rank irá aumentar porque o seu page rank é alto. Isso é totalmente independente de a sua página estar criptografada ou não.
Posso usar o Google Adsense, o Analytics ou outros dados não criptografados nas minhas páginas SSL?
Não. Todos os dados em uma página criptografada por SSL DEVEM ser criptografados. Os dados podem vir de vários servidores e vários certificados SSL, mas todos os dados DEVEM ser criptografados.
Se SSL criptografarmos nossas páginas, o recebimento de clientes espera que TODOS os dados carregados dessa página sejam criptografados por segurança. Se houver algum dado no texto não criptografado, como anúncios ou script Java carregado de um servidor de anúncios, o navegador do cliente avisará o usuário de que “alguns dados foram enviados sem criptografia”. A barra de URL do navegador não ficará amarela (ssl) ou verde (EV ssl) e o pequeno símbolo de bloqueio terá uma linha diagonal que significa que a página NÃO foi totalmente criptografada. Agora, o usuário remoto não tem certeza se a transmissão de seus dados é segura e, portanto, não confia em seu site. Isso anula completamente o propósito de ter um certificado SSL e criptografia de página.
Se você espera veicular anúncios, análises do Google ou qualquer script Java em sua página que carregue na clareza de terceiros, não torne essas páginas criptografadas.
E quanto ao suporte do navegador para o OCSP (Online Certificate Status Protocol)?
O protocolo OCSP (Online Certificate Status Protocol) é usado para obter o status de revogação de um certificado digital X.509. Na maioria dos navegadores, você pode permitir que o OCSP verifique com um servidor de terceiros se o certificado SSL com o qual você está negociando ainda é válido.
O Internet Explorer a partir da versão 7 no Windows Vista (não no XP) oferece suporte à verificação do OCSP. Todas as versões do Firefox suportam a verificação do OCSP, mas estão desabilitadas por padrão. O Firefox 3 permitirá a verificação do OCSP por padrão. O Safari no Mac OS X suporta a verificação do OCSP. Versões posteriores (após 2008) do Opera suportam a verificação do OCSP.
Sugerimos ativar o OCSP no seu navegador. Não é uma solução para ataques de phishing, mas simplesmente outra camada de verificação.
Observe que os critérios para emissão de certificados de Validação Estendida (EV) não exigem que as Autoridades de Certificação suportem imediatamente o Protocolo de Status de Certificados Online para verificação de revogação. A exigência de uma resposta oportuna às verificações de revogação pelo navegador levou a maioria das autoridades de certificação a implementar o suporte ao OCSP. A seção 26-A dos critérios de emissão exige que as CAs ofereçam suporte à verificação do OCSP para todos os certificados.
Teste sua configuração de servidor da Web SSL
Quando terminar de configurar seu servidor da web, é uma boa ideia descobrir se ele está funcionando corretamente. Sugerimos que você use o Qualys SSL Labs para testar seu site. O site é totalmente gratuito e os dados coletados estão sendo estudados por milhões de servidores web baseados em SSL em todo o mundo. Eles executarão uma série de testes do OpenSSL e gerarão um relatório para você. Então você pode ver os resultados e comparar sua configuração com o que o SSL Labs considera uma configuração segura. Então você pode ver onde você classifica contra outros sites. Atualmente, nosso site classifica um “A” a 93%, por exemplo.
Ataques conhecidos em SSL / TLS para estar ciente de
Embora os protocolos SSL / TLS ofereçam um alto nível de segurança em teoria, suas implementações reais podem ser vulneráveis a vários tipos de ataques. Dos muitos vetores de ataque, estes são dignos de atenção especial:
Homem no meio (MITM) ataca. Nesse tipo de ataque, um intruso intercepta o tráfego que está sendo enviado entre um cliente e um servidor, como forjar respostas DNS ou executar o redirecionamento ARP. Em seguida, ele representa o cliente para o servidor e vice-versa. Durante esse ataque, o navegador da Web do usuário não se conecta diretamente ao servidor de destino, mas ao host do intruso, que representa o navegador da Web e age essencialmente como um proxy.
Há boas e más notícias para um administrador que deseja se defender contra tais ataques. A boa notícia é que os navegadores da Web avisam os usuários quando a identidade do servidor da Web não pode ser verificada, o que pode indicar um possível ataque man-in-the-middle, exibindo uma janela de mensagem com um aviso. A má notícia é que, na vida real, os usuários muitas vezes ignoram esses avisos. Portanto, se o navegador da Web do usuário aceitar conexões a sites da Web SSL cujas identidades não puderem ser verificadas, só podemos confiar na educação dos usuários e confiar que eles não pressionarão o botão “continuar”, se essa mensagem de aviso tiver sido exibida.
Ataque a força bruta na chave da sessão. Esses ataques podem ser executados quando o invasor sabe ou pode assumir parte do texto não criptografado que foi enviado durante a sessão SSL / TLS, como (como “GET / HTTP / 1.0”), e o intruso pode escutar essa sessão (por usando tcpdump, Ethereal ou outras ferramentas). Então, o intruso pode criptografar a parte do texto usando todas as chaves possíveis, tentando encontrar sua ocorrência no tráfego SSL / TLS originalmente criptografado. Quando essa ocorrência for encontrada, a chave usada para criptografar essa parte da mensagem pode ser usada para descriptografar o restante do tráfego SSL / TLS originalmente criptografado.
A boa notícia é que o número máximo de chaves que devem ser verificadas é 2 ^ 128 quando a criptografia simétrica de 128 bits é usada. Hoje acredita-se que este seja forte o suficiente para proteger a sessão por literalmente dezenas de anos. No entanto, como os processadores crescem em força a cada ano, não podemos prever por quanto tempo as chaves simétricas de 128 bits serão consideradas seguras, principalmente para hackers com acesso a grandes supercomputadores.
No caso de conjuntos de cifras de classe de exportação (40 bits e em algumas cifras de 56 bits estendidas), esses ataques de força bruta podem ser executados com sucesso em um período de tempo razoável – às vezes em alguns dias, dependendo do número disponível. CPUs. Se os regulamentos de exportação em seu país permitirem o uso de criptografia robusta, deve-se definitivamente usá-lo em vez de conjuntos de cifras de classe de exportação.
Além dos dois tipos de ataques listados acima, há algumas outras vulnerabilidades potenciais, incluindo ataques de reversão de algoritmos, ataques de temporização, análise de tráfego, ataques de Bleinchenbacher e outros. Os interessados em entendê-los podem encontrar mais informações no documento de Bruce Schneier e David Wagner, “Análise do protocolo SSL 3.0” (documento PDF), bem como em muitos outros documentos que podem ser encontrados na Internet pública. Erros típicos de implementação de SSL / TLS
Certificados assinados por uma autoridade de certificação desconhecida pelo navegador da Web.:. O maior erro que pode ser cometido ao implementar o SSL / TLS é com a assinatura do certificado do servidor da web por uma CA que não é confiável pelos navegadores da web. Por exemplo, o CAcert.org não está listado em nenhum navegador baseado no Mozilla. O certificado da CA não está instalado no navegador da Web e isso torna os ataques Man-In-The-Middle muito fáceis de serem executados, porque os usuários não têm como verificar a identidade do servidor da web.
Para evitar esse problema, é importante certificar-se de que o certificado do assinante (geralmente, uma CA confiável) esteja instalado no navegador da Web do usuário. Se uma autoridade de certificação local foi usada para assinar o certificado do servidor da Web, devemos nos certificar de que todos os navegadores da Web em todos os clientes que exigem acesso tenham o certificado da autoridade de certificação local instalado. A mesma regra se aplica a certificados autoassinados.
Certificados expirados:. O certificado do navegador da web deve ser renovado antes que o anterior expire. Caso contrário, isso resultará no mesmo problema acima, pelo qual os clientes da Web não poderão se autenticar com o servidor da Web – o que mais uma vez torna as conexões SSL / TLS vulneráveis ao homem nos ataques do meio. Nesse caso, os usuários podem se acostumar a ver uma mensagem de aviso informando que o certificado expirou e, provavelmente, não perceberão se é um certificado falso.
Versões vulneráveis do OpenSSL e Apache.:. É muito importante sempre executar as versões mais recentes do OpenSSL e do Apache. Os programadores que escrevem pedaços de código maiores, como estes, sem bugs são virtualmente impossíveis, por isso devemos sempre usar as últimas versões estáveis do software acima. As versões mais recentes devem, teoricamente, conter menos vulnerabilidades de segurança (descobertas e ainda não descobertas) do que as versões anteriores.
Aceitação de SSL v2.0, autenticação anônima (aNULL) e criptografia (NULL) pelo servidor da Web.:. Como foi discutido anteriormente, o uso de conjuntos de criptografia que suportam autenticação anônima ou não exigem criptografia deve ser desabilitado. Caso contrário, existe o risco de que o cliente possa ser enganado para negociar parâmetros que possam reduzir drasticamente o nível de segurança da conexão. Por esse motivo, devemos desativar o uso do protocolo SSLv2.0 e usar TLSv1.0 ou SSLv3.0.
Uso de criptografia fraca.:. As primeiras implementações do SSL só foram capazes de usar chaves de 40 bits para criptografia simétrica, devido a restrições do governo dos EUA. Infelizmente, os dados criptografados por chaves simétricas de 40 bits agora podem ser descriptografados em um período de tempo relativamente curto e, por esse motivo, as chaves de 40 e 56 bits não devem mais ser usadas. A maioria dos navegadores modernos suporta chaves de 128 bits para criptografia simétrica, e agora é a chave de comprimento mínima recomendada para uso com SSL / TLS.
Uso indevido de um Sistema de Detecção de Intrusos em Rede (NIDS). É importante ressaltar que, a menos que um NIDS seja capaz de descriptografar o tráfego SSL (como por meio do uso da chave privada do servidor da Web), ele simplesmente não poderá detectar ataques no aplicativo da Web. Para detectar eventuais invasões, devemos usar um sistema de detecção de intrusos baseado em host (HIDS) ou colocar o NIDS em um segmento no qual o tráfego SSL / TLS está sendo enviado em texto não criptografado, como entre um proxy reverso SSL e o farm do servidor da web. Caso contrário, talvez não consigamos detectar nenhum ataque, exceto a negação de serviço, realizado contra o servidor da web.
Permitindo acesso não apenas via SSL, mas também via protocolos não criptografados (HTTP).:. Configurar o SSL / TLS e abrir a porta 443 / tcp para o servidor da web, por si só, não significa nada se os usuários ainda puderem acessar o site via HTTP não criptografado na porta 80 / tcp. Assim, é preciso verificar novamente se o conteúdo protegido não pode ser acessado via HTTP ou outros protocolos não criptografados (incluindo FTP, Samba, NFS e assim por diante). Também é importante lembrar que chapéu é um BOT de busca, como o GoogleBot pode ver a mesma página em HTTP e HTTPS, então o Google pode remover a página completamente do seu índice. Permitir apenas que uma página seja visualizada a partir de HTTPS OU HTTP, nunca de ambas.
Máquinas clientes vulneráveis.:. Quando nos concentramos em proteger os servidores da Web, podemos esquecer facilmente a segurança das máquinas clientes. Se eles estiverem comprometidos, a segurança do SSL / TLS também será comprometida. Nesse caso, os invasores podem fazer o que quiserem com os anfitriões do cliente, tais como substituir certificados em navegadores web, instalar keyloggers, mudança / etc / hosts para redirecionar as solicitações da Internet para servidores web falsas, ou até mesmo roubar certificados de cliente se eles foram marcados como “exportável”.
Portanto, se as máquinas clientes estiverem sob nosso domínio administrativo, precisamos ter muito cuidado com sua segurança. Habilitar um firewall pessoal, software antivírus / antispyware e ativar as atualizações automáticas do Windows deve ser o mínimo absoluto. Mais importante ainda, as versões de navegadores da Web devem estar sempre atualizadas.
Também é recomendado que se apliquem as seguintes opções (relacionadas ao SSL / TLS) à configuração do navegador da Web:
- A verificação da revogação de certificados de um editor deve estar ativada
- a verificação de qualquer revogação de certificado do servidor deve ser ativada
- as páginas do servidor criptografadas não devem ser armazenadas no cache
- o uso de SSLv2.0 deve ser desabilitado, e somente TLSv1.0 e SSLv3.0 devem permanecer habilitados
- a exibição de avisos sobre certificados de servidores da Web inválidos deve ser ativada
Usando os mesmos IDs de sessão / cookies para SSL e HTTP.:. É possível ter uma configuração do Apache que aceite solicitações HTTP e HTTPS no mesmo servidor, como um site de informações acessível via HTTP e uma parte de transação acessível via HTTPS. Nesse caso, devemos ter muito cuidado em nosso aplicativo da Web para não usar os mesmos IDs / cookies de sessão para os dois protocolos. Caso contrário, um intruso pode detectar o tráfego HTTP entre o servidor da Web e a vítima e pode tentar usar IDs de sessão para obter acesso à parte autorizada do aplicativo da Web via SSL.