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)

Conjuntos de criptografia são uma série de algoritmos usados para estabelecer comunicações seguras. Ao estabelecer uma conexão entre um servidor e um cliente, o servidor geralmente determina qual dos conjuntos de criptografia com suporte mútuo deve ser utilizado. O servidor e os clientes podem oferecer suporte a diferentes conjuntos de criptografia. Em geral, não se recomenda o uso de conjuntos de criptografia mais antigos, que podem introduzir vulnerabilidades de segurança no aplicativo. Recomenda-se o uso de conjuntos de criptografia fortes, sem vulnerabilidades de segurança conhecidas.

O conjunto de criptografia preferido do servidor pode incluir um conjunto de criptografia com um ponto fraco conhecido. Se o usuário escolher um conjunto de criptografia vulnerável, isso poderá permitir que ele escolha um conjunto de criptografia com um ponto fraco conhecido para tentar introduzir vulnerabilidades de segurança.

Exemplo 1: O código Paramiko a seguir permite que um invasor defina uma lista de algoritmos desabilitados, proporcionando a capacidade de fazer downgrade da criptografia.

    client = SSHClient()
    algorithms_to_disable = { "ciphers": untrusted_user_input }
    client.connect(host, port, "user", "password", disabled_algorithms=algorithms_to_disable)

O Paramiko permite que um desenvolvedor faça uma seleção inversa do conjunto de criptografia. Os algoritmos preferidos do Paramiko são AES128-CTR, AES192-CTR, AES256-CTR, AES128-CBC, AES192-CBC, AES256-CBC e, por último, 3DES-CBC. Se um invasor for capaz de controlar quais algoritmos estão desativados, ele poderá forçar SSHClient.connect(...) a usar o algoritmo mais fraco 3DES-CBC.

O aplicativo se comunica com seu servidor de banco de dados por meio de canais não criptografados, o que pode representar um risco de segurança significativo para a empresa e os usuários do aplicativo. Nesse caso, um invasor pode modificar os dados inseridos pelo usuário ou até mesmo executar comandos SQL arbitrários no servidor de banco de dados.

Exemplo 1: O código a seguir faz com que o aplicativo se comunique com seu servidor de banco de dados por meio de canais não criptografados:

  ...
  insecure_config = {
        'user': username,
        'password': retrievedPassword,
        'host': databaseHost,
        'port': "3306",
        'ssl_disabled': True
    }

    mysql.connector.connect(**insecure_config)
  ...

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)