Todas as comunicações pela conexão de soquete TCP atualmente não são autenticadas e nem criptografadas, o que as expõe a possíveis comprometimentos. Esse risco é particularmente significativo em ambientes móveis, onde os dispositivos geralmente se conectam a redes sem fio públicas não seguras. Para mitigar essa vulnerabilidade, implemente um protocolo seguro, como SSL/TLS, para garantir a confidencialidade e a integridade dos dados.

Exemplo 1: O trecho de código a seguir demonstra a transmissão de dados por meio de uma conexão de soquete TCP não autenticada e não criptografada, em vez de usar um protocolo seguro como SSL/TLS.

...
FINAL(client) = cl_apc_tcp_client_manager=>create(
      i_host   = ip_adress
      i_port  = port
      i_frame = VALUE apc_tcp_frame(
        frame_type =
          if_apc_tcp_frame_types=>co_frame_type_terminator
        terminator =
          terminator )
      i_event_handler = event_handler ).
...

A comunicação entre o objeto client e o servidor remoto fica vulnerável a comprometimento, porque é transmitido por um canal não criptografado e não autenticado.

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Está, portanto, sujeita a ficar comprometida, especialmente no ambiente móvel, no qual os dispositivos frequentemente se conectam a redes não seguras, públicas e sem fio por meio conexões Wi-Fi. Nesses casos, um protocolo criptografado (seguro) deve ser usado.

Exemplo 1: Esse exemplo envia os dados pelo protocolo HTTP (em vez de usar o HTTPS).

...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...

O objeto HttpResponse de entrada, res, pode ter sido comprometida, pois ela é entregue através de um canal não criptografado e não autenticado.

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Portanto, ela está a ataques man-in-the-middle, na qual os dispositivos frequentemente se conectam a redes não seguras, públicas e sem fio usando conexões Wi-Fi.

Exemplo 1: O código a seguir usa protocol HTTP inseguro (em vez de utilizar o HTTPS):

    var account = new CloudStorageAccount(storageCredentials, false);

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Está, portanto, sujeita a ficar comprometida, especialmente no ambiente móvel, no qual os dispositivos frequentemente se conectam a redes não seguras, públicas e sem fio por meio conexões Wi-Fi.

Exemplo 1: Este exemplo lê os dados usando o protocolo HTTP (em vez de utilizar o HTTPS).

  ...
  String url = 'http://10.0.2.2:11005/v1/key';
  Response response = await get(url, headers: headers);
  ...

A resposta de entrada, response, pode ter sido comprometida, pois ela é entregue por meio de um canal não criptografado e não autenticado.

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Portanto, está sujeita a ser comprometida, especialmente em ambientes nos quais os dispositivos se conectam frequentemente a redes sem fio públicas não seguras.

Exemplo 1: O exemplo a seguir configura um servidor Web usando o protocolo HTTP (em vez de usar HTTPS).

	helloHandler := func(w http.ResponseWriter, req *http.Request) {
		io.WriteString(w, "Hello, world!\n")
	}

	http.HandleFunc("/hello", helloHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Está, portanto, sujeita a ficar comprometida, especialmente no ambiente móvel, no qual os dispositivos frequentemente se conectam a redes não seguras, públicas e sem fio por meio conexões Wi-Fi.

Exemplo 1: Este exemplo lê os dados usando o protocolo HTTP (em vez de utilizar o HTTPS).

var http = require('http');
...
http.request(options, function(res){
  ...
});
...

O objeto de entrada http.IncomingMessage, res, pode ter sido comprometido, uma vez que é entregue por meio de um canal não criptografado e não autenticado.

Todos os dados enviados por meio de HTTP são enviados abertamente e estão sujeitos a um compromisso.

Exemplo 1: Este exemplo envia dados por meio do protocolo HTTP (contra HTTPS).

NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Portanto, está sujeita a ser comprometida, especialmente em ambientes nos quais os dispositivos se conectam frequentemente a redes sem fio públicas não seguras.

Exemplo 1: O exemplo a seguir desabilita a criptografia em um soquete.

...
stream_socket_enable_crypto($fp, false);
...

Todas as comunicações enviadas com um protocolo inseguro, não criptografado ou de texto simples estão sujeitas a comprometimento.

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Portanto, está sujeita a ficar comprometida.

Exemplo 1: Este exemplo lê os dados usando o protocolo HTTP (em vez de utilizar o HTTPS).

require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...

O fluxo de entrada, in, pode ter sido comprometido, pois ele é entregue através de um canal não criptografado e não autenticado.

Toda a comunicação por HTTP, FTP ou gopher não é autenticada e não é criptografada. Está, portanto, sujeita a ficar comprometida, especialmente no ambiente móvel, no qual os dispositivos frequentemente se conectam a redes não seguras, públicas e sem fio por meio conexões Wi-Fi.

Exemplo 1: Este exemplo lê os dados usando o protocolo HTTP (em vez de utilizar o HTTPS).

   val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
   val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))

A resposta de entrada, responseFuture, pode ter sido comprometida, pois ela é entregue através de um canal não criptografado e não autenticado.

