12.185 cursos gratis
8.411.274 alumnos
Facebook Twitter YouTube
Busca cursos gratis:

Capítulo 5:

 Sistemas de seguridad en Internet para protección de información

SSL - Secure Sockets Layer

SSL (Secure Sockets Layer) fue diseñado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versión del Navigator. Sin embargo, no fue hasta su tercera versión, conocida como SSL v3.0 que alcanzó su madurez, superando los problemas de seguridad y limitaciones de sus predecesores. En su estado actual, proporciona cifrado de datos, autenticación de servidores, integridad de mensajes y, opcionalmente, autenticación de cliente para conexiones TCP/IP.

SSL v3.0 goza de gran popularidad, por lo que se encuentra ampliamente extendido en Internet. Viene soportado por los dos principales navegadores del mercado, Netscape Navigator 3.0 ó superior, así como por Internet Explorer 3.0 ó superior.

No se necesita realizar ninguna acción especial para invocar el protocolo SSL, basta con seguir un enlace o abrir una página cuya dirección empieza por https://. El navegador se encarga del resto. Eso sí, asegúrese de que tiene SSL habilitado en su navegador. 

Cómo funciona SSL

El rasgo que distingue a SSL de otros protocolos para comunicaciones seguras, como el hoy prácticamente extinto S-HTTP, es que se ubica en la plataforma OSI entre los niveles de transporte (TCP/IP) y de aplicación (donde se encuentran los conocidos protocolos HTTP para Web, FTP para transferencia de ficheros, SMTP para correo electrónico, Telnet para conexión a máquinas remotas, etc.). Gracias a esta característica, SSL resulta muy flexible, ya que puede servir para securizar potencialmente otros servicios además de HTTP para Web, sin más que hacer pequeñas modificaciones en el programa que utilice el protocolo de transporte de datos TCP.

SSL proporciona sus servicios de seguridad cifrando los datos intercambiados entre el servidor y el cliente con un algoritmo de cifrado simétrico, que puede elegirse entre DES, triple-DES, RC2, RC4 o IDEA, y cifrando la clave de sesión de los algoritmos anteriores mediante un algoritmo de cifrado de clave pública, típicamente el RSA. La clave de sesión es la que se utiliza para cifrar los datos que vienen del y van al servidor seguro. Se genera una clave de sesión distinta para cada transacción, lo cual permite que aunque sea reventada por un atacante en una transacción dada, no sirva para descifrar futuras transacciones. MD5 o SHA se pueden usar como algoritmos de resumen digital (hash). Esta posibilidad de elegir entre tan amplia variedad de algoritmos dota a SSL de una gran flexibilidad criptográfica.

Durante el protocolo SSL, el cliente y el servidor intercambian una serie de mensajes para negociar las mejoras de seguridad. Este protocolo sigue las siguientes fases (de manera muy resumida):

1.      La fase Hola, usada para ponerse de acuerdo sobre el conjunto de algoritmos para mantener la intimidad y para la autenticación. El navegador le informa al servidor de los algoritmos que posee disponibles. Normalmente se utilizarán los más fuertes que se puedan acordar entre las dos partes. En función de las posibilidades criptográficas del navegador, el servidor elegirá un conjunto u otro de algoritmos con una cierta longitud de claves.

2.      La fase de autenticación, en la que el servidor envía al navegador su certificado x.509v3 que contiene su clave pública y solicita a su vez al cliente su certificado X.509v3 (sólo si la aplicación exige la autenticación de cliente).

3.      La fase de creación de clave de sesión, en la que el cliente envía al servidor una clave maestra a partir de la cual se generará la clave de sesión para cifrar los datos intercambiados posteriormente haciendo uso del algoritmo de cifrado simétrico acordado en la fase 1. El navegador envía cifrada esta clave maestra usando la clave pública del servidor que extrajo de su certificado en la fase 2. Posteriormente, ambos generarán idénticas claves de sesión a partir de la clave maestra generada por el navegador.

4.      Por último, la fase Fin, en la que se verifica mutuamente la autenticidad de las partes implicadas y que el canal seguro ha sido correctamente establecido. Una vez finalizada esta fase, ya se puede comenzar la sesión segura.

De ahí en adelante, durante la sesión segura abierta, SSL proporciona un canal de comunicaciones seguro entre los servidores Web y los clientes (los navegadores) a través del cual se intercambiará cifrada la información relevante, como el URL y los contenidos del documento solicitado, los contenidos de cualquier formulario enviado desde el navegador, las cookies enviadas desde el navegador al servidor y viceversa y los contenidos de las cabeceras HTTP.

 Uso de SSL en comercio electrónico

