Transporte WCF vs Mensagem

Eu estava lendo sobre implementações de segurança do WCF e descobri que existem dois tipos de segurança: Transport Mode and Message Mode (or both)

Se eu usei HTTPS para o modo de transporte, é mais seguro se eu usei a segurança da mensagem também? Eu estou perguntando isso porque o que eu entendo é o seguinte:

https usa o protocolo SSL que criptografa as mensagens … então por que devo adicionar o Message Security e criptografar a mensagem criptografada SSL? ou eu estou entendendo mal as coisas?

Segurança no WCF na verdade consiste em vários resources . A diferença entre esses dois é como as mensagens são assinadas e criptografadas.

A segurança de transporte fornece apenas segurança de canal ponto-a-ponto. Isso significa que o HTTPS estabelece um canal seguro apenas entre o cliente e o servidor exposto ao cliente. Mas se esse servidor for apenas um balanceador de carga ou um servidor proxy reverso, ele terá access direto ao conteúdo da mensagem.

A segurança de mensagens fornece segurança de canal de ponta a ponta. Isso significa que a segurança faz parte dos dados transferidos e que apenas o destino pretendido pode descriptografar os dados (o balanceador de carga ou o proxy vê apenas mensagens criptografadas). A segurança de mensagens na maioria dos casos também usa certificados para fornecer criptografia e assinatura, mas geralmente é mais lenta porque a segurança de transporte pode usar a aceleração de HW.

Em cenários avançados, esses methods podem ser combinados. Por exemplo, você pode ter comunicação com seu balanceador de carga protegido por HTTPS porque confia em sua rede interna após o balanceador de carga, mas, ao mesmo tempo, pode ter a mensagem assinada (segurança da mensagem) para provar que não foi alterado.

Outra diferença entre esses dois é que a segurança do transporte está relacionada ao protocolo de transporte único, enquanto a segurança da mensagem é independente no protocolo de transporte.

A segurança da mensagem é baseada em protocolos interoperáveis ​​(mas esteja ciente de que nem toda configuração no WCF é interoperável). O WCF suporta pelo menos parcialmente esses protocolos:

  • WS-Security 1.0 e 1.1 – regras básicas para criptografia, assinatura, transporte de token, timestamps etc.
  • UserName token profile 1.0 – definição de token usado para transportar nome de usuário e senha. Essa especificação é implementada apenas parcialmente porque o WCF pronto para uso não suporta senha digerida e requer o uso desse token com criptografia de transporte ou de mensagem.
  • Perfil de token X509 1.1 – definição de token usado para transportar certificados.
  • Perfil de token Kerberos 1.1 – definição de token usado para transportar tickets do Kerberos.
  • Perfil de token SAML 1.1 1.0 e 1.1 – definição de token usado para segurança federada. O SAML 2.0 é fornecido pelo WIF.
  • WS-SecurityPolicy 1.1 e 1.2 – fornece suporte para definir a asserção de segurança no WSDL.
  • WS-SecureConversation 1.3 e fevereiro de 2005 – fornece suporte para a session de segurança em que as credenciais são trocadas apenas durante a primeira chamada e o restante da comunicação usa token de segurança exclusivo.
  • WS-Trust 1.3 e fevereiro de 2005 – fornece suporte para cenários federados e serviços de token de segurança (STS).

O WCF também suporta o WS-I Basic Security Profile 1.0, que é apenas um subconjunto de protocolos antigos com configuração prescrita.

Para resources não interoperáveis, o WCF oferece resources como segurança do Windows ou TLSNego e SPNego (ambos devem ser geralmente interoperáveis, mas não estão disponíveis em muitas pilhas SOAP) para troca de credenciais de serviço.

Este link descreve as razões para usar ou não a segurança da Mensagem.

Basicamente, a segurança de transporte é preferida, a menos que não possa ser usada.

Um trecho do link:

Prós e Contras da Segurança em Nível de Transporte

A segurança de transporte tem as seguintes vantagens:

Não requer que as partes em comunicação entendam os conceitos de segurança no nível XML. Isso pode melhorar a interoperabilidade, por exemplo, quando o HTTPS é usado para proteger a comunicação.

Geralmente melhor desempenho.

Aceleradores de hardware estão disponíveis.

Streaming é possível.

Segurança de transporte tem as seguintes desvantagens:

Apenas hop-to-hop

Conjunto de credenciais limitado e inextensível.

Dependente de transporte.

Desvantagens da segurança no nível da mensagem

A segurança da mensagem tem as seguintes desvantagens:

atuação

Não é possível usar o stream de mensagens.

Requer a implementação de mecanismos de segurança no nível XML e suporte para a especificação WS-Security. Isso pode afetar a interoperabilidade.

Há também casos em que você pode não ter criptografia no nível de transporte e, portanto, “voltar atrás” à criptografia no nível da mensagem, que é um pouco menos segura do que a segurança do nível de transporte.

Fazendo ambos será mais seguro, com certeza. Mas é um pouco exagerado quando você tem uma boa segurança no nível de transporte.

Eu diria que na maioria dos casos deve ser suficiente com um ou outro. Se você pode usar a segurança no nível de transporte que é preferível, pois criptografa toda a comunicação, não apenas o conteúdo da mensagem.