Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi. En estos casos, se debe utilizar un protocolo cifrado (seguro).

Ejemplo 1: En el siguiente ejemplo se envían datos mediante el protocolo HTTP (en lugar de usar HTTPS).

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

Es posible que el objeto de entrada HttpResponse, res, se haya visto comprometido, ya que se proporciona a través de un canal no cifrado ni autenticado.

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a ataques "man-in-the-middle" cuando los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: El siguiente código utiliza protocolo HTTP inseguro (en lugar de utilizar HTTPS):

    var account = new CloudStorageAccount(storageCredentials, false);

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).

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

Es posible que la respuesta de entrada, response, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están expuestas a riesgos, especialmente en entornos donde los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras.

Ejemplo 1: El siguiente ejemplo configura un servidor web mediante el protocolo HTTP (en lugar de 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))

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo, se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).

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

Es posible que el objeto de entrada http.IncomingMessage, res, se haya visto comprometido debido que se proporciona a través de un canal sin cifrar ni autenticar.

Todos los datos enviados a través de HTTP se envían en texto sin cifrar y expuestos a peligros.

Ejemplo 1: en el siguiente ejemplo se envían datos a través del protocolo HTTP (en lugar de HTTPS).

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

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están expuestas a riesgos, especialmente en entornos donde los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras.

Ejemplo 1: El siguiente ejemplo deshabilita el cifrado en un socket.

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

Toda la comunicación enviada con un protocolo de texto no seguro sin formato o sin cifrar puede estar en peligro.

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, está sujeto a compromiso.

Ejemplo 1: En el siguiente ejemplo, se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).

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

Es posible que la secuencia de entrada, in, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.

Las comunicaciones a través de HTTP, FTP o gopher no están autenticadas ni cifradas. Por lo tanto, están sujetas a riesgos, sobre todo en entornos móviles en los que los dispositivos se conectan con frecuencia a redes inalámbricas públicas poco seguras mediante conexiones WiFi.

Ejemplo 1: En el siguiente ejemplo se leen datos mediante el protocolo HTTP (en lugar de usar HTTPS).

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

Es posible que la respuesta de entrada, responseFuture, se haya visto comprometida, ya que se proporciona a través de un canal no cifrado ni autenticado.

Todos los datos enviados a través de HTTP se envían en texto sin cifrar y expuestos a peligros.

Ejemplo 1: en el siguiente ejemplo se envían datos a través del protocolo HTTP (en lugar de 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)

Los conjuntos de cifrado son grupos de algoritmos que se usan para establecer comunicaciones seguras. Mientras establece una conexión entre un servidor y un cliente, el servidor normalmente determina cuál de los conjuntos de cifrado compatibles mutuamente usar. El servidor y los clientes tienen diferentes grupos de conjuntos de cifrado compatibles. Los conjuntos de cifrado no están normalmente recomendados y pueden introducir vulnerabilidades de seguridad en la aplicación. Se recomienda usar normalmente conjuntos de cifrado fuertes, sin vulnerabilidades de seguridad conocidas.

El conjunto de cifrado preferido del servidor podría incluir un conjunto de cifrado con una debilidad conocida. Si el usuario elige un conjunto de cifrado vulnerable, podría permitirle elegir un conjunto de cifrado con una debilidad conocida para intentar introducir vulnerabilidades de seguridad.

Ejemplo 1: El siguiente código de Paramiko permite a un atacante establecer una lista de algoritmos deshabilitados, lo que brinda la posibilidad de degradar el cifrado.

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

Paramiko permite a un desarrollador realizar una selección de conjunto de cifrado inverso. Los algoritmos preferidos de Paramiko son AES128-CTR, AES192-CTR, AES256-CTR, AES128-CBC, AES192-CBC, AES256-CBC y, por último, 3DES-CBC. Si un atacante es capaz de controlar qué algoritmos están deshabilitados, puede forzar SSHClient.connect(...) a utilizar el algoritmo más débil 3DES-CBC.

