RFC 3261 SIP: Session Initiation Protocol Junho 2002
Como medida adicional para evitar ataques de rebaixamento, entidades que aceitam somente requisições SIPS PODEM também recusar conexões em portas não seguras.
Usuários finais, sem dúvida, vão discernir a diferença entre URI's do SIPS e do SIP, e eles podem edita-los manualmente em resposta a estímulos. Isso pode tanto beneficiar quanto prejudicar a segurança. Por exemplo, se um atacante corromper um cache DNS, a inserção de um conjunto de registros falsos que efetivamente remove todos os registros SIPS para um servidor proxy, então todas as requisições SIPS que atravessam esse servidor proxy podem falhar. Quando um usuário, contudo, vê que chamadas repetidas para um AOR do SIPS estão falhando, eles poderiam em alguns dispositivos converter manualmente o esquema do SIPS para o SIP e tentar de novo. Claro, existem algumas salvaguardas contra isso (se o UA destino for verdadeiramente paranóico ele poderia recusar todas as requisições não-SIPS), mas essa é uma limitação digna de nota. O lado bom, usuários podem também advinhar que o 'SIPS' seria válido mesmo quando eles são apresentados apenas com um URI do SIP.
26.5 Privacidade
Mensagens SIP freqüentemente contêm informações sensíveis sobre seus remetentes – e não apenas o que eles têm a dizer, mas com quem eles se comunicam, quando eles se comunicam e por quanto tempo e de onde eles participam de sessões. Muitas aplicações e seus usuários exigem que esse tipo de informação privada seja escondida de todas as partes que não precisam conhecê-la.
Note que também existem formas menos diretas em que informações privadas podem ser divulgadas. Se um usuário ou serviço escolhe ser alcançável em um endereço que é adivinhação do nome e afiliação organizacional da pessoa (que descreve muitos endereços-de-registro), o método tradicional de assegurar a privacidade tendo um "número de telefone" não listado é comprometido. Um serviço de localização de usuário pode infringir a privacidade do destinatário de um convite de sessão ao divulgar seu paradeiro específico ao chamador; uma implementação DEVE consequentemente ser capaz de restringir, em uma base por usuário, que tipo de informações de localização e disponibilidade é dada a certas classes de chamadores. Essa é uma classe inteira de problema que é esperado seja mais estudada no trabalho SIP em curso.
Em alguns casos, usuários podem querer esconder informações pessoais em campos-cabeçalhos que transmitem identidade. Isso pode se aplicar não só a From e cabeçalhos relacionados que representam o originador da requisição, mas também ao To – esse não pode ser apropriado para transmitir ao destino final um apelido de discagem rápida, ou um identificador não expandido para um grupo de alvos, qualquer um dos dois seria removido do Request-URI quando a requisição é roteada, mas não alterada no campo-cabeçalho To
Rosenberg, et. al. Standards Track [Página 251]
Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:
User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.
Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:
MUST:
PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO,
NECESSITAR, É MANDATÓRIO.
MUST NOT:
NÃO PODE, É PROIBIDO, É VEDADO.
SHOULD:
DEVE, É RECOMENDADO.
SHOULD NOT:
NÃO DEVE, NÃO É RECOMENDADO.
MAY:
PODE, É OPCIONAL.
Nenhum comentário:
Postar um comentário