SSL constituye la solución de seguridad implantada en la mayoría de los servidores web que ofrecen servicios de comercio electrónico. Su mayor mérito radica en ofrecer respuesta al principal problema que afronta el comercio en línea: la renuencia de los usuarios a enviar su número de tarjeta de crédito a través de un formulario web por el temor de que caiga en manos de un intruso y por la desconfianza generalizada hacia Internet, a lo que se suma en Perú la falta de costumbre de compra por catálogo.

La forma más fácil y más extendida para construir un sistema de comercio en Internet consiste en utilizar un servidor web con un catálogo con información sobre los productos o servicios ofrecidos y un formulario para procesar los pedidos. El catálogo estará compuesto por una serie de páginas web describiendo la mercancía en venta, acompañadas de imágenes, dibujos, especificaciones, animaciones, clips de vídeo o audio, applets de Java, controles ActiveX, etc. Estas páginas web se pueden crear estáticamente con un programa de edición HTML como Microsoft FrontPage o Adobe PageMill, o también pueden crearse dinámicamente desde una base de datos de los artículos y su información asociada, con programas como FileMaker Pro de Claris. Junto a cada artículo se sitúa un botón que el usuario puede pulsar para comprarlo o, más comúnmente, para añadirlo al carrito de la compra para pagarlo todo al final. Cuando el cliente ha terminado sus compras, pasa por una "caja virtual", que iniciará el proceso de pago.

Hoy por hoy, el medio de pago más común en Internet es la tarjeta de crédito. No obstante, no hay que despreciar otros métodos más conservadores, aunque a menudo preferidos por los compradores españoles, como el envío contra reembolso o la transferencia bancaria, que representan un porcentaje importante de las ventas en línea. El usuario debe rellenar un formulario con sus datos personales (tanto para el caso del envío de los bienes comprados, como para comprobar la veracidad de la información de pago), y los datos correspondientes a su tarjeta de crédito (número, fecha de caducidad, titular). Esta arquitectura no exige que el servidor disponga de capacidades especiales para el comercio. Basta con que se utilice como mínimo un canal seguro para transmitir la información de pago y el comerciante ya se ocupará manualmente de gestionar con su banco las compras.

Sin embargo, este enfoque, aunque práctico y fácil de implantar, no ofrece una solución comercialmente integrada ni totalmente segura. A medida que el comercio crece, esta arquitectura podría llegar a resultar difícil de expandir o de incorporar nuevas tecnologías y componentes a medida que vayan apareciendo. Existen una serie de desventajas al utilizar exclusivamente SSL para llevar adelante ventas por Internet:

·        Por un lado, SSL ofrece un canal seguro para el envío de números de tarjeta de crédito, pero carece de capacidad para completar el resto del proceso comercial: verificar la validez del número de tarjeta recibido, autorizar la transacción con el banco del cliente, y procesar el resto de la operación con el banco adquiriente y emisor.

·        Por otro lado, es importante recalcar que SSL sólo garantiza la confidencialidad e integridad de los datos en tránsito, ni antes ni después. Por lo tanto, si se envían datos personales al servidor, entre ellos el ya citado número de tarjeta de crédito, el número de la seguridad social, el DNI, etc., SSL solamente asegura que mientras viajan desde el navegador hasta el servidor no serán modificados ni espiados. Lo que el servidor haga con ellos, está ya más allá de la competencia de este protocolo. Los datos podrían ser manipulados irresponsablemente o caer en manos de un atacante que asaltara el servidor con éxito.

·        Además, SSL es vulnerable porque podría permitir ataques de hackers sobre servidores de comercio con bajo diseño de seguridad, para averiguar números de tarjeta de crédito.

Todos estos inconvenientes convierten a SSL en una solución deficiente desde el punto de vista del pago electrónico, lo cual no significa que no se deba utilizar ni que no sea útil en otras muchas facetas igualmente necesarias de la actividad empresarial. Al proporcionar un canal seguro de comunicaciones, el comerciante puede ofrecer al cliente de manera confidencial una serie de servicios para estrechar las relaciones de confianza: autenticación del cliente frente al comercio, trato personalizado, evitar que terceras partes espíen las compras de los clientes, intercambio de información privada, etc.

Dado que SSL es un protocolo seguro de propósito general, que no fue diseñado para el comercio en particular, se hace necesaria la existencia de un protocolo específico para el pago. Este protocolo existe y se conoce como SET.

Transacciones Electrónicas Seguras (Secure Electronic Transaction o SET) es un protocolo estandarizado y respaldado por la industria, diseñado para salvaguardar las compras pagadas con tarjeta a través de redes abiertas, incluyendo Internet. El estándar SET fue desarrollado en 1995 por Visa y MasterCard, con la colaboración de otras compañías líderes en el mercado de las tecnologías de la información, como Microsoft, IBM, Netscape, RSA, VeriSign y otras.