Todos os dados enviados por meio de HTTP são enviados abertamente e estão sujeitos a um compromisso.

Exemplo 1: Este exemplo envia dados por meio do protocolo HTTP (contra HTTPS).

let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)

O uso de configurações de segurança do canal do Google Remote Procedure Call (gRPC) que não especificam a criptografia, não permitem autenticação ou não têm capacidade de identidade de conexão deixa o canal aberto a muitas formas de ataque. Os dados enviados com esse canal inseguro não são confiáveis.

Exemplo 1: O código a seguir mostra uma configuração de canal do gRPC com credenciais de canal inseguras.

    ...
    using var channel = GrpcChannel.ForAddress("https://grpcserver.com", new GrpcChannelOptions { 
        Credentials = ChannelCredentials.Insecure
    });
    ...
    

O uso de configurações de credencial de canal do Google Remote Procedure Call (gRPC) não especificadas resulta em configurações de segurança definidas para um valor padrão não seguro de None. Os dados enviados com configurações de credencial de canal não seguras não são confiáveis.

Exemplo 1: O código a seguir mostra um objeto de credenciais de canal do gRPC criado com todos os parâmetros padrão, o que resulta em todas as configurações de segurança de credenciais de canal definidas como valores padrão inseguros. Nesse caso, o valor do parâmetro root_certificates será definido como None, o valor do parâmetro private_key será definido como None e o valor do parâmetro certificate_chain será definido como None.

...
channel_creds = grpc.ssl_channel_credentials()
...

O uso de configurações de credencial de servidor do Google Remote Procedure Call (gRPC) não especificadas resulta em configurações de segurança definidas para um padrão inseguro de None ou False. Os dados enviados de e para um servidor com configurações de credenciais de servidor inseguras não são confiáveis.

Exemplo 1: O código a seguir mostra um objeto de credenciais de servidor do gRPC criado com parâmetros padrão, resultando na desativação da autenticação do cliente.

...
pk_cert_chain = your_organization.securelyGetPrivateKeyCertificateChainPairs()
server_creds = grpc.ssl_server_credentials(pk_cert_chain)
...

Um ataque de remoção de HTTPS é um tipo de ataque intermediário, no qual invasor observa todo o tráfego HTTP em cabeçalhos e links de localização que fazem referência HTTPS e os substitui por HTTP. O invasor mantém uma lista de todas as substituições HTTP feitas para que ele possa fazer a solicitação HTTPS ao servidor. Realiza-se o proxy de todas as conexões HTTP ao servidor por meio de HTTPS. Todo o tráfego entre a vítima e o agressor é enviado por meio de HTTP, revelando nomes de usuários, senhas e outras informações privadas, mas o servidor ainda recebe o tráfego HTTPS esperado do invasor para que nada pareça errado.

O HTTP Strict Transport Security (HSTS) é um cabeçalho de segurança que instrui o navegador a sempre conectar a um site que retorne os cabeçalhos HSTS via SSL/TLS durante um período especificado no cabeçalho. Qualquer conexão ao servidor via HTTP será automaticamente substituída por uma conexão HTTPS, mesmo se o usuário digitar http:// na barra de URL do navegador.

Um ataque de remoção de HTTPS é um tipo de ataque intermediário, no qual invasor observa todo o tráfego HTTP em cabeçalhos e links de localização que fazem referência HTTPS e os substitui pelas versões HTTP. O invasor mantém uma lista de todas as substituições HTTP feitas para que ele possa fazer a solicitação HTTPS ao servidor. Realiza-se o proxy de todas as conexões HTTP ao servidor por meio de HTTPS. Todo o tráfego entre a vítima e o agressor é enviado por meio de HTTP, revelando nomes de usuários, senhas e outras informações privadas, mas o servidor ainda recebe o tráfego HTTPS esperado do invasor para que nada pareça errado.

O HTTP Strict Transport Security (HSTS) é um cabeçalho de segurança que instrui o navegador a sempre conectar a um site que retorne os cabeçalhos HSTS via SSL/TLS durante um período especificado no cabeçalho. Qualquer conexão ao servidor via HTTP será automaticamente substituída por uma conexão HTTPS, mesmo se o usuário digitar http:// na barra de URL do navegador.

Um ataque de remoção de HTTPS é um tipo de ataque intermediário, no qual invasor observa todo o tráfego HTTP em cabeçalhos e links de localização que fazem referência HTTPS e os substitui pelas versões HTTP. O invasor mantém uma lista de todas as substituições HTTP feitas para que ele possa fazer a solicitação HTTPS ao servidor. Realiza-se o proxy de todas as conexões HTTP ao servidor por meio de HTTPS. Todo o tráfego entre a vítima e o agressor é enviado por meio de HTTP, revelando nomes de usuários, senhas e outras informações privadas, mas o servidor ainda recebe o tráfego HTTPS esperado do invasor para que nada pareça errado.

O HTTP Strict Transport Security (HSTS) é um cabeçalho de segurança que instrui o navegador a sempre conectar a um site que retorne os cabeçalhos HSTS via SSL/TLS durante um período especificado no cabeçalho. Qualquer conexão ao servidor via HTTP será automaticamente substituída por uma conexão HTTPS, mesmo se o usuário digitar http:// na barra de URL do navegador.