La aplicación se comunica con su servidor de bases de datos a través de canales no cifrados, lo puede representar un riesgo de seguridad importante para la empresa y los usuarios de la aplicación. En este caso, un atacante puede modificar los datos insertados por el usuario o incluso ejecutar comandos SQL arbitrarios en el servidor de bases de datos.

Ejemplo 1: El siguiente código hace que la aplicación se comunique con su servidor de bases de datos a través de canales no cifrados:

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

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

El uso de configuraciones de seguridad del canal Google Remote Procedure Call (gRPC) que no especifican el cifrado o que no son compatibles con la autenticación o no tienen la capacidad de identidad de conexión deja al canal expuesto a muchas formas de ataque. No se puede confiar en los datos enviados con este canal inseguro.

Ejemplo 1: El siguiente código muestra una configuración de canal gRPC con credenciales de canal no seguras

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

El uso de una configuración de credenciales del canal de Google Remote Procedure Call (gRPC) no especificada da como resultado una configuración de seguridad que se establece en un valor predeterminado no seguro de None. No se puede confiar en los datos enviados con una configuración no segura de credenciales del canal.

Ejemplo 1: El siguiente código muestra un objeto de credenciales del canal gRPC creado con todos los parámetros predeterminados, lo que da como resultado que todas las configuraciones de seguridad de credenciales del canal se establezcan en valores predeterminados no seguros. En este caso, el valor del parámetro root_certificates se configurará en None, el valor del parámetro private_key se configurará en None y el valor del parámetro certificate_chain se configurará en None.

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

El uso de una configuración de credenciales del servidor de Google Remote Procedure Call (gRPC) no especificada da como resultado que la configuración de seguridad se establezca en un valor predeterminado no seguro de None o False. No se puede confiar en los datos enviados hacia un servidor y desde él con una configuración de credenciales no segura.

Ejemplo 1: El siguiente código muestra un objeto de credenciales del servidor gRPC creado con parámetros predeterminados, lo que hace que se deshabilite la autenticación del cliente.

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

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el usuario malintencionado observa todo el tráfico HTTP para los encabezados de ubicación y vínculos que hacen referencia a HTTPS y los reemplaza por versiones HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP agotadas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el usuario malintencionado se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otra información privada, pero el servidor sigue recibiendo el tráfico HTTPS esperado del usuario malintencionado para que nada parezca incorrecto.