El 19 de diciembre de 1997 Visa y MasterCard formaron SET Secure Electronic Transaction LLC (comúnmente conocida como "SETCo") para que implantase la especificación. En cuanto el protocolo SET 1.0 fue finalizado, comenzó a emerger una infraestructura basado en el mismo para dar soportar su uso a gran escala. Ya existen numerosos fabricantes de software que han empezado a crear productos para consumidores y comerciantes que deseen realizar sus compras de manera segura disfrutando de las ventajas ofrecidas por SET.

Qué servicios ofrece SET

·        Autenticación: todas las partes implicadas en la transacción económica (el cliente, el comerciante y los bancos, emisor y adquiriente) pueden autenticarse mutuamente mediante certificados digitales. De esta forma, el comerciante puede asegurarse de la identidad del titular de la tarjeta y el cliente, de la identidad del comerciante. Se evitan así fraudes debidos a usos ilícitos de tarjetas y a falsificaciones de comercios en Internet imitando grandes web comerciales. Por su parte, los bancos pueden verificar así las identidades del titular y del comerciante.

·        Confidencialidad: la información de pago se cifra para que no pueda ser espiada. Es decir, solamente el número de tarjeta de crédito es cifrado por SET, de manera que ni siquiera el comerciante llegará a verlo, para prevenir fraudes. Si se quiere cifrar el resto de datos de la compra, como por ejemplo qué artículos se han comprado, debe recurrirse a un protocolo de nivel inferior como SSL.

·        Integridad: garantiza que la información intercambiada, como número de tarjeta, no podrá ser alterada de manera accidental o maliciosa mientras viaja a través de la red. Para lograrlo se utilizan algoritmos de firma digital.

·        Gestión del pago: SET gestiona tareas asociadas a la actividad comercial de gran importancia como registro del titular y del comerciante, autorizaciones y liquidaciones de pagos, anulaciones, etc.

Quiénes participan en SET

El pago mediante tarjeta es un proceso complejo en el cual se ven implicadas varias entidades:

·        El banco emisor: emite la tarjeta del cliente, extiende su crédito y es responsable de la facturación, recolección y servicio al consumidor.

·        El banco adquiriente: establece una relación con el comerciante, procesando las transacciones con tarjeta y las autorizaciones de pago.

·        El titular de la tarjeta: posee la tarjeta emitida por el banco emisor y realiza y paga las compras.

·        El comerciante: vende productos, servicios o información y acepta el pago electrónico, que es gestionado por su entidad financiera (adquiriente).

·        La pasarela de pagos: mecanismo mediante el cual se procesan y autorizan las transacciones del comerciante. La pasarela puede pertenecer a una entidad financiera (adquiriente) o a un operador de medio de pago, el cual procesa todas las transacciones de un conjunto de entidades.

·        El procesador (redes de medios de pago): proporciona servicios adicionales operando la infraestructura de telecomunicaciones sobre las que se realizan las transacciones.

·        Autoridad de certificación: certifica las claves públicas del titular de la tarjeta, del comerciante y de los bancos.

En una compra convencional mediante tarjeta de crédito, en la que el cliente paga en la tienda haciendo uso de su tarjeta, la transacción sigue los siguientes pasos:

1. El titular de la tarjeta la presenta al comerciante.

2. Éste la introduce en el Terminal de Punto de Venta (POST), que su banco le ha proporcionado.

3. Los datos de la transacción se envían a través del sistema de redes de medios de pago hasta el banco emisor.

4. El banco emisor comprueba que todos los datos son correctos y remite su aprobación.

5. De ahí llega al banco adquiriente y al terminal del comercio, de donde saldrá el recibo de la operación.

6. El comerciante tendrá ingresado el dinero en su cuenta a las ocho del mañana del día siguiente.

7. Por su parte, el cliente no lo verá descontado de su cuenta corriente hasta el mes siguiente, en función de cuándo realice la compra.

A continuación se describe cómo SET realiza este mismo proceso a través de Internet.

 El funcionamiento de SET en 10 pasos

Una transacción SET típica funciona de forma muy parecida a una transacción convencional con tarjeta de crédito y consta de los siguientes pasos:

1. Decisión de compra del cliente. El cliente está navegando por el sitio web del comerciante y decide comprar un artículo. Para ello rellenará algún formulario al efecto y posiblemente hará uso de alguna aplicación tipo carrito de la compra, para ir almacenando diversos artículos y pagarlos todos al final. El protocolo SET se inicia cuando el comprador pulsa el botón de Pagar.

2. Arranque del monedero. El servidor del comerciante envía una descripción del pedido que despierta a la aplicación monedero del cliente.