Um ataque de remoção de HTTPS é um tipo de ataque intermediário, no qual invasor observa todo o tráfego HTTP em cabeçalhos e links de localização que fazem referência HTTPS e os substitui pelas versões HTTP. O invasor mantém uma lista de todas as substituições HTTP feitas para que ele possa fazer a solicitação HTTPS ao servidor. Realiza-se o proxy de todas as conexões HTTP ao servidor por meio de HTTPS. Todo o tráfego entre a vítima e o agressor é enviado por meio de HTTP, revelando nomes de usuários, senhas e outras informações privadas, mas o servidor ainda recebe o tráfego HTTPS esperado do invasor para que nada pareça errado.

O HTTP Strict Transport Security (HSTS) é um cabeçalho de segurança que instrui o navegador a sempre conectar a um site que retorne os cabeçalhos HSTS via SSL/TLS durante um período especificado no cabeçalho. Qualquer conexão ao servidor via HTTP será automaticamente substituída por uma conexão HTTPS, mesmo se o usuário digitar http:// na barra de URL do navegador.

Dados confidenciais enviados na rede em formato não criptografado estão sujeitos a serem lidos/modificados por qualquer invasor que possa interceptar o tráfego de rede.

Exemplo 1: O seguinte SmtpClient está configurado incorretamente, sem usar SSL/TLS para se comunicar com um servidor SMTP:

  string to = "bob@acme.com";
  string from = "alice@acme.com";
  MailMessage message = new MailMessage(from, to);
  message.Subject = "SMTP client.";
message.Body = @"Envie com facilidade uma mensagem de e-mail por um aplicativo.";
  SmtpClient client = new SmtpClient("smtp.acme.com");
  client.UseDefaultCredentials = true;
  client.Send(message);

Dados confidenciais enviados na rede em formato não criptografado estão sujeitos a serem lidos/modificados por qualquer invasor que possa interceptar o tráfego de rede.

Exemplo 1: O seguinte cliente SMTP está configurado incorretamente, sem usar SSL/TLS para se comunicar com um servidor SMTP:

session = smtplib.SMTP(smtp_server, smtp_port)
session.ehlo()
session.login(username, password)
session.sendmail(frm, to, content)

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca podem ser vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Um aplicativo que depende de SSL/TLS para garantir autenticidade, confidencialidade e integridade das transmissões de dados poderá ser vulnerável a comprometimento se não escolher algoritmos criptográficos suficientemente fortes. A força do mecanismo de proteção é determinada pelos algoritmos de autenticação, criptografia e hash, conhecidos coletivamente como conjunto de criptografia. Um conjunto de criptografia é usado para a transmissão de informações confidenciais pelo canal de TLS/SSL.

Quando um servidor oferece suporte a uma variedade de conjuntos de criptografia de intensidades variadas, o uso de uma criptografia fraca ou uma chave de criptografia de tamanho insuficiente pode permitir que um invasor se esquive do mecanismo de proteção e roube ou modifique informações confidenciais. Os invasores podem manipular aplicativos, que são implantados em um servidor Web configurado de forma não segura, para escolher conjuntos de criptografia fraca. Os conjuntos de criptografia fraca estão vulneráveis a ataques de força bruta e man-in-the-middle, que podem resultar em interceptação e manipulação de dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques man-in-the-middle
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques MITM (man-in-the-middle)
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques man-in-the-middle
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques man-in-the-middle
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Exemplo 1: Este trecho de Node.js tenta criar um servidor com uma conexão segura:

...
var options = {
  port: 443,
  path: '/',
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  ...
}
https.createServer(options);
...

Uma vez que o Node.js definir o valor padrão de secureProtocol como SSLv23_method, o servidor será inerentemente inseguro quando secureProtocol não for especificamente substituído.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, o que resulta em atualizações de versão periódicas. Cada nova revisão resolve as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões inseguras do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques man-in-the-middle
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP

A presença dessas propriedades pode possibilitar que um invasor intercepte, modifique ou adultere dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques MITM (man-in-the-middle)
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Exemplo 1: O seguinte exemplo usa a versão SSL padrão que é SSL v3.0:

NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration ephemeralSessionConfiguration];
[configuration setTLSMinimumSupportedProtocol = kSSLProtocol3];
NSURLSession *mySession = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:operationQueue];

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques man-in-the-middle
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques MITM (man-in-the-middle)
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques MITM (man-in-the-middle)
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, resultando em atualizações de versão periódicas. Cada nova revisão é projetada para corrigir as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões fracas do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques MITM (man-in-the-middle)
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP
- Uso de conjuntos de criptografia fraca

A presença dessas propriedades pode permitir que um invasor intercepte, modifique ou adultere dados confidenciais.

Exemplo 1: O exemplo a seguir configura a sessão para usar SSL v3.0:

let configuration : NSURLSessionConfiguration = NSURLSessionConfiguration.defaultSessionConfiguration()
let mySession = NSURLSession(configuration: configuration, delegate: self, delegateQueue: operationQueue)