La Seguridad de transporte HTTP estricta (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio devolviendo los encabezados HSTS a través de SSL/TLS durante un período especificado en el encabezado en sí. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente con una HTTPS, incluso si el usuario escribe http:// en la barra de dirección URL del explorador.

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el usuario malintencionado observa todo el tráfico HTTP para los encabezados de ubicación y vínculos que hacen referencia a HTTPS y los reemplaza por versiones HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP agotadas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el usuario malintencionado se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otra información privada, pero el servidor sigue recibiendo el tráfico HTTPS esperado del usuario malintencionado para que nada parezca incorrecto.

La Seguridad de transporte HTTP estricta (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio devolviendo los encabezados HSTS a través de SSL/TLS durante un período especificado en el encabezado en sí. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente con una HTTPS, incluso si el usuario escribe http:// en la barra de dirección URL del explorador.

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el usuario malintencionado observa todo el tráfico HTTP para los encabezados de ubicación y vínculos que hacen referencia a HTTPS y los reemplaza por versiones HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP agotadas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el usuario malintencionado se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otra información privada, pero el servidor sigue recibiendo el tráfico HTTPS esperado del usuario malintencionado para que nada parezca incorrecto.

La Seguridad de transporte HTTP estricta (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio devolviendo los encabezados HSTS a través de SSL/TLS durante un período especificado en el encabezado en sí. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente con una HTTPS, incluso si el usuario escribe http:// en la barra de dirección URL del explorador.

Un ataque de extracción de HTTPS es un tipo de ataque "man-in-the-middle" donde el usuario malintencionado observa todo el tráfico HTTP para los encabezados de ubicación y vínculos que hacen referencia a HTTPS y los reemplaza por versiones HTTP. El atacante conserva una lista de todas las sustituciones de HTTP realizadas para poder devolver la solicitud HTTPS al servidor. Todas las conexiones HTTP agotadas se conectan a través de un proxy con el servidor mediante HTTPS. Todo el tráfico entre la víctima y el usuario malintencionado se envía a través de HTTP, por lo que se revelan nombres de usuario, contraseñas y otra información privada, pero el servidor sigue recibiendo el tráfico HTTPS esperado del usuario malintencionado para que nada parezca incorrecto.

La Seguridad de transporte HTTP estricta (HSTS) es un encabezado de seguridad que indica al explorador que siempre se conecte al sitio devolviendo los encabezados HSTS a través de SSL/TLS durante un período especificado en el encabezado en sí. Cualquier conexión con el servidor mediante HTTP se reemplazará automáticamente con una HTTPS, incluso si el usuario escribe http:// en la barra de dirección URL del explorador.

Los datos confidenciales enviados sin cifrar a través de la conexión pueden ser leídos/modificados por cualquier usuario malintencionado que intercepte el tráfico de red.

Ejemplo 1: el siguiente SmtpClient está configurado incorrectamente, no utiliza SSL/TLS para comunicarse con un servidor SMTP:

  string to = "bob@acme.com";
  string from = "alice@acme.com";
  MailMessage message = new MailMessage(from, to);
  message.Subject = "SMTP client.";
  message.Body = @"You can send an email message from an application very easily.";
  SmtpClient client = new SmtpClient("smtp.acme.com");
  client.UseDefaultCredentials = true;
  client.Send(message);

Los datos confidenciales enviados sin cifrar a través de la conexión pueden ser leídos/modificados por cualquier usuario malintencionado que intercepte el tráfico de red.

Ejemplo 1: el siguiente cliente SMTP está configurado incorrectamente, no utiliza SSL/TLS para comunicarse con un servidor SMTP:

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

Una aplicación que se basa en los protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede verse comprometida si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones, implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

Una aplicación que se basa en protocolos SSL/TLS para garantizar la autenticidad, la confidencialidad y la integridad de las transmisiones de datos puede resultar vulnerable a compromisos si no elige algoritmos criptográficos lo suficientemente sólidos. La solidez del mecanismo de protección viene determinada por los algoritmos de autenticación, cifrado y hash, conocidos colectivamente como conjunto de cifrado. Se utiliza un conjunto de cifrado para la transmisión de información confidencial a través del canal TLS/SSL.

Cuando un servidor admite una variedad de conjuntos de cifrado de diferentes niveles, el uso de un cifrado débil o una clave de cifrado de longitud insuficiente puede permitir que un atacante anule el mecanismo de protección y robe o modifique información confidencial. Los atacantes podrían manipular las aplicaciones implementadas en un servidor web configurado de manera insegura, para que elijan conjuntos de cifrado débiles. Es posible que los conjuntos de cifrado débiles resulten vulnerables a los ataques de fuerza bruta y los ataques "man-in-the-middle", lo que puede derivar en la interceptación y manipulación de datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

Ejemplo 1: este fragmento de Node.js intenta crear un servidor con una conexión segura:

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

Como Node.js establece el valor predeterminado de secureProtocol en SSLv23_method, el servidor es inherentemente inseguro cuando secureProtocol no se reemplaza específicamente.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión aborda las deficiencias de seguridad halladas en la versión previa. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

Ejemplo 1: en el siguiente ejemplo se usa la versión predeterminada de SSL, que es SSL v3.0:

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

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión se diseña para abordar las deficiencias de seguridad halladas en versiones previas. El uso de versiones de los protocolos TLS/SSL inseguras debilita la fortaleza de la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP
- Uso de conjuntos de cifrado débiles

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

Ejemplo 1: El siguiente ejemplo configura la sesión para usar SSL v3.0:

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