Existe alguma coisa inerentemente mais insegura sobre o uso de um certificado SSL curinga em um certificado SSL regular?
Estamos procurando implementar um aplicativo da Web subdominio (a la FreshBooks e o BaseCamp, onde os usuários escolhem um subdominio), e um dos membros da nossa equipe está preocupado que uma abordagem SSL curinga não seja segura o suficiente (em caso afirmativo, como o FreshBooks e o BaseCamp faz isso?!?).
A solução alternativa é usar um único subdomínio, como https://ssl.domain.com , e quando um usuário digita http://user.domain.com , definimos o subdomínio na sessão e redirecionamos imediatamente as solicitações futuras do usuário para " link " e use as informações da sessão para mostrar as informações do usuário.
Minha preocupação é que, se um usuário quiser enviar um link para seu domínio a um amigo, ele copiará / colará o URL no navegador (agora https://ssl.domain.com ), que será nossa página inicial principal, e não o usuário página inicial.
BTW, se eu perdi uma das melhores práticas recomendadas para este tipo de cenário, por favor me avise.
No meu conhecimento, não há diferença entre os certificados curinga e normal. Contanto que você tenha controle total sobre o DNS de domain.com , não há motivo para não usar um caractere curinga. Na verdade, eu recomendaria no seu caso. Quais são suas preocupações específicas com eles?
(IMO, Redirecionamentos como o que você sugere são sempre um pouco de fudge quando são visíveis para o usuário final.)
De um aspecto técnico, seria igualmente seguro. Você ainda estaria usando a mesma criptografia que faria com um certificado não curinga. O que eles estão dizendo é menos seguro?
Como SmallClanger aponta, desde que você tenha controle total sobre o domínio e quaisquer subdomínios possíveis, não há problemas de segurança inerentes. Uma possível desvantagem é que você não pode obter um certificado Wildcard EV, portanto não há barra verde para os poucos usuários que o procuram.
Concordo com as outras respostas, que os certificados curinga não são inerentemente inseguros.
No entanto, é possível introduzir um problema de segurança usando certificados curinga incorretamente. O seguinte problema de segurança não aconteceria se seus certificados fossem válidos apenas para um domínio.
Imagine que você inicialmente tenha um único servidor hospedando todos os subdomínios. O adversário se inscreve no seu serviço e recebe o domínio evil.example.com . Isso, como todos os outros clientes, é coberto pelo certificado de *.example.com .
O adversário organiza o evil.example.com para receber muito tráfego, então, eventualmente, esse domínio recebe um servidor dedicado. Agora você tem dois servidores físicos com certificado idêntico.
Neste ponto, o adversário começa a realizar ataques MITM (não importa se isso acontece por envenenamento de DNS ou por APs mal-intencionados). O adversário direciona os usuários de legitimate.example.com para o endereço IP de evil.example.com . Como o certificado diz *.example.com , é válido.
No entanto, o servidor dedicado para evil.example.com não sabe o nome do domínio legitimate.example.com , então ele responde com o conteúdo do vhost padrão, que será evil.example.com porque esse servidor dedicado não tem nenhum outros domínios.
Esse cenário de ataque pode ser evitado se todos os servidores que possuem o certificado puderem responder a solicitações de todos os subdomínios. É perfeitamente aceitável, se isso, às vezes, significar a intermediação do pedido de um servidor para outro. Contanto que o proxy esteja protegido contra ataques MITM.
Em uma configuração adequada, o servidor dedicado para evil.example.com só começará a receber solicitações para legitimate.example.com quando o adversário tentar executar um ataque MITM aos usuários. Ele não poderá armazenar o conteúdo e, em vez disso, fará o proxy da solicitação para o servidor real que hospeda legitimate.example.com .
Se o adversário receber controle suficiente sobre o servidor dedicado que hospeda evil.example.com para desabilitar esse proxy, você terá um problema real de segurança.
Certificados curinga trazem risco adicional em alguns cenários. Se esses cenários são aplicáveis a você e se você considera que o risco adicional aceitável é algo que você terá que determinar no contexto.
Digamos que todos os seus subdomínios estejam em um servidor. Neste caso, não faz virtualmente nenhuma diferença a segurança se você tiver um certificado curinga, um certificado multi-nome ou certificados separados para cada site. Se um invasor comprometer seu servidor ao ponto de verificar que ele rouba as chaves particulares dos certs, ele provavelmente não roubará todos eles, não apenas aquele.
Agora, digamos que você adicione outro subdomínio, que deve ter maior segurança do que os existentes, talvez um site de pagamentos. Você coloca esse subdomínio em seu próprio servidor e obtém o seu próprio certificado.
Se você usou certs separados ou um certificado de vários nomes no primeiro servidor, o certificado / chave do primeiro servidor não pôde ser usado para representar o segundo servidor.
Se você usasse um certificado curinga no primeiro servidor, o certificado / chave do primeiro servidor poderia ser usado para representar o segundo servidor.
P.S. certificado "seguro" é snakeoil.