3. El cliente comprueba el pedido y transmite una orden de pago de vuelta al comerciante. La aplicación monedero crea dos mensajes que envía al comerciante. El primero, la información del pedido, contiene los datos del pedido, mientras que el segundo contiene las instrucciones de pago del cliente (número de tarjeta de crédito, banco emisor, etc.) para el banco adquiriente. En este momento, el software monedero del cliente genera un firma dual, que permite juntar en un solo mensaje la información del pedido y las instrucciones de pago, de manera que el comerciante puede acceder a la información del pedido, pero no a las instrucciones de pago, mientras que el banco puede acceder a las instrucciones de pago, pero no a la información del pedido. Este mecanismo reduce el riesgo de fraude y abuso, ya que ni el comerciante llega a conocer el número de tarjeta de crédito empleado por el comprador, ni el banco se entera de los hábitos de compra de su cliente.

4. El comerciante envía la petición de pago a su banco. El software SET en el servidor del comerciante crea una petición de autorización que envía a la pasarela de pagos, incluyendo el importe a ser autorizado, el identificador de la transacción y otra información relevante acerca de la misma, todo ello convenientemente cifrado y firmado. Entonces se envían al banco adquiriente la petición de autorización junto con las instrucciones de pago (que el comerciante no puede examinar, ya que van cifradas con la clave pública del adquiriente).

5. El banco adquiriente valida al cliente y al comerciante y obtiene una autorización del banco emisor del cliente. El banco del comerciante descifra y verifica la petición de autorización. Si el proceso tiene éxito, obtiene a continuación las instrucciones de pago del cliente, que verifica a su vez, para asegurarse de la identidad del titular de la tarjeta y de la integridad de los datos. Se comprueban los identificadores de la transacción en curso (el enviado por el comerciante y el codificado en las instrucciones de pago) y, si todo es correcto, se formatea y envía una petición de autorización al banco emisor del cliente a través de la red de medios de pago convencional.

6. El emisor autoriza el pago. El banco emisor verifica todos los datos de la petición y si todo está en orden y el titular de la tarjeta posee crédito, autoriza la transacción.

7. El adquiriente envía al comerciante un testigo de transferencia de fondos. En cuanto el banco del comerciante recibe una respuesta de autorización del banco emisor, genera y firma digitalmente un mensaje de respuesta de autorización que envía a la pasarela de pagos, convenientemente cifrada, la cual se la hace llegar al comerciante.

8. El comerciante envía un recibo al monedero del cliente. Cuando el comerciante recibe la respuesta de autorización de su banco, verifica las firmas digitales y la información para asegurarse de que todo está en orden. El software del servidor almacena la autorización y el testigo de transferencia de fondos. A continuación completa el procesamiento del pedido del titular de la tarjeta, enviando la mercancía o suministrando los servicios pagados.

9. Más adelante, el comerciante usa el testigo de transferencia de fondos para cobrar el importe de la transacción. Después de haber completado el procesamiento del pedido del titular de la tarjeta, el software del comerciante genera una petición de transferencia a su banco, confirmando la realización con éxito de la venta. Como consecuencia, se produce el abono en la cuenta del comerciante.

10. A su debido tiempo, el dinero se descuenta de la cuenta del cliente (cargo).

El protocolo definido por SET especifica el formato de los mensajes, las codificaciones y las operaciones criptográficas que deben usarse. No requiere un método particular de transporte, de manera que los mensajes SET pueden transportarse sobre HTTP en aplicaciones web, sobre correo electrónico o cualquier otro método. Como los mensajes no necesitan transmitirse en tiempo presente, son posibles implantaciones de SET eficientes basadas en correo electrónico u otros sistemas asíncronos.

En su estado actual SET solamente soporta transacciones con tarjeta de crédito/débito, y no con tarjetas monedero. Se está trabajando en esta línea para extender el estándar de manera que acepte nuevas formas de pago. Al mismo tiempo se están desarrollando proyectos para incluir los certificados SET en las tarjetas inteligentes, de tal forma que el futuro cambio de tarjetas de crédito a tarjetas inteligentes pueda incorporar el estándar SET.

Nuestras novedades en tu e-mail

Escribe tu e-mail:

Al presionar "Recibir" estás dándote de alta y aceptas las condiciones legales de mailxmail

Cursos similares a Comercio electrónico. E-business (3/3)


  • Vídeo
  • Alumnos
  • Valoración
  • Cursos
1. Comercio electrónico. E-business (1/3)
Comercio electrónico. E.business. Con este práctico curso aprenderá nociones... [23/04/10]
1.412  
2. Comercio electrónico. E-business (2/3)
Conocer el comercio electrónico es algo imprescindible a día de hoy para alcanzar... [23/04/10]
848  
3. Creación de sitios de comercio electrónico
Con este tutorial, intentaremos dar un recorrido teórico-práctico por la... [28/11/05]
1.992  

¿Qué es mailxmail.com?|ISSN: 1699-4914|Ayuda
Publicidad|Condiciones legales de mailxmail


¿Te gustaría visitar más cursos gratis de Dirección y Liderazgo?